BookNest's sample history is small: 137,944 sales lines, a 19 MB DuckDB 61,228 file, 7.75 MiB at ten times the size in ClickHouse 29,491 . Size and the number of people querying, more than features, choose the stack:
| Stage | Data and users | Stack | Why |
|---|---|---|---|
| Today | Under 10 GB, a few analysts | PostgreSQL 1,289 , DuckDB, dbt 37,942 | One server, no bill, fast enough |
| Growing | 10 GB-1 TB, dashboards for all | Add ClickHouse or a small cloud warehouse | Concurrency, event data |
| Large | Terabytes, many teams | Lakehouse (Lakehouses, Data Quality and Governance) or Snowflake, BigQuery 1 | Elastic compute, open formats |
For BookNest today the answer is the stack this chapter built: orders in PostgreSQL, a dimensional mart built and tested by dbt, DuckDB for exploration and files, PostgreSQL row-level security for shared access, and metrics defined once. Each later step keeps those parts: dbt models move to a new adapter, the star schema stays a star, and Iceberg 129 tables let ClickHouse, Spark 129 (Batch Processing with Apache Spark) and Trino 403,499 read the same data (Lakehouses, Data Quality and Governance). Revisit the choice when a measurement says so: a dashboard query over its latency budget, a nightly build that no longer fits its window, or a monthly bill above an engineer's time.