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.
Sources reviewed: 2026-09-06. This is an assessment of official sources, not a benchmark. Recommendations below are my interpretation of workload fit. Version links identify the reviewed code; rolling documentation can describe newer capabilities.
Comparison at a glance
OLAP describes analytical processing, not one deployment model. The table includes distributed servers, an embedded engine and a PostgreSQL extension; their operating boundaries are explicit.
Rating (1–5): an editorial readiness score for the fit named in the same row, dated 2026-09-06. It adds five criteria worth 0, 0.5 or 1 point each: maintenance, open edition (what the open-source edition includes without a paid tier), maturity and community, operating scope and interoperability, with caps for archived, stale or prerelease projects. The breakdown sits under the table and the method on the Blog index. A rating is not a benchmark or a universal ranking; the workload sections still decide.
| Project | Rating | Core license | I would shortlist it for | Main constraint |
|---|---|---|---|---|
| ClickHouse 26.8.2.7 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.3 | 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.3 | Apache-2.0 | BI, joins, materialized views and lake analytics | Storage/compute topology and refresh behavior are part of the design. | |
| Apache Druid 37.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. | |
| DuckDB 1.5.5 | 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. | |
| ParadeDB 0.25.6 | AGPLv3 | Search and analytical aggregations inside PostgreSQL | An extension sharing PostgreSQL resources, not a standalone distributed warehouse. |
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 on 2026-09-06 from the official repository, releases and documentation; the method is on the Blog index.
| Project | Maintenance | Open edition | Maturity | Operations | Interoperability | Rating |
|---|---|---|---|---|---|---|
| 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 |
| Apache Druid | 1 | 1 | 1 | 0 | 1 | 4 |
| Apache Pinot | 1 | 1 | 1 | 0 | 0.5 | 3.5 |
| DuckDB | 1 | 1 | 1 | 1 | 1 | 5 |
| ParadeDB | 1 | 1 | 0.5 | 1 | 1 | 4.5 |
| OpenObserve | 1 | 0.5 | 0.5 | 1 | 1 | 4 |
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.
- 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
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.3 dates from 2026-07-14; 4.0.14 (2026-08-27) 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.0.0-rc2 is a prerelease. 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.
The local SQL explorer shows logical query stages on fictional data. Use it to inspect the concepts, not to estimate any engine's performance.
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.