Why DuckLake fits an embedded architecture and a separate OLAP cluster doesn't, and the hidden risk of a catalog database on the hot path.

Once you embed DuckDB, the next question is where the data lives. Two options: a lakehouse format (DuckLake) or a dedicated OLAP cluster like StarRocks.

The trade-off

• A cluster adds a second system to operate, size, fail over and secure — justified only when you need concurrent writes or sub-second freshness.
• DuckLake keeps tables as files on object storage with a small catalog database tracking snapshots. The embedded engine reads both directly.

The hidden risk: the catalog database sits on the query path. If it's down or slow, every query is. Keep it tiny, replicate it, and cache snapshot metadata in the service so a catalog hiccup degrades freshness, not availability.

The lesson: match storage to your actual concurrency and freshness needs. An embedded engine plus lakehouse files covers most read-heavy analytics without a cluster's operational bill — as long as you treat the catalog as a critical dependency, not an implementation detail.