Do I need a lakehouse, or just Parquet plus DuckDB?

Summary

• Parquet plus DuckDB is a complete setup when one process writes the data, the workload fits on one machine, and nobody needs row-level updates, shared permissions or a history of changes.
• A lakehouse (an open table format such as Delta Lake or Apache Iceberg, plus a catalog) earns its place once several writers, engines or teams share the data, or once rows change after they land.
• DuckDB's own docs point the same way: its database file allows one read-write process, and for stable multi-process writes they recommend DuckLake with PostgreSQL as the catalog database.
• It isn't either-or. DuckDB reads Delta Lake tables with its delta extension, Iceberg tables with its iceberg extension, and Unity Catalog tables with its unity_catalog extension.
• On Databricks, Unity Catalog governs Delta Lake and Apache Iceberg tables, and predictive optimization runs their maintenance automatically.

Do I need a lakehouse, or just Parquet plus DuckDB?

You don't need a lakehouse while one process writes the data, the workload fits on one machine, and nobody needs to update rows, control access per user or look back at earlier versions. In that case Parquet plus DuckDB is a complete setup: DuckDB queries Parquet files in place, reads only the columns a query needs, and spills to disk when data exceeds memory. You need a lakehouse, meaning an open table format such as Delta Lake or Apache Iceberg plus a catalog, once several writers, engines or teams share the data, or once rows change after they land. The choice isn't exclusive, because DuckDB can read lakehouse tables too.

What Parquet plus DuckDB covers

DuckDB is an in-process SQL database for analytical queries, released under the MIT License. It queries Parquet directly, from local disk or from object storage through its httpfs extension, with globs and Hive partitioning:

SELECT region, count(*) AS orders
FROM read_parquet('orders/*/*/*.parquet', hive_partitioning = true)
GROUP BY region;

Writing results back is a COPY (...) TO 'result.parquet' (FORMAT parquet) statement. For one analyst or one scheduled job, that loop can be all the infrastructure required.

Parquet plus DuckDB vs a lakehouse: how they compare

Capability	Parquet files with DuckDB	Lakehouse tables (Delta Lake or Apache Iceberg)
Storage	Parquet files on local disk or object storage	Data files such as Parquet, plus table metadata that records each committed version
Engines	DuckDB, embedded in your process	Engines with a reader for the format, including Apache Spark and DuckDB
Concurrent writers	DuckDB's database file allows one read-write process; for stable multi-process writes, DuckDB's docs recommend DuckLake with a PostgreSQL catalog	Optimistic concurrency control on every commit
Row-level changes	Your job writes new or replacement files	MERGE, UPDATE and DELETE statements
History	Not part of plain Parquet files; DuckLake adds snapshots and time travel	Delta versioning with DESCRIBE HISTORY; Iceberg snapshots, time travel and rollback
Data larger than memory	Out-of-core processing by spilling to disk	Distributed engines such as Apache Spark spill to disk across a cluster

When to move from Parquet files to a lakehouse

• A second writer appears. Delta Lake and Iceberg commit atomically with optimistic concurrency, so readers never see a partial write from a concurrent job.
• Rows change after they land. Change data capture, corrections and deletion requests map to MERGE, UPDATE and DELETE on a table format.
• You need history. Time travel reproduces an earlier version of a table, and rollback undoes a bad write.
• More engines or teams join. A shared catalog gives Spark jobs, DuckDB sessions and other tools one set of table names and one place to manage permissions.
• Governance becomes a requirement. A catalog such as Unity Catalog adds fine-grained governance and lineage over the same files.

The DuckDB project also offers a middle path. DuckLake is a lakehouse format that keeps data in plain Parquet files and metadata in a SQL database (PostgreSQL, MySQL, SQLite or DuckDB), with ACID transactions across multi-table operations.

How Databricks approaches the lakehouse

Databricks defines a data lakehouse as a data management system that combines the benefits of data lakes and data warehouses. Unity Catalog managed tables are the default and recommended table type for Delta Lake and Apache Iceberg, and predictive optimization runs OPTIMIZE, VACUUM and ANALYZE on them automatically, so table maintenance doesn't fall to your team. Unity Catalog adds fine-grained governance and lineage tracking for those tables.
DuckDB still fits in. Its unity_catalog extension attaches a Unity Catalog and queries its Delta tables, and Databricks lists DuckDB as a Beta client of the Unity REST API. Credential vending gives external engines short-lived credentials that inherit the privileges of the Databricks principal used to configure the integration.

FAQs

Is DuckDB a lakehouse?

No. DuckDB is an in-process analytical database. It reads lakehouse tables through its delta, iceberg and unity_catalog extensions, and the DuckDB project's DuckLake format adds a table and catalog layer of its own.

Can DuckDB read Delta Lake and Apache Iceberg tables?

Yes. The delta extension, built on Delta Kernel, reads Delta tables locally and in cloud storage and supports blind appends. The iceberg extension reads Iceberg tables from their metadata and writes through an attached Iceberg REST catalog.

When is plain Parquet with DuckDB the right call?

For one writer and a workload that fits on one machine, with append-only files, no row-level changes, no audit-trail requirement and a single team using the data.

Do I have to give up DuckDB to adopt a lakehouse?

No. Lakehouse tables keep their data in open file formats, and DuckDB's extensions read Delta Lake and Iceberg tables, including Delta tables in Unity Catalog.