Open-source OLAP databases
Start with the queries and the freshness target.
Scanning Parquet on a laptop and serving concurrent customer dashboards are both analytical workloads. They justify different architectures. I would compare query shape, updates, ingestion lag and recovery before comparing headline throughput.
-
Ingestion and batching
Streams, CDC logs or object-storage files land in bounded batches so writes do not overwhelm background merges or segment creation.
-
Columnar layout and indexes
Data is sorted, compressed and partitioned into columnar parts, segments or external Parquet files with zone maps and skipping indexes.
-
Vectorized execution
Single-process or distributed MPP coordinators prune partitions, push down predicates and execute vectorized scans, aggregations and joins.
-
Concurrency and recovery
Materialized views, replicas, snapshots and deep storage govern how many concurrent readers the system serves and how fast a node recovers.
Comparison at a glance
Sources reviewed: October 2026, from official repositories, releases and documentation. The table mixes distributed servers, an embedded engine and a PostgreSQL extension. Each rating (1–5) is an editorial readiness score for the fit in its row; the breakdown sits under the table and the method on the Blog index.
| Project | Rating | Core license | I would shortlist it for | Main constraint |
|---|---|---|---|---|
| DuckDB 1.5.6 | MIT | Embedded analytics, Parquet exploration and bounded batch jobs | The native in-process database has a single writer process; shared service designs need a separate plan. | |
| ClickHouse 26.8.27.9 LTS | Apache-2.0 | Columnar SQL over events and analytical datasets | Table layout, ingestion batches, merges and replication need deliberate design. | |
| Apache Doris 4.1.4.1 | Apache-2.0; dependency exceptions | Shared SQL analytics, reporting and lake queries | Own frontend metadata and backend data; deployment mode changes the components. | |
| StarRocks 4.1.6 | Apache-2.0 | BI, joins, materialized views and lake analytics | Storage/compute topology and refresh behavior are part of the design. | |
| Trino 483 | Apache-2.0 | Federated SQL over lakehouse tables and existing databases, without loading the data first | It stores no data: file layout, the catalog and each connector set its performance. | |
| ParadeDB 0.26.1 | AGPLv3 | Search and analytical aggregations inside PostgreSQL | An extension sharing PostgreSQL resources, not a standalone distributed warehouse. | |
| Apache Druid 38.0.0 | Apache-2.0 | Time-oriented event analytics with continuous ingestion | Segments, deep storage and metadata add distinct recovery responsibilities. | |
| Apache Pinot 1.5.1 | Apache-2.0 | Analytics exposed inside an application | Index selection and real-time/offline table design shape the result. |
How each rating was computed
Five criteria worth 0, 0.5 or 1 point each. Caps: archived upstream 1, no stable release in 18 months 2, no general-availability release 2.5. "Open edition" scores what the open-source edition includes without a paid tier. Scored in October 2026 from the official repository, releases and documentation; the method is on the Blog index.
| Project | Maintenance | Open edition | Maturity | Operations | Interoperability | Rating |
|---|---|---|---|---|---|---|
| DuckDB | 1 | 1 | 1 | 1 | 1 | 5 |
| ClickHouse | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| Apache Doris | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| StarRocks | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| Trino | 1 | 1 | 1 | 0.5 | 1 | 4.5 |
| ParadeDB | 1 | 1 | 0.5 | 1 | 1 | 4.5 |
| Apache Druid | 1 | 1 | 1 | 0 | 1 | 4 |
| OpenObserve | 1 | 0.5 | 0.5 | 1 | 1 | 4 |
| Apache Pinot | 1 | 1 | 1 | 0 | 0.5 | 3.5 |
AGPLv3 is open source; Apache, MIT and AGPL make different licensing choices. Identify the exact build and extensions being adopted. Doris explicitly documents third-party licensing exceptions. Commercial cloud editions are outside these core-license labels.
Start with the workload
- Local files or an analytical step inside an application: start with DuckDB. Measure memory and temporary-disk use before introducing a cluster. A daily report does not automatically require a permanent database service.
- A shared BI platform with joins and changing dimensions: compare Doris and StarRocks with representative SQL and the actual BI client. Include ClickHouse when its ingestion and table model fit. Protocol compatibility alone does not establish identical SQL semantics.
- Event-heavy dashboards and operational analytics: compare ClickHouse, Druid and Pinot. Reproduce time ranges, filter selectivity, concurrent users and ingestion while queries run.
- SQL over lakehouse tables that stay in object storage: start with Trino when Iceberg, Delta or Hudi tables remain the source of truth and several engines must read them. Choose ClickHouse, Doris or StarRocks when low-latency serving justifies loading the data into their own storage.
- Application search and aggregates over existing PostgreSQL data: evaluate ParadeDB before creating another ingestion pipeline. The decision must include transactional workload contention and extension upgrades.
I would not rank these by a single published latency number. A pre-aggregated dataset, a warm cache and an exact join over raw data are different tests.
Version and operational notes
Trino — a query engine, not a store
Reviewed: 483, released 2026-07-18. A coordinator plans each query and workers read the data in place through connectors for Iceberg, Delta Lake, Hudi and relational databases. Nothing is loaded or stored, so the catalog, file sizes and partitioning decide most of the result. Commercial distributions add features that are not scored here.
Query a partitioned Iceberg table while its snapshots change, measure planning time on a large metadata tree, and stop a worker mid-query with fault-tolerant execution enabled. Verify access control through the plugin you will actually run.
ClickHouse — table design is an operating decision
The introduction describes columnar SQL, joins and asynchronous replication. Its MergeTree family makes ordering, partitions and background merges relevant to ingestion and query behavior. 26.8 is the August LTS line; 26.3 LTS still receives patches, so choose the line by support window rather than newest feature.
I would test the real insert batch size, late corrections and deletes alongside queries. Measure merge pressure and replica lag. Replication provides additional copies; an independently restorable backup still needs its own rehearsal.
Doris — include metadata and the deployment mode
The reviewed architecture describes frontend and backend responsibilities and distinguishes integrated from separated storage/compute deployments.
I would replay representative joins and updates with the production client's SQL, then recover frontend metadata and data together. A shorter component list is useful only if the team understands its failure domains. Validate dependency licenses in the chosen binary.
StarRocks — test views and lake access with changing data
The project overview describes MPP execution, a columnar engine, materialized views, streaming and batch ingestion, and access to data lakes.
I would compare direct queries with materialized views after a late dimension update. Record refresh lag and extra storage, not only query speed. For lake access, include catalog availability, object-store requests and the cost of cold reads. The reviewed 4.1.6 dates from 2026-09-30; 4.0.16 (tagged 2026-09-29) is the maintained previous line, so pin the exact release you deploy.
Druid — protect the segments and their catalog
Druid's deep storage holds durable segments outside the query processes. Its architecture separates ingestion and serving responsibilities.
I would verify ingestion lag, late-event handling and recovery after losing serving nodes. Protect metadata as well as deep storage. If rollup is used, document the detail discarded at ingestion and whether the raw source can reconstruct it.
Pinot — application traffic should drive the trial
The project targets analytical queries in applications and supports batch and streaming ingestion with multiple index types.
I would reproduce skewed tenants, selective filters and concurrent requests while ingestion continues. Test the transition between offline and real-time data for gaps or double counting. Include segment management and cluster recovery in the trial, not just one SQL endpoint.
DuckDB — be precise about concurrency
The concurrency reference distinguishes the native in-process model from other architectures: one process can read and write, or multiple processes can open read-only. Multiple writer threads within that process are supported.
The same reference describes Quack as a beta remote protocol and DuckLake with a PostgreSQL catalog as another route to concurrent writers. Those add different components and storage contracts. I would not generalize the native-file restriction to every DuckDB-based system.
ParadeDB — an AGPL option within PostgreSQL
The reviewed source
adds full-text search and aggregations through the pg_search extension,
using Tantivy and DataFusion. Its deployment boundary remains PostgreSQL.
I would test the supported PostgreSQL/extension combination, index maintenance and mixed transaction/search traffic. Keep a recovery plan for both the database and extension. Treat this as a search-and-analytics alternative for existing data, not evidence of distributed warehouse parity.
A specialized AGPL candidate
OpenObserve is an AGPLv3 observability platform for logs, metrics and traces with analytical querying. I would evaluate it when the requirement is telemetry search, retention and dashboards.
Its scope differs from a general BI warehouse. Verify the chosen release and the OSS/enterprise boundary; the reviewed 1.1.0 (released 2026-10-14) belongs to its first general-availability line, 1.x, which began on 2026-09-11 and moved SLOs and synthetic monitoring into the open edition. An AGPL requirement should narrow a technically suitable shortlist, not turn different products into equivalent databases.
A trial that can change the decision
Use the same event dataset and customer dimension for every candidate. Document partitioning, indexes, replication, hardware and all preprocessing.
- Correctness: reconcile counts and sums after duplicate ingestion, a late event, an updated dimension and a deletion. Distinguish exact from approximate aggregates.
- Freshness: measure source-event-to-query visibility as well as query p50/p95/p99. A quick query over stale data may miss the business objective.
- Concurrency: run the real query mix during ingestion and maintenance; report cold and warm caches separately.
- Recovery: restore data, catalog, permissions and ingestion offsets into a clean environment. Compare recovered results with the source.
- Cost: include replicas, indexes, temporary disk, object-store traffic, compaction and operator time. Fix acceptable thresholds before testing.
Complete the data path
An object store can hold raw inputs and backups. An orchestrator coordinates loads and rebuilds. Vector databases address another retrieval workload. Keep those responsibilities visible when deciding whether another service is justified.
Transformation defines the models that feed these engines; BI presents their results. Compare lakehouse formats when table state spans engines, and graph databases when traversing relationships is central.