Database / DuckDB Interview questions
How does DuckDB differ from a traditional client-server database like PostgreSQL?
PostgreSQL runs as a standalone server process that client applications connect to over a network protocol (even if that network is just localhost), designed from the ground up around many concurrent clients, robust multi-user access control, and a row-oriented storage engine well suited to transactional workloads. DuckDB, in its traditional mode, runs embedded inside the calling application's own process with no separate server or network protocol involved.
| DuckDB (embedded mode) | PostgreSQL |
| Runs in-process; no separate server by default. | Runs as a standalone server process. |
| Columnar, vectorized engine optimized for OLAP. | Row-oriented engine optimized for OLTP. |
| Simple to embed in a single application/script. | Built for many concurrent clients and robust access control. |
| Single-file persistence, trivially portable. | Managed data directory requiring dedicated database administration. |
Notably, this gap has started narrowing somewhat: DuckDB's newer Quack client-server protocol brings an optional, genuine client-server deployment mode to DuckDB for cases that want that model, while PostgreSQL's own ecosystem includes DuckDB-powered extensions for accelerating analytical queries. The core distinction in typical use, though, remains DuckDB's embedded-first design against PostgreSQL's server-first, multi-client design.
More Related questions...