The DuckDB Bet

The interesting thing about DuckDB in 2026 is not that it is fast.

It is fast. But that is no longer the most useful way to explain why teams are rebuilding real systems around it.

The better explanation is that DuckDB is simple enough to understand, modern enough to trust, and extensible enough to build on.

That combination is rare.

Most analytical systems ask you to adapt your architecture around the system. DuckDB has a different feel. It gives you a compact OLAP engine with a clean SQL surface, strong columnar execution, direct file access, and an extension model that lets you change where the engine fits instead of wrapping everything around it.

That matters when you are building infrastructure, not just using it.

At Altertable, we did not choose DuckDB because we thought one embedded database would replace the whole data stack. We chose it because it gave us a modern analytical core we could actually work with: inspect, extend, embed, debug, and contribute back to.

Simplicity in data infrastructure is often underrated because it sounds less impressive than scale.

But systems do not become reliable because every component is powerful. They become reliable when the important parts can be understood, tested, isolated, and changed without turning every improvement into a cross-service migration.

Fewer components also mean less surface area, fewer interconnections, and fewer ways for the system to fail.

DuckDB has that property.

It is not simple because the query engine is unsophisticated. It is simple because the boundary is clean. You can put it inside another process. You can query local files. You can extend it. You can reason about what is local, what is remote, what is persisted, and what is computed. You can build higher-level systems around it without immediately inheriting the operational shape of a distributed warehouse.

The bet is not that DuckDB replaces every part of the data stack.

The bet is that a small, well-designed analytical engine can become a powerful foundation for larger systems. DuckDB gives us a core that is easy to embed, extend, and reason about, while the surrounding architecture handles the pieces that belong outside the engine.

The recent engineering posts that resonate are not really about benchmarks. They are about teams using DuckDB as a building block and designing around it deliberately.

PostHog rebuilt its data warehouse on DuckDB over ClickHouse, while keeping ClickHouse for hot product analytics. The important point is not that one engine replaced another. It is that DuckDB became a foundation they could shape around their needs: single-tenant isolation, standard SQL behavior, a Postgres-compatible interface, local compute through extensions, and a stronger context layer for agents.

monday.com’s mondayDB 3 shows a similar pattern. They did not treat DuckDB as a distributed database. They designed around its strengths and constraints: durable snapshots in object storage, recent mutations in an external WAL, local DuckDB files on serving nodes, and a separate coordination layer for synchronization and routing. DuckDB handles the analytical execution; the surrounding system handles the pieces that do not belong in the engine.

MariaDB Foundation’s DuckDB storage engine shows the same idea from another direction. DuckDB is embedded as a storage engine inside MariaDB, allowing analytical tables to use ENGINE=DuckDB while remaining behind an existing database interface. The interesting part is not that MariaDB becomes DuckDB. It is that DuckDB can be embedded deeply enough to add columnar analytical execution without requiring users to adopt a separate analytical cluster.

These are three different systems and the common thread is not just performance.

The common thread is that DuckDB is simple and extensible enough to become part of the architecture.

The modern data stack has a bad habit: when a system is missing a capability, we add another system to an already large ecosystem.

Need search? Add a search system. Need AI access? Add an agent sidecar. Need ingestion? Add a pipeline. Need product analytics? Add a product analytics store. Need operational access? Add reverse ETL. Need local analysis? Export the data.

Each addition solves a real problem, but the stack gets less coherent. Data moves again. Permissions get reimplemented. Definitions drift. A single source of truth becomes harder to establish. Agents see partial context. Engineers spend more time maintaining glue than improving the core system.

This is where DuckDB’s extension model matters.

If the engine is extensible, more capabilities can be brought into the same execution model instead of forcing every new access pattern into a separate system. That does not mean every capability belongs inside DuckDB. It means the default answer does not have to be another disconnected service boundary.

This has been central to how we build Altertable.

We have built a lot of DuckDB extensions. We have contributed upstream many times. We keep choosing that path because it lets us improve the primitive instead of hiding limitations behind layers of glue.

The DuckDB Altertable extension is a good example.

It lets DuckDB connect to Altertable over Arrow Flight SQL. From a local DuckDB session, you can attach an Altertable catalog, query remote lakehouse tables, browse schemas, join governed lakehouse data with local files, and write results back with familiar SQL.

Copy
1
2
3
4
5
6
7
8
9
10
11
12
13
INSTALL altertable FROM community;
LOAD altertable;

ATTACH 'user=my-user password=my-pass catalog=analytics'
AS analytics (TYPE ALTERTABLE);

SELECT *
FROM analytics.main.events;

CREATE TABLE analytics.main.top_customers AS
SELECT customer_id, SUM(amount) AS total_amount
FROM read_parquet('local_orders.parquet')
GROUP BY customer_id;

That is not just a convenience feature.

It shows the two places DuckDB matters for Altertable: as a local runtime developers can use directly, and as the embedded execution core inside our managed lakehouse workers.

In both cases, the same principle applies: DuckDB gives us a compact analytical engine we can extend and reason about, while Altertable provides the governed foundation around it.

DuckDB is not the product. It is the analytical core we wanted to build on: small enough to understand, modern enough for serious workloads, and extensible enough that we can add capabilities at the engine boundary instead of surrounding it with glue.

Altertable is what sits around that core. Storage, federation, ingestion, search, orchestration, context, and agent access belong in one governed lakehouse, not in a constellation of systems that each reimplement permissions, drift on definitions, and force agents to stitch together partial context.

Replacing the fragmented stack with one operational lakehouse for analytics, applications, and agents is the work. DuckDB makes the execution layer tractable. Altertable makes the whole thing coherent.

That is the bet.