ClickHouse vs DuckDB

Quick verdict

ClickHouse describes itself as a real-time analytics database management system. It stores data by column in MergeTree table engines designed for high insert rates, with sparse primary indexes, partitioning, TTL rules and background merges. The server is open source under the Apache License 2.0 and released monthly; the ClickHouse changelog lists 26.10 (22 October 2026) as the latest release line. You can run it yourself on one machine or a cluster, or use ClickHouse Cloud on AWS, Google Cloud and Azure (Basic, Scale and Enterprise plans, plus Bring Your Own Cloud). ClickHouse also documents clickhouse-local, for SQL over local and remote files without a server, and chDB, "an in-process SQL OLAP Engine powered by ClickHouse", with bindings for Python, Go, Rust, Node.js, Bun and C/C++.

DuckDB is an in-process analytical database. By default it does not run as a separate process but is embedded within the host process, has no external dependencies, and uses a columnar-vectorised execution engine. It runs on Linux, macOS and Windows on x86 and ARM, and in the browser through DuckDB-Wasm. It is released under the MIT License, with the intellectual property held by the DuckDB Foundation. The release calendar lists DuckDB 2.0.0, a Long-Term Support release, on 21 October 2026, with 2.0.1 planned for 18 November 2026. DuckDB 2.0 ships a polished version of the Quack remote protocol, which lets DuckDB act as a client-server database.

For each engine against other systems, see ClickHouse vs Snowflake, ClickHouse vs PostgreSQL, DuckDB vs SQLite and DuckDB vs Snowflake.

Side by side

Key differences

A server for many users or a library for one process

The practical difference is where the engine lives. ClickHouse is a database server: clients connect over the network, many queries run at once, and data keeps arriving while it is queried. That is what you need behind a dashboard used by hundreds of people, an observability tool or an analytics feature inside a SaaS product.

DuckDB runs inside the program that calls it. A Python process can import it, query a folder of Parquet files and hand the result to a DataFrame, with no network hop, no credentials and no service to keep running. Its concurrency rules follow from that: one process may read and write a database file, using several writer threads, or many processes may open it read-only. For multi-process writes the DuckDB docs point to the Quack remote protocol or to DuckLake with PostgreSQL as the catalog.

Both projects now reach toward the other side. ClickHouse documents clickhouse-local for file processing and chDB as an in-process engine, but notes that clickhouse-local "is not suitable for serving end users or applications". DuckDB 2.0 makes Quack a polished client-server option. In our view, the defaults still describe the products: ClickHouse is built to serve, DuckDB is built to embed.

Continuous ingestion versus analysis of data at rest

ClickHouse's MergeTree engines turn each insert into a sorted part that is merged in the background, and incremental materialized views run a query on each inserted block, so aggregates are maintained as data lands. Table engines and, in ClickHouse Cloud, ClickPipes read from Kafka, object storage and database CDC sources. This is the design for event streams that never stop.

DuckDB is designed for analytical queries over large portions of data with bulk changes. It shines at loading or scanning a set of files, transforming them and writing results, for example as a step in a data pipeline or a dbt project. Using it as the live target of thousands of small inserts per second from many producers is not what it is designed for. Both engines can query the same Parquet files in object storage directly:

-- ClickHouse: query Parquet files in S3 in place
SELECT event_type, count() AS events
FROM s3('https://example-bucket.s3.amazonaws.com/events/*.parquet', 'Parquet')
GROUP BY event_type
ORDER BY events DESC;

-- DuckDB: the same question (after creating an S3 secret)
SELECT event_type, count(*) AS events
FROM read_parquet('s3://example-bucket/events/*.parquet')
GROUP BY event_type
ORDER BY events DESC;

Scaling: clusters and cloud versus one machine

ClickHouse scales out. Self-hosted, you shard and replicate tables across nodes; in ClickHouse Cloud, compute is separated from object storage, Scale and Enterprise plans add vertical autoscaling and compute-compute separation, and idle services can stop. Data volume is bounded by your cluster or cloud budget rather than one machine.

DuckDB scales up. It uses all the cores of the machine it runs on and can process data larger than memory by spilling to disk, but it does not distribute a query across machines. For shared, multi-user access to DuckDB data, the options are DuckLake (a table format with a separate catalog database), the Quack protocol, or a hosted service built on DuckDB such as MotherDuck, which a separate company runs; see DuckDB vs Snowflake for its plans.

SQL dialect, updates and licences

DuckDB's SQL follows PostgreSQL closely and adds conveniences such as GROUP BY ALL and SELECT * EXCLUDE; it supports ACID transactions within its writer process, and standard UPDATE and DELETE. ClickHouse SQL has a large library of analytical functions and specialised joins, but its model is append-oriented: primary keys define sort order rather than uniqueness, lightweight deletes and updates work differently from row-store databases, and multi-statement transactions are experimental and not supported in ClickHouse Cloud.

Both are permissively licensed: ClickHouse's server under Apache 2.0 and DuckDB under MIT. ClickHouse, Inc. funds development and sells ClickHouse Cloud; DuckDB's intellectual property sits with the DuckDB Foundation, and DuckDB Labs offers commercial support. Neither licence restricts offering the engine as a service.

Pricing and licensing

ClickHouse server is free under the Apache License 2.0; self-hosted costs are your servers, storage and staff time. ClickHouse Cloud is usage-based with no monthly minimum: compute is metered per minute and priced per compute unit-hour (one unit is 8 GiB of RAM and 2 vCPUs), storage per TB per month, and backups, data transfer and ClickPipes are billed separately. Rates vary by plan, cloud and region; as one example, clickhouse.com/pricing lists the Enterprise plan on AWS us-east-1 at USD 0.39030 per compute unit-hour and USD 25.30 per TB-month of storage. New accounts get a 30-day trial with USD 300 in credits and no credit card. BYOC is quoted by sales.

DuckDB is free under the MIT License, with no paid edition of the engine. Costs are the machine it runs on plus any cloud storage reads and egress. duckdb.org notes that extended support for LTS releases is available commercially from DuckDB Labs, without published prices. Hosted services built on DuckDB, such as MotherDuck, are priced by the companies that run them.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want a fully managed, general-purpose warehouse for many teams with governance features: see ClickHouse vs Snowflake and DuckDB vs Snowflake.
• Your workload is transactional application storage: see DuckDB vs SQLite and ClickHouse vs PostgreSQL.
• You need a time-series database with retention and downsampling built for metrics: see ClickHouse vs TimescaleDB and the best time-series databases.
• You need distributed SQL over a data lake with many sources: see Trino vs Spark.

Final recommendation

Frequently asked questions

Sources

• ClickHouse GitHub repository and licence
• ClickHouse changelog
• ClickHouse: chDB
• ClickHouse: clickhouse-local
• ClickHouse: Incremental materialized views
• ClickHouse Cloud pricing
• DuckDB: Why DuckDB
• DuckDB release calendar
• DuckDB 2.0 documentation: Concurrency

Checked November 2026.

How we research comparisons: our editorial method.