DuckDB 1.5 Review: Features, Limits, and Real Use Cases

The default answer to "my data outgrew a spreadsheet" has been the same for a decade: spin up a cloud warehouse. Snowflake, BigQuery, Redshift — pick your flavor of expensive, scalable, and somebody else's problem. That advice isn't wrong, exactly. But it's increasingly incomplete, because DuckDB has been quietly building a credible alternative for a very specific slice of the analytics world — the one-machine, one-analyst, why-am-I-paying-for-a-cluster slice — and its latest releases mark a genuine maturation point.

Better Stack's recent walkthrough of DuckDB 1.4 and 1.5 is worth engaging with seriously, mostly because it does something rare for tools coverage: it slows down to clarify what actually shipped when, and why that distinction matters.

The version confusion is real, and it's causing problems

Here's the thing the video surfaces that the broader developer discourse keeps bungling. There are two releases in play, and the internet has collapsed them into one fuzzy hype cloud.

DuckDB 1.4, released in September 2025, was the structural leap. Full AES-256 encryption at the page level. A MERGE INTO command for git-style upserts. The ability to write Apache Iceberg tables. And critically: DuckDB's first-ever long-term support release, which signals something about the project's maturity and its ambitions for production credibility.

DuckDB 1.5, released this past March, is refinement on top of that foundation. A redesigned CLI with colors and a pager. The new VARIANT type for semi-structured data. Built-in geometry support for spatial workloads baked into core rather than shipped as an extension afterthought.

As the Better Stack presenter puts it: "This is why 1.4 was the big update. It went from a query engine to something you can actually trust with real data on a single machine."

That framing is useful. 1.4 changed what DuckDB is. 1.5 changed how it feels. The distinction matters if you're deciding whether to adopt it now or were waiting for a specific capability.

What DuckDB actually is (and isn't)

The SQLite analogy the video reaches for is genuinely the clearest one: same single-file, no-server, embedded-in-your-process philosophy, but rotated 90 degrees toward analytical workloads. SQLite is a row store optimized for transactions — reading and writing individual records fast. DuckDB is a column store optimized for aggregation — scanning millions of rows and summing them up fast.

That architectural difference isn't incidental. It determines almost everything about when DuckDB makes sense and when it doesn't.

What it does well: reading Parquet, CSV, and JSON files without an import step. You point SQL at a file — including a remote file over HTTP — and it runs. The video demo shows querying a Parquet file from a URL in a single command, no schema definition, no server startup, no waiting. That's not a trick; that's the actual experience. For data exploration, ELT pipelines on single-machine scale, or notebook-style analysis, that frictionlessness is genuinely valuable.

The VARIANT type in 1.5 extends this to messier data. Mixed types — integers, strings, arrays, objects — in a single column, without schema enforcement, stored as typed binary that compresses and queries better than plain JSON. If you've ever wrestled with a JSON column in Postgres because your upstream data source couldn't decide what shape it wanted to be, you understand why this matters.

The MERGE INTO command from 1.4 is the piece that quietly expands what you can build. Upsert logic that used to require Spark jobs or custom Python now lives in a single SQL statement. "This is the kind of thing that used to require Spark or custom Python," the presenter notes. That's not hyperbole — it's a description of how much infrastructure DuckDB is absorbing.

Where it breaks down

The video is honest about the limits, which is why it's worth treating as a useful primary source rather than marketing material.

Memory is the recurring complaint. DuckDB processes data in-memory, and if your dataset exceeds available RAM, it falls over. Point it at a billion rows on a laptop with 16GB of memory and you'll find out the hard way. The project has made progress on spill-to-disk behavior, but the video doesn't oversell it: for very large datasets, a cloud warehouse still has a structural advantage that can't be wished away.

The single-writer constraint is equally fundamental. DuckDB is not a transactional backend. One process writes at a time. You're not wiring it to your application's session store or using it as the database behind a multi-user web app. That's still Postgres's job, or SQLite for smaller MVPs. DuckDB occupies a different niche entirely.

The encryption story deserves particular attention. AES-256 at the page level is real and thorough — but it's bring-your-own-key, fully. DuckDB doesn't store the key, doesn't rotate it, doesn't manage it in any way. "You lose the key, your data is gone." That's not a flaw in the design so much as a design decision with serious operational implications. For teams used to managed key services, this is an adjustment that requires actual key management infrastructure, not just a strong password you paste into a config file.

The Iceberg writing capability — the ability to produce Iceberg table format output — lives in an extension that the video flags as still relatively new. Worth watching, but worth caution if you're planning to build production pipelines around it today.

The open source angle

DuckDB is MIT licensed, no paywall, no enterprise tier. The project is developed primarily by DuckDB Labs, the company spun out of CWI (Centrum Wiskunde & Informatica in the Netherlands) to sustain DuckDB development. That structure — a research-originated project with a dedicated commercial entity that doesn't gate features behind a paid tier — is genuinely unusual in the current data tools landscape, where the open-core model has become so standard it barely registers as a choice anymore.

The first LTS release in 1.4 is meaningful in this context. LTS commitments are expensive for small teams to maintain. Making one signals either growing organizational capacity, genuine production adoption driving demand, or both. The fact that 1.5 landed on schedule as an incremental improvement on top of an LTS base suggests the project is operating with more deliberate release discipline than it was two years ago.

Whether DuckDB Labs' sustainability model holds up as the project matures — whether free-and-open forever is compatible with the staffing levels required to maintain something this widely depended on — is a question the OSS community has been asking about a lot of projects lately. DuckDB isn't in crisis, but it's worth watching how that equation evolves as adoption grows.

The actual question

The video lands in a sensible place: DuckDB is one of the best free tools available for analytics on a single machine, and the recent releases have made it meaningfully more trustworthy for data that matters. But it's not a cloud warehouse replacement for teams working at cloud warehouse scale, and it's not a transactional database for application backends.

What's more interesting than the tool itself is what its adoption curve reveals about developer preferences. The fact that DuckDB has built a substantial following by being less than Snowflake — cheaper, simpler, local, bounded — suggests that the default "go cloud" answer has been overshooting the actual requirements of a lot of real analytical workloads.

The question worth sitting with: if a database that runs on your laptop, costs nothing, and handles SQL on remote Parquet files in one command is genuinely sufficient for a meaningful percentage of analytics work, what does that say about how much infrastructure we've been buying by reflex rather than by need?

---

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag