Searching for which database is faster for analytical queries can produce contradictory answers on the same page of results. Those answers can all be technically correct. DuckDB has a genuine advantage for local exploration, single-node benchmarks show a close contest, and distributed, high-concurrency workloads demand a different architecture.
How DuckDB's in-process design gives it a structural edge on a single machine
DuckDB runs inside the process that uses it, so it needs no separate database server. For a practitioner working in a notebook, that makes the database part of the analysis environment. When the data already exists in local files, the path from opening the notebook to asking a question can be direct. There is no server deployment between the analyst and the first query.
For local Parquet, CSV, or JSON files, DuckDB can begin returning results without an ingestion step. That changes what “faster” means in exploratory work. Query execution is only part of the elapsed time when an alternative requires loading the data before analysis can start. A system that avoids that preparation can deliver an answer sooner by removing work, even when the execution engines are closely matched.
This distinction is especially useful for ad-hoc analysis, where the question may be temporary and the files are already in hand. The analyst does not need to establish a serving system simply to investigate them. Setup is part of the workload. A comparison that starts only after both systems have prepared their data excludes the very step that makes DuckDB attractive in this setting.
The architectural benefit nevertheless has a boundary. When analytics runs inside an application process, it shares the process that the application needs to keep running. That setup works differently for a local analytical session than for a service that handles concurrent requests. A benchmark that submits isolated queries does not test how the application process behaves under concurrent requests. Before treating local speed as evidence of production capacity, the comparison therefore has to distinguish an engine’s execution time from its behaviour under shared load.
What single-node benchmarks actually show — and what they leave out
Single-node benchmarks place the competing engines much closer together than a categorical claim of superiority suggests. The differences are small enough that changes to the workload, schema design, and hardware often affect performance more than changing the database. A result describes how a particular configuration handled a particular set of queries. Changing either side of that pairing can change what the result tells a practitioner about the intended deployment.
ClickBench provides public results, scripts, and a dataset that make its tests reproducible. That transparency gives the evidence practical value because the comparison is not just an unsupported claim about speed. Reproducibility does not, however, widen the question being tested. An engine’s results on an analytical suite show how it performs on that suite under the stated conditions. It is not automatically evidence about a service receiving queries and writes from many users.
The distinction is between the machine being tested and the workload being imposed on it. A single machine can be the setting for different kinds of tests, but isolated query timings do not measure concurrent operation. In particular, the single-node query comparisons at issue do not establish ingestion throughput or multi-tenant query isolation. Those properties need evidence about work arriving together, rather than a sequence of execution times considered separately.
Even load time and ingestion throughput answer different questions. A benchmark can report how long it took to prepare its dataset without establishing how a system performs while new events arrive and users continue querying. Likewise, a fast analytical query does not establish that unrelated tenants will remain unaffected by a demanding request. These are different units of comparison. Treating them as interchangeable turns a valid benchmark into an invalid deployment conclusion.
Single-node results establish that DuckDB is a serious analytical engine and that engine choice alone may not explain a large performance difference on one host. They do not crown a production winner. For a team whose workload really is local and isolated, those results are directly relevant. For a team building a shared analytical service, they do not establish that fast individual queries will yield reliable service performance.
The concurrency cliff where DuckDB's model breaks down
A poorly bounded query can exhaust host memory and take down the application running it. The failure extends beyond a slow answer. In this setting, the analytical engine and its host application do not have separate process boundaries protecting the application from that query.
An exploratory session and a shared service may execute similar SQL, but they do not make the same promise to other users. A service must account for requests that overlap and for the effect one request can have on another. Isolation becomes part of the performance requirement.
DuckDB has no built-in streaming ingestion layer, such as a native Kafka connector or an event-driven API. Writes typically arrive through files, batch loads, or programmatic micro-batch inserts using its Appender API. The engine is not the whole ingestion system. High-frequency workloads with logs, traces, or event streams thus need an external layer before DuckDB can query their data.
The DuckLake extension now also supports continuous streaming ingestion, which qualifies any blanket claim that the ecosystem is limited to batch analysis. That development expands the available architecture, but it does not make the distinction between the core engine and the ingestion layer disappear. The complete data path still counts. A comparison of production performance has to include both how data becomes queryable and how quickly an engine reads data that is already available.
For distributed, high-concurrency server workloads, the advantage consequently shifts from bare in-process DuckDB toward a distributed OLAP server. The relevant workload includes concurrent queries, ongoing ingestion, and the separation of unrelated users’ work. Improving an isolated query time does not by itself supply those properties. DuckDB’s ecosystem has tackled those needs by changing how the engine is deployed.
How the DuckDB ecosystem has tried to close the scale gap — and where it still has limits
MotherDuck’s “hypertenancy” model gives every user, service account, or agent a dedicated DuckDB instance called a “Duckling”. Each instance spins up in around 100ms and shuts down when idle. The isolation boundary changes as a result. Rather than placing all tenants in one shared process, the model isolates concurrency failures to a single tenant.
Together AI runs 128 concurrent self-service users across 40 read-scaling Duckling replicas through MotherDuck, with AI agents querying unconstrained. That example provides concrete production evidence for multi-tenant use. It also identifies the architecture doing the work. The deployment spreads requests across isolated instances and read-scaling replicas instead of making one embedded instance handle them all. The evidence therefore supports hypertenancy as a way to serve concurrent users while offering only limited conclusions about the capacity of standalone DuckDB.
DuckLake extends MotherDuck’s reach to petabyte-scale lakehouse workloads on S3, GCS, or Azure. MotherDuck can also query existing Iceberg and Delta Lake tables directly without ingestion. These capabilities address another part of the scale question. They allow the analysis to reach beyond local files and avoid a separate ingestion step for those existing tables. The attempt to close the gap is substantial even though it does not adopt a distributed execution model.
Dataset scale and concurrency nevertheless remain separate properties. Access to a petabyte-scale lakehouse does not, on its own, establish how a deployment handles simultaneous work from many departments. Hypertenancy answers that problem through per-tenant isolation. Teams that expect MotherDuck to absorb the same multi-department concurrent load as a distributed OLAP server without redesigning around that isolation can encounter contention.
ClickStack added a beta LLM observability dashboard in August 2026 covering token usage, model calls, tool calls, cache hits, error rates, and response times. It supports OpenTelemetry GenAI semantic conventions, OpenLLMetry, OpenInference, and Vercel AI SDK telemetry, with no dedicated tables or ingestion changes required. That workflow evidence shows why a production choice can depend on how incoming telemetry becomes data that can be analysed, while a local benchmark tests only one part of that path.
The three-answer framework practitioners can apply to their own stack
Practitioners can turn these distinctions into a decision by identifying the workload before comparing execution times. The first answer applies to a single machine, files already in hand, and ad-hoc or exploratory analysis. DuckDB is faster and far simpler for that task because it requires no server, no schema setup, and no ingestion step. The comparison includes the time needed to begin.
The second answer applies when the question is specifically about analytical execution on one node under comparable conditions. Here, the engines are closely matched, and the result depends on the queries, schema, and hardware. The benchmark is useful within that boundary. A team evaluating this workload should treat the relevant query mix as the deciding evidence rather than importing a broad claim from a different deployment.
The third answer applies to a distributed service with high concurrency, continuing data arrival, and multiple tenants. A distributed OLAP server is the stronger fit for that workload than bare in-process DuckDB. The unit of evaluation is the service. MotherDuck can change the choice for teams willing to use per-tenant isolation, and Together AI shows that this approach can handle concurrent production use. That option belongs in the comparison as a distinct architecture, with its own commitment to how tenants and replicas are organised.
If the work begins with files and ends with an analyst’s answer, choose DuckDB for its direct path to the data. If the work must keep accepting events and answering concurrent users, evaluate the ingestion and isolation architecture as part of the database choice. For a single-node execution contest, use results from tests of the workload at hand.