2026 ENGINE EVALUATION / SOURCE-LED
Compare Apache Doris with search engines, columnar OLAP systems, cloud warehouses and smaller analytical databases through the workload UnifyLogs is built for: high-volume operational data, fast retrieval, analytical SQL and long useful retention.
Evaluate your workloadThis page synthesizes material published by Apache Doris and VeloDB. It is not an independent benchmark or a universal performance guarantee. Results depend on versions, hardware, schemas, data distribution, tuning and query shape. Every claim links to its original methodology or case study.
AGENTLOGSBENCH / MAY 2026
AgentLogsBench ran six engines on one AWS m6i.8xlarge with the same logical schema and 20-query search-and-analytics workload. Load and footprint are raw values; cold and hot are normalized scores derived from the published per-query results.
| Engine | Load time ↓ | Stored footprint ↓ | Cold read score ↑ | Hot read score ↑ |
|---|---|---|---|---|
| Apache Doris | 4,396s | 57.94 GiB | 100/100 | 100/100 |
| ClickHouse | 2,755s | 50.10 GiB | 4/100 | 6/100 |
| Elasticsearch | 13,926s | 178.71 GiB | 98/100 | 32/100 |
| OpenSearch | 15,050s | 181.37 GiB | 72/100 | 33/100 |
| DuckDB | 10,111s | 100.26 GiB | 1/100 | 1/100 |
| PostgreSQL | 51,250s | 350.26 GiB | 0/100 | 0/100 |
Load and storage are raw values from the published 100M run. Read scores are comparative scores derived from the published cold/hot timings for the same 20 queries; this is not an independent benchmark.
AgentLogsBench favored ClickHouse load speed. In ClickBench’s May 10, 2026 untuned c6a.4xlarge runs, Doris loaded the same 100M-row dataset in 205s versus 283s and stored it in 13.78 GB versus 15.26 GB. That is 28% less load time and 10% less space in this test—not a universal write claim.
DECISION MATRIX
| Evaluation dimension | Apache Doris | ClickHouse | Elasticsearch / OpenSearch | Snowflake |
|---|---|---|---|---|
| Natural center of gravity | Real-time analytics combining retrieval, joins and high concurrency | High-throughput columnar OLAP and engineering analytics | Document search, relevance and log exploration | Cloud warehousing, reporting and broad analytical workloads |
| Log investigation | Full-text retrieval and analytical SQL in one engine | Strong aggregation; full-text search is a weaker fit in the cited Doris/VeloDB material | Mature search experience; deeper aggregation and joins can require another analytical layer | Useful for centralized analysis; not positioned for the strictest real-time investigation loop |
| Changing operational data | Primary-key model, real-time UPSERT and CDC-oriented ingestion | Merge-oriented updates and asynchronous mutations | Document updates are supported but index work can raise compute and storage cost | Warehouse-oriented pipelines; freshness depends on ingestion architecture |
| Complex SQL & joins | Cost-based optimizer, distributed joins and MySQL-compatible SQL | Very fast OLAP; complex join workloads need workload-specific validation | Query DSL first; SQL and multi-table analytics are not its primary strength | Strong SQL warehouse with mature ecosystem |
| Deployment posture | Apache 2.0; self-managed, cloud and on-prem paths | Open-source core and managed cloud | Self-managed and managed offerings with Elastic / OpenSearch ecosystems | Managed cloud service |
| Choose it when… | Search and analytics must share one real-time operational memory | Raw OLAP throughput is primary and the team owns the surrounding architecture | Search relevance and search-native UX matter more than complex analytical SQL | Enterprise warehousing and centralized reporting outweigh sub-second operational response |
SQL SUITE TOTALS / SF1000
Each bar is the sum of all query runtimes in that benchmark suite at SF1000—roughly a 1 TB scale factor. It is not one query, ingest throughput or QPS. Lower is faster; all values are seconds.
How each engine completes a fixed, join-heavy analytical SQL suite on its native storage format.
Log-search relevance, write speed, storage efficiency, concurrency or your production workload.
In VeloDB’s June 2026 single-node ASOF JOIN benchmark, a 100M × 100M time-series join completed in 0.97s on Doris, 1.93s on ClickHouse and 3.62s on DuckDB. The test used one 16-core / 64 GB machine, aligned parallelism and the fastest of three hot runs after one cold run.
ENGINE-BY-ENGINE
A strong choice for high-throughput event analytics, dashboards and teams comfortable operating the surrounding stack.
For UnifyLogs-shaped workloads, validate full-text retrieval, high-concurrency mixed queries, complex joins and update semantics—not only scan speed.
The strongest fit when relevance scoring, autocomplete, search suggestions and a search-native ecosystem are central requirements.
For long-retention observability, validate ingestion peaks, index footprint and analytical aggregation cost. Doris/VeloDB’s 2026 material positions unified search + SQL as the alternative.
A mature choice for centralized reporting, enterprise data sharing and broad warehouse workloads.
For operational loops, test end-to-end freshness, continuously arriving data and the cost of keeping low-latency compute available.
Strong candidates for streaming event analytics, time-oriented dashboards and high-concurrency serving workloads.
Validate complex joins, mutable data, full-text investigation and how many surrounding services the team must own.
A natural fit for ad-hoc SQL across open lake formats and multiple existing data sources without moving everything first.
Interactive lake queries, workload isolation and user-facing concurrency may need caching, materialization or a serving engine.
Excellent when the workload fits one machine or when transactional data and familiar SQL matter more than distributed log scale.
AgentLogsBench shows the long-tail JSON and 100M-row observability workload widening the gap; validate the scale boundary before adding infrastructure.
2026 FIELD SIGNAL
Advance.AI’s published January 2026 migration from OpenSearch reports more than 50% total cost reduction and 5× query improvement after moving its log platform to Apache Doris. That is one customer workload, not a promise for yours; use it to frame the questions your own pilot should answer.
V26-OSSOURCE LEDGER
We’ll help define a small, reproducible evaluation around your actual log volume, retention and investigation queries.
