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 — every Databasin surface now treats Doris as a first-class warehouse:
- SQL editor — a first-class connection with streaming parity to Trino. Results stream in as they're produced, and the whole toolbar (history, saved queries, object explorer, limit results) applies.
- Notebooks — Doris cells run over the MySQL-protocol client, with the SQL you write unchanged.
- Databasin One — the agent queries Doris directly. The sidebar shows a real connection dot, a cluster bar, and a Start button with genuine wake progress — so you can tell a cold cluster from a broken one, and wake it without leaving the chat.
- Data Exchange and Metrics Library — Doris is selectable as a warehouse.
- Semantic models — build and deploy them onto Doris like any other engine.
It did, and that was wrong. Doris was classified as a managed warehouse, which suppressed the status UI entirely: no dot, no Start button, and a status permanently faked as ready. A side effect was that the catalog list could get stuck on a stale set. Both are fixed — Doris now goes through the same real status poll as Trino.
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.
Live sources on Doris
Doris can host the Databasin live plugin, the same as Trino — so a source you make live is queryable from a Doris cluster under the live catalog, with nothing synced. See Live connections.
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.