Apache Doris (real-time OLAP)
Low-latency, high-concurrency SQL over your Iceberg lakehouse.
Apache Doris is a real-time, massively-parallel (MPP) OLAP engine that runs over your Iceberg lakehouse. It joins Trino, Spark, and DuckDB as a native Lakehouse engine, built for the cases where query latency and the number of concurrent users both matter.
Doris currently carries a Beta badge in the engine picker. It's a full, queryable engine across the SQL editor, notebooks, and Databasin One — the badge just signals it's the newest of the bunch.
What Doris is good for
Reach for Doris when you want interactive analytics that stay fast under load:
- Low-latency queries on dashboards and exploratory analysis, where a multi-second wait is too slow.
- High concurrency — many people (or many dashboard tiles) hitting the same data at once.
- BI workloads that connect over a standard wire protocol.
Trino is still the best all-round choice for ad-hoc SQL and cross-catalog federation. Doris is the one to pick when the workload is read-heavy, latency-sensitive, and concurrent — classic real-time OLAP.
How Doris is different
Doris speaks the MySQL wire protocol rather than Trino's protocol. That's invisible when you write SQL, but it does change how each surface reaches it:
- SQL editor — Doris is a first-class connection with streaming parity to Trino. Results stream in as they're produced, exactly like a Trino query, and the same toolbar (history, saved queries, object explorer, limit-results) all apply.
- Notebooks — notebooks reach Doris through a MySQL-protocol client, so a Doris notebook connects a little differently under the hood while the SQL you write stays the same.
- Databasin One — the agent can query Doris too, over the same MySQL-protocol path.
So the short version: in the SQL editor, working with Doris feels just like Trino; in notebooks and Databasin One, Doris is reached over its MySQL protocol.
Clusters and scale-to-zero
Like Trino and Spark, Doris answers queries from a running cluster — its lifecycle lives at /doris/clusters/* and mirrors the other engines, with a few Doris-specific details:
- FE and CN nodes. A Doris cluster is a Frontend (FE) node plus one or more Compute Nodes (CN) — Doris's equivalent of a coordinator and its workers. They use the same size tiers as the other Lakehouse engines (X-Small through Extra Large).
- Scale-to-zero. Compute can scale all the way down to zero when idle and is woken automatically on the first query — so you only pay while you're actually running work.
- IP whitelisting. Because Doris exposes a MySQL-protocol port for BI tools, a cluster can restrict access to specific IP addresses or CIDR ranges.
The wake/sleep behavior, sizing tiers, and credit-mode limits are shared with the other engines — see Clusters, wake and sleep for the full picture.
Iceberg, by default
New Doris clusters use Iceberg as their table format, the same default as Trino and Spark (since 2026-03-24). That means schema evolution, time travel, and reads that are compatible across engines — a table written by Spark is queryable from Doris without translation.