Choose ClickHouse vs DuckDB based on who queries the data and who owns it
DuckDB fits when one application, notebook or scheduled job owns its data. DuckDB is embedded in its host process, so there is no database server to install, patch or back up as a separate service. That suits analysts working alone on large files, pipelines that rebuild a dataset on a schedule, and tools that ship analytics inside their own software. ClickHouse fits when several users or services query and write the same data at the same time, or when replication, backup and access control must be designed in from the start. Its server runs as its own process, and its replicated tables are coordinated through ClickHouse Keeper, which is the part your team will have to operate.
The decision turns on four questions. First, how many readers and writers will touch the data at once, and do they need to write from separate processes? DuckDB's concurrency model allows several processes to read a file in READ_ONLY mode, but writing from several processes needs an additional protocol or DuckLake with PostgreSQL as the catalog, so confirm whether that path is production ready for your version. Second, is the data shared across teams or owned by one job? Third, how fast will volume grow, and does your current design still hold at ten times today's size? Fourth, what operating capacity does your team have for a cluster, including Keeper nodes, upgrades and restore tests?
Ask the vendor or your own platform team to confirm which ClickHouse release line you would run, since the ClickHouse production FAQ describes how stable and LTS releases are supported. A useful test is to write a short list of your real query and write patterns, then run them against a single DuckDB file and a single ClickHouse server before you commit to a cluster design.
Which scenarios favor DuckDB and which favor ClickHouse
This table maps common analytics scenarios to the engine with the better fit and explains each choice through process model, concurrency and operations. Read it by matching your workload to a row, then checking the reason column against your user count, write pattern and who will run the system. The main takeaway is that DuckDB removes a server but ties access to one host process or a shared file, while ClickHouse adds a server to run and gains shared, concurrent access.
| Scenario | Better fit | Reason |
|---|---|---|
| Ad hoc analysis of Parquet files on a laptop | DuckDB | DuckDB runs inside the analyst's process and reads Parquet named in the FROM clause, so there is no server to install or patch. |
| Nightly Python job that transforms and writes files | DuckDB | The job opens an embedded database, does its work and exits, so the job owns its lifecycle without a separate service to keep running. |
| Product feature embedding analytics for one tenant | DuckDB | An application process can embed DuckDB and query its own data, which suits one writer and a small number of readers inside the same host. |
| Dashboards for many analysts over shared tables | ClickHouse | A ClickHouse server serves many concurrent SQL clients over network protocols, while DuckDB's file access is limited to one read-write process or read-only readers. |
| Continuous ingestion from several services | ClickHouse | Several services can write to one server at once, whereas DuckDB writes from multiple processes need the beta Quack protocol or DuckLake with PostgreSQL. |
| Large, long-running scans with few concurrent users on one machine | Either, depending on operations | DuckDB avoids a server, while ClickHouse adds replication and backup work; choose by who will operate the system and how many users connect. |
| Parquet produced by a pipeline that both engines read | Both | DuckDB can query the same Parquet files that ClickHouse reads, so each team uses the engine that suits its job without copying data into a second store. |
| Shared analytics needing HA and backup | ClickHouse | Replicated tables with Keeper and BACKUP and RESTORE support are server-side features; DuckDB's single-file model needs your own backup and failover design. |
How each engine is built and what that means for operations
DuckDB and ClickHouse solve analytics from opposite ends: one runs inside your process, the other is a service your team keeps running. The cards below trace each design choice to a concrete task someone on your team will own, from restarts and patching to restore testing.
DuckDB runs inside the host process
DuckDB is embedded in the application, notebook or job that uses it, so there is no database server to install, update or keep running. The operational question shifts to the host: whoever deploys the job decides when DuckDB upgrades, and a crash in that process ends the query. Check how your team pins the DuckDB version in each host, since a library upgrade is the only upgrade path.
ClickHouse runs as a server you operate
ClickHouse runs as clickhouse-server processes on hosts you control, so someone owns patching, restarts, disk growth and capacity. Stable releases ship roughly monthly, and the security policy names which lines get security updates, so the upgrade calendar becomes a standing task. Confirm who approves a version change and how a pre-production environment with representative data is kept in step.
Replication through ClickHouse Keeper
Replicated tables use ReplicatedMergeTree, coordinated by ClickHouse Keeper, which replaces ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, so a replicated setup adds a second tier of machines to patch and monitor. A recovered replica syncs missing data from a healthy peer on its own, but replication does not protect against accidental deletes or corruption, which is why backups still matter.
Authentication and access on the server
A ClickHouse server carries its own access control, with users, roles and grants, and can delegate sign-in to external authenticators such as LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT. Someone must own user lifecycle, certificate rotation and directory connectivity, and those duties land on your identity team. DuckDB has no accounts at all, so access control there comes from file permissions and the host application.
Reading Parquet directly from files
DuckDB reads CSV and Parquet by naming the file in the FROM clause, so a job can query files on local disk or object storage without loading them first. The operating work is file lifecycle: who writes the Parquet, where it lands, and how schema changes are versioned. ClickHouse can also query Parquet, but its main path is tables it manages, so confirm whether your data stays as files, becomes server tables, or both.
Backups and restore tests
ClickHouse BACKUP and RESTORE cover full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The backup documentation warns that a backup never test-restored will probably not restore when needed, so a restore drill on a spare cluster belongs in the runbook. With DuckDB, the durable copy is usually the source files or the database file, so the team must define which copy is authoritative and how it is restored.
Capability comparison from supplied facts
This table sets the ClickHouse server against the embedded DuckDB engine on the capabilities that decide architecture: licensing, writes, replication, backup, authentication, file access and release support. Read each row as a question about your workload, and treat any cell that says to confirm as a item for your pilot. The main takeaway is that DuckDB removes the server to operate, while ClickHouse supplies the multi-user write, replication and access controls that a shared service needs.
| Capability | ClickHouse server | DuckDB |
|---|---|---|
| License | Apache License 2.0 for the open-source server; ClickHouse Cloud is a separate managed service | MIT License, with intellectual property held by the DuckDB Foundation |
| Deployment model | Separate database server that you install, run and upgrade on your own hosts | Embedded in a host process (application, notebook or job) with no server to maintain |
| Concurrent writes | Designed as a multi-user server for concurrent access; confirm write throughput and locking behavior with your own load | One read-write process per database file; several processes can only read in READ_ONLY mode, and multi-process writes need the beta Quack protocol or DuckLake with PostgreSQL |
| Replication | ReplicatedMergeTree tables coordinated by ClickHouse Keeper, with recovered replicas syncing automatically from a healthy replica | No built-in replication of a database file; confirm how your team would share or copy data across hosts |
| Backup and restore | BACKUP and RESTORE support full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage; replication alone does not protect against human error | Backup depends on how you store the database file or Parquet source data; confirm your procedure and restore test |
| External authentication | LDAP, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication | Not applicable as a shared service; access control follows the host process and file permissions |
| Parquet and CSV access | Loads and queries data through its table engines and formats; confirm the exact file-based workflow for your pipeline | Queries CSV and Parquet files by naming them directly in the FROM clause |
| Table format extensions | Confirm support for open table formats such as Iceberg or Delta Lake in your target version | Core extensions for iceberg, delta and ducklake, most at the best-effort support tier; confirm support level for your formats |
| Release cadence and support | Stable roughly monthly, LTS twice a year with one-year support; 26.9, 26.8, 26.7 and 26.3 receive security updates | Latest supplied release is v1.5.6 (September 28, 2026); confirm your own upgrade and compatibility policy |
| Browser or Wasm use | Not a browser engine; use it as a server reached over the network | DuckDB-Wasm runs in web browsers, and the engine also runs on Linux, macOS and Windows on x86 and ARM |
What each license allows and what is paid for
The ClickHouse server is open source under the Apache License 2.0, so your organization can run, modify and redistribute it without a license fee. The license covers the software itself, not the work to run it. Your team carries the cost of installing, upgrading, backing up and monitoring the server, along with any clusters you build from it. Those costs are staff time and infrastructure you already pay for.
- Permissive terms: Apache-2.0 allows internal use, modification and redistribution, subject to its notice and attribution conditions.
- Recurring work: Stable releases ship roughly monthly, and LTS releases ship twice a year and are supported for a year, so upgrade planning is an ongoing cost.
- Supported versions: The security policy lists 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and other versions as unsupported.
- Replication and backup tooling: Keeper, replication and BACKUP and RESTORE are part of the open-source server, so they are your responsibility to configure, test and staff.
- Support terms: Vendor or services-firm support for the open-source server is a separate contract. Confirm its scope, response terms and whether it covers your version with ClickHouse Inc. or your chosen provider.
Before you commit, read the ClickHouse security policy and confirm in writing what any support agreement covers for your deployed version.
ClickHouse Inc. sells ClickHouse Cloud as a managed service separate from the open-source server. It is a different product with different operating terms, so buying it does not change the license of the server you run yourself. Choosing Cloud shifts operations to the vendor and replaces them with a metered bill for compute and storage. Cost and feature scope should be compared against your own hosting and staffing estimates, not assumed.
- Separate purchase: Cloud is priced and contracted separately from the Apache-2.0 server, and the supplied facts do not give its rates.
- Operational shift: The vendor runs the service, so backup, upgrade and availability duties move to the provider under the contract.
- Feature differences: Confirm which engines, authentication methods and settings your workload needs are available in Cloud before you assume parity with self-hosting.
- Data residency: If residency is a requirement, ask which regions and deployment options are offered, including any bring-your-own-cloud arrangement.
- Exit terms: Ask how data would be exported and how long migration back to self-hosting would take, since that cost recurs in the form of lock-in risk.
Request a written quote that itemizes compute, storage, backup, support and data transfer, and confirm which of these you would still need to staff yourself.
DuckDB is released under the MIT License, one of the most permissive open-source licenses in common use. The DuckDB Foundation holds the project's intellectual property. Because DuckDB runs inside your own process, there is no server license or server subscription to account for. The supplied facts do not describe any paid DuckDB edition, so you should confirm with the project and your own legal review whether any commercial offering applies to your use.
- MIT terms: The license permits use, modification and redistribution with the copyright notice retained, and it carries no copyleft obligation on applications that embed DuckDB.
- Foundation ownership: The DuckDB Foundation holds the intellectual property, which matters if you need to know who controls the project's direction and assets.
- No paid edition described: The supplied facts do not describe a commercial DuckDB edition, so do not budget for one without confirming it.
- Third-party extension: The motherduck extension connects DuckDB to the MotherDuck service and is maintained by a third party, so its terms and support are separate from DuckDB's own.
- Extension support tiers: Most core extensions, including iceberg, delta, ducklake and httpfs, sit at a secondary, best-effort support tier, which affects how much you can rely on them in production.
Before relying on an extension in a regulated workload, check its support tier and maintainer in the core extensions documentation and record the result in your own assessment.
The DuckDB ecosystem includes services and extensions maintained outside the core project. The motherduck extension is the clearest example in the supplied facts: it links DuckDB to a managed service, and its maintenance sits with a third party rather than the DuckDB project. Adopting it adds a dependency that carries its own terms and costs. Plan this as a separate purchasing and risk decision from the MIT-licensed engine.
- Third-party maintenance: The extension is maintained by a third party, so bug fixes and release timing do not follow the core DuckDB schedule.
- Managed service terms: Any connection to a hosted service is governed by that service's own agreement, which the supplied facts do not describe.
- Data path questions: Confirm where queried data is processed and stored when the extension is used, since that determines your residency and access review.
- Lock-in exposure: Queries and workflows written against a hosted endpoint may need rework if you return to local DuckDB only.
- Support boundaries: Confirm who answers for issues that span DuckDB, the extension and the managed service before you rely on the combination.
Ask the extension maintainer and any hosted provider for written support terms before you place regulated data behind this path.
What drives the running cost of a ClickHouse server versus DuckDB
DuckDB's running cost is mostly the host that runs the application, notebook or scheduled job, plus the engineer time spent on files and table formats. Because DuckDB is embedded in a host process, there is no database server to install, patch or keep online, and its MIT license carries no license fee. The recurring costs sit in compute sized for the largest job, storage for Parquet and CSV files, and the time someone spends on file layout, schema drift and access control. Those costs rise when several teams must write to the same database file. DuckDB's concurrency documentation points to the Quack remote protocol, which was in beta as of v1.5.2, or to DuckLake with PostgreSQL as the catalog, and each adds components to run. Confirm how many writer processes you expect before you assume the cost stays near zero.
A ClickHouse deployment carries one-time work and recurring work. The one-time work is designing the layout: replicated tables, the Keeper quorum, backup targets, and a pre-production environment with representative data and queries. The recurring costs are servers and storage for each replica, at least three ClickHouse Keeper nodes on dedicated hosts in production with about 4 GB of RAM each, and backup storage on local disk, S3-compatible storage or Azure Blob Storage. Restore tests on spare capacity are also recurring, because the ClickHouse backup documentation warns that a backup never test-restored will probably not restore when needed. Upgrades recur as well, since stable releases ship roughly monthly, LTS lines are supported for a year, and minor backward-incompatible changes can occur. Costs climb with replica count, shard count and retention, and fall when you standardize on one LTS line and automate restore tests.
When you request a written quote, the items that move the number are specific. Ask for the replica count per shard and whether Keeper runs on three dedicated hosts with the stated memory or shares hosts with clickhouse-server. Ask which backup targets are in scope, how often full and incremental backups run, where they are stored, and how many restore tests are included each year and on what capacity. Ask who selects versions, whether upgrades follow the LTS line or the stable line, and whether the pre-production environment and changelog review are itemized. For DuckDB, ask who maintains the Parquet layout and table format versions and how many writer processes are in scope. Request that the quote separate one-time implementation from recurring support, so you can compare it with the host and engineer hours you would otherwise carry.
Moving analytics from DuckDB files to a ClickHouse server, or back
This sequence moves analytical data and queries from DuckDB files into a ClickHouse server, or back, without losing the system of record or the ability to recover. Each step ends with a check that tells the team whether it can move to the next one.
Confirm the system of record
Before any move, the data team decides whether the Parquet or other files, the DuckDB database file, or the ClickHouse tables are the authoritative copy. Engineering and the data owners sign off in writing, because the other copies become derived data that must be rebuilt from the source. The step is done when every dataset has one named owner and one named source of truth, and the team agrees on which direction the data flows during the transition. Teams that skip this step often discover later that two copies have diverged.
Define schema and types in ClickHouse
Map each DuckDB or Parquet column to a ClickHouse table definition, choosing column types, sorting keys and partitioning deliberately rather than copying the source layout. Review nullable columns, decimal precision and timestamp zones, since type mismatches are a common source of silent differences. Confirm the engine choice with the ClickHouse documentation for your table design. The step is done when a reviewer has read every DDL statement and each table has a documented mapping from its source columns.
Load and validate with representative data
Load a representative slice of the data first, then the full set, using a pre-production cluster. Run the queries your readers actually use against both engines and compare row counts, sums, distinct counts and sample rows for each table. Load timing and resource use will vary with your data and hardware, so measure them on your own environment rather than relying on published figures. The step is done when the results match within the tolerance the data owners agreed to, and any gaps are explained and closed.
Rewrite SQL where dialects differ
Most standard SQL and the file-reading syntax in DuckDB will not carry over unchanged, so move each query into ClickHouse SQL and note every function that needed a replacement. Keep a list of queries that transfer as written, since those can be reused on both engines. Test each rewritten query against the validated results from the previous step. The step is done when every query in scope has either a ClickHouse version with matching output or a documented reason it is retired.
Build and test backups with a restore
Configure ClickHouse BACKUP for the tables in scope and schedule it, storing copies on a destination outside the cluster. Replication does not protect against human error or corruption, so the backup is a separate control. Restore the backup onto a spare cluster and compare the restored data with the source. The ClickHouse backup documentation warns that an untested backup will probably not restore when needed, so repeat the restore test on a regular schedule. The step is done when a restore has completed on a spare cluster and the comparison has passed.
Switch readers in stages
Move dashboards, notebooks and jobs to the new source one group at a time, starting with low-risk readers. Keep the previous DuckDB files or Parquet exports available until each group has run for a full reporting cycle without issues. Track which consumers read from which source so rollback is a configuration change rather than a rebuild. The step is done when every reader in scope points to the new source, and the old source is marked read-only with an agreed retirement date.
Rebuild jobs, access and monitoring
Some work does not transfer: scheduled jobs that wrote DuckDB files must be rewritten to load ClickHouse, access rules must be recreated in ClickHouse access control, and external authentication such as LDAP or JWT must be configured for the server. Monitoring for query latency, replication health and backup status also needs to be built. Assign an owner to each item. The step is done when each rebuilt job, role and alert has been tested by its owner.
Keep DuckDB for ad hoc reads
After the cutover, DuckDB remains useful for analysts who read exported Parquet files on their own machines. Export from ClickHouse on a defined schedule, keep the file layout documented, and confirm that DuckDB can query the exported files by name in the FROM clause. Remember that DuckDB in read-write mode is limited to one writing process at a time, so do not point multiple writers at the same file. The step is done when a sample of exported files returns the same results in DuckDB as in ClickHouse.
Where ClickHouse server projects usually run long
The timeline for a ClickHouse server project is set less by installation than by three decisions: how data is replicated and coordinated, how users authenticate, and whether backups have been proven by a restore. Replication design comes first. A replicated layout uses ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Confirm host placement, failure domains and network paths with your infrastructure team before the build starts, because a recovered replica syncs missing data automatically only when the cluster is laid out correctly from the beginning.
Authentication wiring is the second common delay. ClickHouse supports LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT authentication as external authenticators, and each one needs its own identity team, certificate or token issuer, and test accounts. Plan the access model in the users.xml or SQL access control configuration early, and check the ClickHouse access control documentation against the roles your analysts actually need. Backups are the third item. BACKUP and RESTORE cover local disk, S3-compatible storage and Azure Blob Storage, but the backup documentation warns that a backup never test-restored will probably not restore properly, so schedule restore tests on a spare cluster before go-live rather than treating them as a later task.
Upgrades and the test environment set the pace for the whole project. The ClickHouse production FAQ recommends stable releases for most production use, a pre-production environment with representative data and queries, and reading the changelog before upgrading, because minor backward-incompatible changes can occur. Ask your team to confirm which release line (stable or LTS) they will pin, check the current ClickHouse security policy for supported versions, and build a pre-production cluster with a realistic data volume before committing to a schedule. Any duration you put on the plan should come from your own measured test runs, not from this page.
Questions buyers ask before choosing ClickHouse or DuckDB
Can DuckDB replace a ClickHouse server for our analytics?
It can, for some workloads. DuckDB is embedded in a host process, so there is no server to install, patch or back up, which suits a notebook, a scheduled job or an application that analyzes data it can reach as files. It becomes a weaker fit when many users need to query at once, when data volume grows into a size that one process must scan repeatedly, or when dashboards need a shared, always-on endpoint. Map your current query patterns, user count and data volume against those three conditions before deciding. If you need a shared endpoint, a ClickHouse server is the more direct answer, and the two can also coexist, with DuckDB reading Parquet files that ClickHouse also queries.
Does DuckDB support multiple writers to the same database?
Only in limited ways. In read-write mode, one process can read and write a DuckDB database file. In READ_ONLY mode, several processes can read the file, but none can write. Within a single process, DuckDB supports multiple writer threads, and a write fails with a conflict error only when two threads change the same row at the same time. For several processes writing to one store, the documentation points to the Quack remote protocol, which was in beta as of DuckDB v1.5.2, or to DuckLake with PostgreSQL as the catalog database. Confirm the status of either option against your own write pattern before relying on it.
What does running a ClickHouse cluster require from our team?
A replicated cluster needs people who can operate several components, not only the database. ClickHouse replicates data with ReplicatedMergeTree tables coordinated by ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Your team also owns:
- Version management, since stable releases ship roughly monthly and LTS releases twice a year, with LTS support lasting a year
- Backup and restore, because replication does not protect against human error or corruption, and the backup documentation recommends regular restore tests on spare clusters
- Authentication integration, such as LDAP, Kerberos, X.509 or JWT through external authenticators
- Capacity planning and monitoring for merges, disks and query load
If these skills are not in-house, price them in before comparing the cluster with a single-node or DuckDB design.
Can our own team implement and run ClickHouse without outside help?
Often yes, if the team already runs Linux services, databases and backups, and has someone who will own the upgrade and restore schedule. The main gaps are usually replication design, Keeper operations, restore testing and integrating authentication with your directory. Assess those skills honestly, then decide which tasks you keep and which you hand to a partner. A common split is for the internal team to own day-to-day operations while an outside partner handles the initial build, hardening and documentation. DeployOpen implements and operates self-hosted platforms inside your own infrastructure, and its engagements are fixed-scope, so the split is agreed in writing before work starts.
What drives the effort and time for a ClickHouse or DuckDB deployment?
Effort depends mainly on topology, data and integration scope. A DuckDB job or application embedding is usually small, because it has no server to build. A ClickHouse deployment grows with the number of shards and replicas, the Keeper layout, the backup target (local disk, S3-compatible storage or Azure Blob Storage), the number of data sources and the authentication model. Other drivers include how many dashboards or applications connect, how much schema design and data migration is required, and how much security testing and compliance evidence you need. No timeline is set here. Ask for a schedule that lists each of these items as a separate milestone.
What does a fixed-scope engagement for ClickHouse cover?
A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts. For a ClickHouse build, the written scope should name the topology (single node or replicated cluster), the Keeper layout, the backup targets and restore test plan, the authentication integration, the upgrade procedure, the monitoring and the handover documentation. It should also say which items are excluded, such as data modeling for specific workloads or changes to source systems. Ongoing support, upgrades and continuous testing are available as separate retainers, so ask whether they are included or priced apart. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares should be checked by your independent assessor.
How should we cost a quote for ClickHouse or DuckDB work?
Split the quote into one-time and recurring components. One-time costs include design, build, migration, hardening, testing and documentation. Recurring costs include infrastructure you pay your cloud provider or data center for, staff time for upgrades and restore tests, and any retainer for support. Ask the provider to state each deliverable, its acceptance criteria, the environments covered and what is excluded. For infrastructure, ask for the Keeper node count and host sizing, the backup storage assumptions and the expected growth. DeployOpen does not publish a price list, and a quote follows from the written scope. Compare quotes on the same scope items rather than on totals alone.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, so a ClickHouse server and a DuckDB workflow can be sized against your users, data volume and compliance evidence before anything is installed. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.
How we scope
- Map which workloads are single-user jobs or notebooks and which need a shared ClickHouse server for concurrent users
- Record data volumes, query shapes, concurrency targets and where Parquet files live before choosing a layout
- Agree in writing which deliverables, environments and handover items are included before work starts
How we build
- Install and configure a ClickHouse server, or a replicated cluster with ClickHouse Keeper, in your own cloud, data center or air-gapped network
- Set up DuckDB workflows, including Parquet access and read-only sharing, and document where each one should stop
- Test queries and loads against representative data in a pre-production environment before any cutover
How we hand over
- Document configuration, access control, upgrade steps and the decision record behind the chosen architecture
- Configure BACKUP and RESTORE jobs and run a restore test on a spare environment with your team present
- Walk your administrators and analysts through runbooks for upgrades, failover checks and when to escalate
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review ClickHouse release notes and changelogs for backward-incompatible changes before each planned upgrade
- Keep compliance evidence such as backup records, restore test results and access reviews current for your assessors
