Fast in-process analytical database with rich SQL support and zero dependencies
A free, open-source analytical database that runs in-process, storing data in columns for fast local OLAP queries.
It gives you data-warehouse-style analytics on one machine with no server to run and no dependencies to install.
| Category | Analytics |
| First released | 2019 |
| Latest release | 1.5.4 (Jun 2026) |
| License | MIT |
| Written in | C++ |
| Runs on | Linux, Macos, Windows |
| Deployment | Embedded, Self-hosted |
| Wire protocol | |
| Query dialect | postgresql-sql |
| Consistency | strong |
| ACID support | native |
| JSON support | native |
| Full-text search | native |
| Vector support | extension |
| HA model | none |
| Managed by | motherduck |
DuckDB is a free, open-source database built for analytics. It runs in-process, meaning it lives inside your application as a library rather than a server you connect to over a network. That is the same model SQLite uses, which is why DuckDB is often called the SQLite of analytics. The difference is what it optimizes for. DuckDB stores data in columns and runs aggregations, joins, and scans over large tables, the kind of work a data warehouse handles.
The project began in 2019 at the Centrum Wiskunde & Informatica (CWI), the Dutch national research institute for mathematics and computer science, where much of the early column-store database research was done. Its creators, Mark Raasveldt and Hannes Mühleisen, later founded DuckDB Labs to develop it full time, and the non-profit DuckDB Foundation holds the intellectual property to keep the code MIT-licensed and independent. MotherDuck, a separate company, builds a managed cloud service on top of it.
DuckDB spread quickly through the data science and analytics world because it needs no setup and reads common file formats directly. Tools like Hugging Face's dataset viewer, Rill Data, Evidence, and Hex build on it, and analysts reach for it inside Python and R notebooks to query Parquet and CSV files without loading them into a warehouse first. It runs on laptops, inside serverless functions, and in the browser through WebAssembly.
DuckDB has no server process. You load it as a library inside Python, R, Java, or a handful of other languages, or run its standalone command-line shell, and the engine executes queries in the same process as your program. There is no connection to open, no port to manage, and no separate daemon to keep running. A database is either a single file on disk or an in-memory instance that disappears when the process ends.
Where a transactional database stores rows together, DuckDB stores each column separately. An analytical query that sums one column reads only that column instead of every field in every row. On top of that it uses vectorized execution: rather than processing one row at a time, it moves batches of a few thousand values through each operator, which keeps the CPU cache warm and lets modern processors work through data much faster. Join ordering, query planning, and parallel execution across cores all happen automatically.
DuckDB reads Parquet, CSV, and JSON files directly, so a query like SELECT * FROM 'data.parquet' works with no import step. It pushes filters and column selection down into the file scan, reading only the parts of a Parquet file a query needs. Extensions add capabilities on demand. httpfs reads files straight from S3 and HTTP endpoints, spatial adds geometry types, and the postgres and sqlite extensions attach and query those databases in place. Each installs and loads with a single SQL command.
DuckDB runs as a library inside your application's process, not as a standalone server. There is no daemon to start, no port to bind, and no network round trip between query and data. You open a database file or an in-memory instance directly from Python, R, Java, or the CLI, so it embeds as easily as SQLite while targeting analytical work.
DuckDB stores each column of a table separately instead of keeping whole rows together. Analytical queries usually touch a few columns across many rows, so reading columns in isolation moves far less data off disk. The layout also compresses well, since values in one column share a type and often repeat, feeding the vectorized engine.
Instead of processing one row at a time, DuckDB moves batches of roughly a few thousand values through each operator at once. These vectors stay in the CPU cache, so aggregations, filters, and joins run with far less per-row overhead than a row-by-row engine. The work spreads across all available cores automatically, with no tuning from you.
DuckDB queries Parquet, CSV, and JSON files as if they were tables, with no import or loading step. Point a query at a file path or a glob of many files and it reads them in place. For Parquet it uses the file's own statistics to skip row groups and read only the columns a query names, so a scan touches just the parts that matter.
Capabilities load on demand through extensions installed with a single SQL command. httpfs reads files straight from S3, GCS, or any HTTP endpoint. The spatial extension adds geometry types, fts adds full-text search, vss adds vector similarity, and the postgres and sqlite extensions attach those databases to query from inside DuckDB.
A DuckDB database is a single file on disk, or an in-memory instance that vanishes when the process exits. Writes are ACID, so a transaction either lands completely or not at all, even across a crash. Its SQL dialect follows PostgreSQL closely and adds analyst touches like SELECT * EXCLUDE, GROUP BY ALL, and struct types for nested data.
Live GitHub adoption, updated daily
A handful of the companies running it in production
Run aggregations and joins over millions of rows on a laptop without standing up a warehouse. DuckDB uses every core and keeps data in columns, so large scans finish in seconds right on your machine.
Query Pandas, Polars, and Arrow frames in place with SQL from Python or R. DuckDB reads and writes those formats without a copy, so it slots right into a notebook beside the rest of your analysis.
Point SQL straight at Parquet, CSV, and JSON files, including globs and files on S3. Filters push down into the scan, so a query over a large dataset reads only the columns and row groups it needs.
Ship an analytical engine inside a desktop app, a CLI, or a browser through WebAssembly. There is no server to run and no dependency to install, so the database travels with your product as one library.
DuckDB allows one writer at a time to a database file. For apps with many users inserting and updating rows at once, a row store like Postgres or MySQL handles the concurrent writes DuckDB is not built for.
There is no server process, no user accounts, and no network protocol for many clients. When several services need to share one live database over a network, reach for Postgres, MySQL, or a warehouse.
DuckDB runs on a single node with no built-in replication or failover. Workloads that need an always-on database surviving a machine loss should use a clustered system like Postgres or ClickHouse.
A single machine handles a lot, but petabyte datasets spread across a cluster are a different job. For distributed analytics at that scale, Snowflake, BigQuery, or ClickHouse split work across many nodes.
Head-to-head specs against the top 4 alternatives
| Spec | |||||
|---|---|---|---|---|---|
| Identity | |||||
| License | MIT | Public Domain | PostgreSQL License | Apache-2.0 | Proprietary |
| First released | 2019 | 2000 | 1996 | 2016 | 2014 |
| Capabilities | |||||
| Consistency | Strong | Strong | Strong | Eventual | Strong |
| HA model | None | None | Primary-standby | Primary-standby | None |
| JSON | Native | Native | Native | Native | Native |
| Ecosystem | |||||
| Managed providers | 1 | 2 | 9 | 3 | 1 |
| Integrations | 6 | 4 | 8 | 7 | 8 |
| Use cases | |||||
| Best for | Local OLAP queries, data science workflows, embedded analytics, and Parquet/CSV processing | Embedded applications, mobile apps, local data storage, edge computing, and prototyping | General-purpose OLTP, complex queries with advanced SQL, geospatial data with PostGIS, and applications requiring strong ACID compliance | Real-time analytics, log and event analytics, OLAP queries over billions of rows | Large-scale analytics, data warehousing, cross-cloud data sharing, and multi-cluster concurrent workloads |
| Not ideal for | Multi-user server workloads, OLTP applications, or distributed analytics at massive scale | High-concurrency write-heavy workloads, multi-user client-server applications | Extreme write-heavy workloads at massive horizontal scale, simple key-value caching, or real-time streaming without extensions | OLTP workloads, frequent small updates/deletes, or applications requiring strict ACID transactions | OLTP transactional workloads, low-latency point lookups, or cost-sensitive small-scale projects |
Install DuckDB, open the shell, and query a Parquet file directly. Under a minute, and there is no server to configure.
pip install duckdb# macOS
brew install duckdb
# Or download the binary
curl https://install.duckdb.org | sh# In-memory (nothing persisted)
duckdb
# Or a persistent file
duckdb analytics.duckdbSELECT country, count(*) AS users
FROM 'users.parquet'
GROUP BY country
ORDER BY users DESC
LIMIT 10;That reads the file in place, with no import step. The same query runs from Python with duckdb.sql(), or reach for a GUI when you want to browse tables and results visually.
Fast open-source column-oriented database for real-time analytics and OLAP
The world's most advanced open-source relational database
The most popular document database for modern applications
High-performance open-source vector database for next-generation AI applications
In-process SQL database compatible with SQLite, written in Rust with vector search and CDC support
Fast, typo-tolerant open-source search engine with built-in vector and semantic search
Connect to DuckDB in 30 seconds. Browse tables, run queries, and edit rows visually, on localhost, self-hosted, or cloud.
Open DuckDB in 1bench