Running DuckDB in production with multiple concurrent writers requires solving its single-writer limitation. Two approaches are covered: Quack, a new client-server protocol that serializes writes server-side enabling concurrent writers without lock conflicts, and DuckLake, a Parquet-based table format using a Postgres catalog for transactional metadata. Benchmarks compare NVMe local storage vs S3-hosted Parquet and DuckLake, showing local NVMe is dramatically faster. The recommended production pattern combines hot local NVMe storage for interactive analytics with lakehouse storage for batch workloads. Trade-offs include operational overhead of running a Quack server with a custom auth proxy, or managing a Postgres catalog dependency for DuckLake.
