DuckDB
otsumami.duckdb
A Docker Compose file for DuckDB alone, generated from the catalog and checked by the safety inspector. No account needed.
In-process analytical database that runs OLAP queries over Parquet, CSV and its own columnar files without a server, embedding directly into the process that queries it.
DuckDB executes analytical SQL inside the calling process, the way SQLite does for transactional work, so there is no server to connect to and no data transfer between query engine and application. Its vectorised columnar execution handles aggregations and joins over tens of millions of rows on a laptop, and it reads Parquet, CSV, JSON and Arrow directly from disk or object storage without a load step. Extensions add HTTP and S3 access, full-text search, spatial types and connections to PostgreSQL, MySQL and SQLite. A first deployment usually means running the shell against an existing Parquet file and querying it in place.
You know it worked when
- The shell starts and reports its version.
- A query against a Parquet file returns rows without an import step.
- An aggregation over a large file completes within the container's memory limit.
- A persisted database file reopens with its tables intact after a restart.
Known sharp edges
- It is an in-process engine with no network listener, so a container running it exits as soon as its command finishes rather than staying up.
- A database file is held by one writing process at a time; concurrent writers from separate containers corrupt or block rather than queue.
- Query memory is bounded by the container's own limit, and a large join spills to a temporary directory that must have room or the query aborts.
- The on-disk file format has changed between major versions, and a file written by a newer build will not open in an older one.