Apache Doris

Editor’s note: This Apache Doris review evaluates open-source version 4.1.4.1, its documented setup and product behavior, and VeloDB Cloud’s October 2026 plans. It is not a hands-on performance test. I weigh pricing transparency, openness and exit costs, setup and operating effort, governance and development momentum.

Quick verdict: I recommend Apache Doris for engineering teams that need sub-second SQL on fresh, updatable data, with MySQL-protocol tooling and no license bill. The catch is operations: production starts at 3 FE + 3 BE nodes with 16 cores and 64 GB each, and upgrades go step by step, unless you pay VeloDB from $0.134 per vCPU-hour.

Key Takeaways

• Apache 2.0 with no license fee, about 16,000 GitHub stars and ASF top-level status since June 2022.
• VeloDB Cloud Standard costs $0.134 per vCPU-hour (SaaS) or $0.11 (BYOC) in US East, plus $300 in trial credits for 30 days.
• The production floor is 3 FE + 3 BE nodes on AVX2 CPUs, with 4 GB+ of BE RAM per core.
• Minor upgrades step one version at a time behind a metadata compatibility test, and FE out-of-memory reports are still open in 2026.
• Upserts, Kafka ingestion, Iceberg and Hudi catalogs and HNSW and IVF vector indexes share one engine.

In the Panoply directory, Doris sits under OLAP engine next to ClickHouse, Apache Druid and Apache Pinot.

In this review, I’ll take a closer look at Apache Doris’s pricing, setup, data models and AI features, so you can see exactly whether self-hosting or VeloDB fits.

Apache Doris Pros and Cons

How Much Does Apache Doris Cost?

Apache Doris costs nothing to license: the engine is Apache 2.0, so you pay for your own servers and the people who run them, or for VeloDB Cloud, sold by the company that hosts Doris’s release binaries. VeloDB prices vary by region; every figure below is for US East (N. Virginia).

• Apache Doris (free): for teams with a platform engineer who can self-host on Linux x86-64 or ARM64, on bare metal, VMs or Kubernetes.
• VeloDB Cloud Standard ($0.134 per vCPU-hour SaaS, $0.11 BYOC): for teams that want a managed cluster with multi-cluster compute, PrivateLink, manual and auto scaling, configurable backups and business-hours support.
• VeloDB Cloud Premium ($0.174 per vCPU-hour SaaS, $0.143 BYOC): for regulated teams that need SAML SSO, TDE with customer-managed keys, single tenancy and a 10-minute response on severity-0 incidents.
• VeloDB Enterprise (quote): for companies that self-manage on-prem, on VMs or on Kubernetes and want 36-month long-term support, a web UI and a visual cluster manager.

Plan	Compute (per vCPU-hour)	Storage	Cache	Where it runs
Apache Doris	Free (your hardware)	Your disks or object storage	Your disks	Self-hosted, Linux x86-64 or ARM64
VeloDB Cloud Standard, SaaS	$0.134	$0.00005 per GB-hour	$0.000332 per GB-hour	VeloDB’s cloud account
VeloDB Cloud Standard, BYOC	$0.11	Paid to your cloud provider	Paid to your cloud provider	Your own cloud account
VeloDB Cloud Premium, SaaS	$0.174	$0.00005 per GB-hour	$0.000332 per GB-hour	VeloDB’s cloud account, single tenancy
VeloDB Cloud Premium, BYOC	$0.143	Paid to your cloud provider	Paid to your cloud provider	Your own cloud account
VeloDB Enterprise	Quote	Your infrastructure	Your infrastructure	On-prem, VMs or Kubernetes

SaaS bills compute, storage and cache, while BYOC bills only VeloDB’s compute service fee and leaves servers and storage on your own cloud invoice. VeloDB’s estimator puts the FE group on a Small size (4 vCPU, 16 GB) at no charge.

What a Cluster Costs in a Month

The table assumes 730 hours a month with the cluster always on.

Setup (US East, always on)	Monthly cost
1 vCPU, Standard SaaS	$97.82
16 vCPU, Standard SaaS	$1,565.12 before storage and cache
16 vCPU, Standard BYOC	$1,284.80 service fee, plus your cloud bill
16 vCPU, Premium SaaS	$2,032.32 before storage and cache
1 TB stored, SaaS	$36.50
1 TB of cache, SaaS	$242.36

Idle clusters stop billing for compute, but storage keeps billing. Cache costs 6.6 times as much per GB as storage, so I’d size it to the hot data your dashboards touch, not to the full table set. ClickHouse Cloud’s Basic tier charges $0.2181 per compute unit-hour and $25.30 per TB-month of storage, about $11 less per stored terabyte than VeloDB SaaS, though a ClickHouse unit does not map directly to a vCPU.

Self-hosting has no software bill, but the documented production floor is six machines: 3 FE + 3 BE at 16 cores and 64 GB each, with 100 GB+ of SSD per FE. You pay for those servers plus the engineering time covered in the production section below.

Is Apache Doris Good Value for Money?

• Best value: if you already run Linux infrastructure, the engine, connectors and Kubernetes operator cost nothing, and the license sets no row or node limits.
• Managed premium: a 16-vCPU Standard SaaS warehouse at about $1,565 a month before storage and cache buys you out of upgrades and FE tuning.
• BYOC discount: BYOC compute is 18% cheaper than SaaS ($0.11 vs $0.134), but you still pay your cloud provider for servers and storage.
• Cost to watch: cache at $0.000332 per GB-hour is the highest per-GB rate on SaaS.

Reviewer’s Notes: I’d start with the Docker script on one AVX2 machine, or with VeloDB’s $300 in trial credits (valid 30 days) if you’d rather skip setup. Go self-hosted once a platform team can own six nodes and the upgrade procedure. Pick Standard BYOC when data must stay in your own VPC, and pay for Premium only when SAML SSO or customer-managed keys are a hard requirement.

My Experience With Apache Doris

Apache Doris asks for more before the first query than a single-binary engine: an AVX2 CPU, two process types (the FE frontend and the BE backend) and network settings that the quick start’s own FAQ spends several entries on.

Starting a Test Cluster

The fastest route is the project’s Docker script, which starts 1 FE and 1 BE on one machine:

curl -fsSL https://doris.apache.org/files/start-doris.sh | bash

To pin a release, append -s -- -v 4.1.0 to the bash call.

The documented dev sizing is 8 cores and 8 GB for the FE and 8 cores and 16 GB for the BE. The docs limit Docker to local dev and test, since data is lost when the container is destroyed.

For anything longer-lived, I’d use the tarball. You need Linux, JDK 17 (required since Doris 3.0) and a dedicated non-root user. You raise nofile to 1000000 in /etc/security/limits.conf and vm.max_map_count to 2000000, set priority_networks in both fe.conf and be.conf, run start_fe.sh --daemon and start_be.sh --daemon, then register the backend with ALTER SYSTEM ADD BACKEND "127.0.0.1:9050";.

Connecting and Creating a Table

Doris speaks the MySQL protocol on port 9030, so the stock mysql client is the console:

mysql -uroot -P9030 -h127.0.0.1 -e 'SELECT `host`, `join`, `alive` FROM frontends()'

The same query against backends() confirms the BE joined, and the FE’s HTTP port is 8030. A first Unique Key table looks like this:

CREATE DATABASE demo;
CREATE TABLE demo.users (
  user_id BIGINT,
  city VARCHAR(64),
  last_seen DATETIME
)
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 1
PROPERTIES ("replication_num" = "1");

The table model (Duplicate, Unique or Aggregate Key) and the merge-on-write choice are fixed at creation, so I’d settle both before loading real data.

Loading Data

For files, Stream Load pushes data over HTTP to the FE on port 8030 or to a BE on port 8040, and the label makes a retried load idempotent:

curl --location-trusted -u root: -H "label:users_load_01" -H "column_separator:," \
  -T users.csv http://127.0.0.1:8030/api/demo/users/_stream_load

Plain INSERT suits tiny volumes, and Group Commit is the documented path once more than 20 concurrent writers hit the same table.

Where First Runs Go Wrong

The quick-start FAQ names the usual failure: a BE showing Dead because priority_networks does not match the host, or because ports 9050, 9060, 8040 or 8060 are blocked. On WSL2, loopback is namespaced per distro, so the default 127.0.0.1/32 setting stops the BE from registering until you set the real eth0 segment in both config files. The quick start also still ends in NEXT-TODO placeholders.

ClickHouse installs as a single binary, while Doris makes you learn FE, BE and four BE ports first. I think that is a fair price for a design that separates planning and metadata from storage, but I’d plan the network ranges and open those ports before the first install, not after the first Dead backend. On a multi-machine test, I’d also run the frontends() and backends() checks after every node you add.

Data Models and Real-Time Ingestion

Every Doris table uses one of three models, and the model decides how cheap updates are:

• Duplicate Key: keeps every row as loaded, for raw logs and events; in 4.0 it is the only model that supports ANN vector indexes.
• Unique Key: primary-key upserts. Merge-on-write is the default and keeps reads fast, while merge-on-read suits write-heavy, read-light pipelines. Partial column updates need merge-on-write, and the mode cannot be changed by schema change later.
• Aggregate Key: pre-aggregates rows on load for fixed reporting.

Updatable tables are where Doris parts ways with ClickHouse, which favors append-heavy data. Mutable dimension tables synced from MySQL or PostgreSQL are a documented Doris use case: a customer or product table can take row-level upserts while dashboards keep reading it. Merge-on-write resolves duplicate keys at load time rather than at query time, the right trade for dashboards. Release 4.1 also accepts single JSON documents up to 100 MB for semi-structured payloads. Partition keys must be a subset of the key columns, so plan partitioning together with the key.

Load method	Source	Best for
Stream Load	Files over HTTP	High-throughput batch pushes
Routine Load	Kafka (CSV, JSON)	Continuous topic consumption, pulled by Doris
Doris Kafka Connector	Kafka (Avro, JSON, CSV, Protobuf)	Existing Kafka Connect pipelines
Flink Doris Connector, Flink CDC	Flink jobs, database change logs	Streaming ETL
Streaming Job	MySQL, PostgreSQL, S3	Continuous sync without Flink or Kafka
Broker Load	S3, OSS, HDFS	Large historical backfills
Group Commit	JDBC INSERT or Stream Load	More than 20 concurrent writers

The built-in Streaming Job has two modes. SQL Mapping Sync loads exactly-once into tables you pre-create, while Auto Table Creation Sync follows upstream DDL for a whole database at-least-once. Spark users get a separate first-party connector, Doris Streamloader handles local files, and INSERT INTO SELECT through a catalog pulls from lake tables.

For mirroring a MySQL database into Doris, I’d try the Streaming Job before adding Kafka and Flink to the stack. Routine Load stays the simpler choice when the data already lands in Kafka, since Doris pulls from the topic itself and no Connect cluster is needed.

Query Performance: Indexes, Materialized Views and Benchmarks

Doris runs a fully vectorized MPP engine with pipeline execution, runtime filters (In, Min/Max and Bloom) and an optimizer that combines cost-based, rule-based and history-based planning. Four index types decide how much data a query skips:

• Sorted prefix key: up to 3 columns, chosen in the table definition.
• Min/max: data skipping on range filters.
• BloomFilter: data skipping on equality filters.
• Inverted index: full-text search; 4.0 added a SEARCH() function with an Elasticsearch-style query string, and 4.1 adds BM25 scoring.

Single-table materialized views stay strongly consistent and are maintained automatically, while multi-table views refresh asynchronously on an in-cluster schedule or from an external scheduler. Release 4.0 added spill-to-disk for heavy ETL and multi-table views, TopN lazy materialization, and turned the SQL cache on by default.

The project’s benchmark page, at scale factor 1000, shows these total run times in seconds:

Suite	Doris	Redshift	Snowflake	ClickHouse
SSB	11.6	30.1	32.9	82.2
TPC-H	53.8	120.6	102.5	279.0
TPC-DS	173.8	395.5	464.6	1,913.9

The page does not state the hardware, and its full report link is marked Coming Soon, so I treat these numbers as direction, not proof. The same page shows Doris ahead of Elasticsearch, OpenSearch and ClickHouse on 100-million-row agent-observability workloads (2.3 s against OpenSearch’s 6.1 s on search and retrieval), a benchmark built around the project’s own use case. TPC-H and TPC-DS are join-heavy suites that suit Doris’s design; ClickHouse’s own strength, scans over wide event tables, is a different workload. VeloDB also claims 4.1 runs TPC-H 22.6% and TPC-DS 19.1% faster than 4.0.

The optimizer depends on statistics: open issues report a broadcast join chosen for tables with no collected statistics, which can push a BE out of memory, and a MultiDistinct aggregation on a near-unique column that can do the same. I’d run ANALYZE after every large load and keep statistics current on any table that joins, because Doris’s speed on joins depends on the planner knowing table sizes.

Lakehouse, Vector Search and AI Functions

Doris queries open table formats in place and, since 4.0, stores vector indexes next to its own tables.

Lakehouse Catalogs

Doris reads Hive, Iceberg, Hudi, Paimon and JDBC sources through catalogs, with metadata from Hive Metastore, AWS Glue or Unity Catalog. Trino connector plugins drop in for further sources, and Kudu, BigQuery and Delta Lake are already connected that way. Release 4.1 adds Iceberg V2 and V3 read and write, plus Paimon DDL in SQL.

Federation is the practical win: one query can join a Hive fact table with a MySQL dimension table, and a scheduled CREATE JOB with INSERT INTO can write results back to Iceberg. Next to lake engines such as Dremio and Trino, Doris’s difference is that the hot, frequently updated tables can live in its own storage with Unique Key upserts. Iceberg write-back also lowers exit costs, since another engine can read the same tables later.

Vector Search and AI Functions

Release 4.0 added an ANN index (HNSW) on ARRAY<FLOAT> NOT NULL columns with a fixed dimension, and the 4.0 release notes limit ANN retrieval to Duplicate Key tables, so check the 4.1 docs before planning vectors on a Unique Key table. Hybrid search pre-filters with inverted indexes before the TopN step, and predicates with no index fall back to exact brute-force search. AI Functions call LLMs straight from SQL.

Release 4.1 adds IVF and IVF_ON_DISK indexes plus PQ, INT8 and INT4 quantization, which cuts index memory to between 1/4 and 1/8. VeloDB’s own test reports about 900 QPS at 97% recall on 1 million vectors with 16 cores and 64 GB. An MCP Server project also sits under the apache organization on GitHub.

For RAG retrieval next to existing analytics tables at modest scale, I’d skip a separate vector database and use Doris. It is still an OLAP engine with vector indexes, not a dedicated vector store, and its one published vector benchmark is VeloDB’s own single-configuration test.

Running Apache Doris in Production

Architecture and Sizing

A Doris cluster has FE nodes (Master, Follower and Observer roles, with metadata replicated through BDB JE) and BE nodes that store data and run queries. Production guidance is at least 3 Follower FEs and 3 BEs, each with 16+ cores and 64 GB+ of RAM, plus 100 GB+ of SSD per FE. BE disk follows a formula: data volume x 3 replicas x 1.4, which covers LZ4 compression and a 40% compaction reserve. The docs recommend 10GbE networking.

Since 3.0, compute-storage decoupled mode runs stateless BEs in compute groups over shared storage (S3, HDFS, OSS, COS, OBS, MinIO or Ceph), with local disk used only as cache. The Doris Operator for Kubernetes is a separate apache/doris-operator project.

Upgrades and Stability

Patch versions roll directly, but minor versions step one at a time (3.0 to 3.1 to 3.2). Before each upgrade you back up Master FE metadata, run the metadata compatibility test on a spare machine and disable replica repair and balance, and clients need retry logic because nodes restart in sequence.

Open issues in 2026 show where the risk sits: an FE out-of-memory analysis on 3.1.4 (67199), DynamicPartitionScheduler entries leaking on DROP TABLE (62883) and a first_value/nth_value bug that can crash a BE once a window partition spans more than 257 blocks (68116). An earlier report (59889) tied FE memory growth to tablet count. Seven releases shipped between March 31 and September 29, 2026 across the 4.0 and 4.1 lines, and 4.1.5 release candidates are already tagged.

Doris began as Palo at Baidu, was open-sourced in 2017, entered the ASF in 2018 and became a top-level project in June 2022; VeloDB hosts its release binaries and sells the managed and supported editions. I’d budget a platform engineer for any self-hosted cluster, or pay for VeloDB Enterprise’s 36-month long-term support to upgrade less often.

How Does Apache Doris Compare to Competitors?

ClickHouse, StarRocks, Druid and Pinot are all Apache 2.0 like Doris, so workload fit, community size and the managed price decide the pick:

• ClickHouse: about 50,000 GitHub stars against Doris’s 16,000, a single-binary install and ClickHouse Cloud from $0.2181 per unit-hour plus $25.30 per TB-month. ClickHouse wins append-heavy event and log analytics and ecosystem size; Doris wins joins, primary-key upserts and MySQL-protocol tooling. ClickHouse’s Basic tier caps storage at 1 TB, so larger datasets start on Scale at $0.2985 per unit-hour.
• StarRocks: forked from Doris in 2020, Apache 2.0, about 12,000 stars, with 4.1.3 the current release. StarRocks says it has rewritten about 90% of the code since and leans toward lakehouse query acceleration. Its vendor CelerData rebranded to PhoenixAI in 2026 and offers 30-day trials but publishes no unit prices, while Doris has ASF governance and VeloDB’s public rate card.
• Apache Druid and Imply: built for time-partitioned event streams, with Imply Polaris Starter from $100 a month (25 GB) and Standard from $600 a month; usage-based instances run from $1.30 to $124.80 an hour. Druid wins when your data is a time series; Doris fits better when queries join several tables.
• Apache Pinot: aimed at user-facing analytics, with StarTree offering a free tier on AWS with no time limit but no published paid prices. Pinot wins high-concurrency queries behind customer-facing apps, but it has the smallest community of the group at about 6,000 stars, while Doris’s MySQL protocol lets Tableau, Power BI and Superset connect as they would to MySQL.
• BigQuery and Snowflake: no cluster to run at all. BigQuery charges $6.25 per TiB scanned with the first 1 TiB free each month, which turns unpredictable when dashboards rescan tables all day. They win when nobody on the team wants to run a cluster; Doris wins on fixed, predictable compute for always-on dashboards, either self-hosted or on VeloDB’s per-vCPU rate.

Tool	License	Managed price (entry)	Best for
Apache Doris	Apache 2.0	VeloDB Standard $0.134 per vCPU-hour (SaaS)	Joins and upserts on fresh data
ClickHouse	Apache 2.0	$0.2181 per unit-hour + $25.30 per TB-month	Append-heavy event and log analytics
StarRocks	Apache 2.0	No public prices (PhoenixAI)	Lakehouse query acceleration
Apache Druid	Apache 2.0	Imply Polaris from $100 a month	Time-series event streams
Apache Pinot	Apache 2.0	StarTree free tier on AWS; paid prices not published	User-facing analytics
BigQuery	Proprietary	$6.25 per TiB scanned, 1 TiB free monthly	No infrastructure to run

How I Reviewed Apache Doris

I evaluated Apache Doris on the five areas Panoply weighs for every data tool:

• Pricing transparency: VeloDB’s per-vCPU, storage and cache rates in US East, and the hardware floor for self-hosting.
• Openness and exit costs: the Apache 2.0 license, MySQL-protocol access and Iceberg write-back.
• Setup and operating effort: the quick start, sizing guidance and the upgrade procedure.
• Governance: ASF stewardship and VeloDB’s role as the company behind the managed and supported editions.
• Development momentum: release cadence across the 4.0 and 4.1 lines, the open issue tracker and the memory and upgrade reports on it.

I weighed Doris against ClickHouse, StarRocks, Druid, Pinot and BigQuery on the same five areas, and on the workloads each one serves best.

Prices current as of October 2026.

Should You Build Your Real-Time Analytics on Apache Doris?

Yes, if you need sub-second SQL on fresh, updatable data, joins across fact and dimension tables and MySQL-protocol tooling, and you have people to run a six-node cluster. If you don’t, VeloDB Cloud at $0.134 per vCPU-hour removes the upgrade and FE-memory work, at about $1,565 a month for a 16-vCPU warehouse before storage and cache, or about $1,285 on BYOC plus your own cloud bill.

Pick ClickHouse instead for append-only event analytics with the biggest ecosystem, and BigQuery or Snowflake if you don’t want to run anything. StarRocks is the closest like-for-like alternative, but its vendor publishes no prices, so budgeting it means a sales call.

Run the Docker script on an AVX2 machine with 16 GB of RAM, load a day of your own data with Stream Load, and test your worst join after running ANALYZE. If that query comes back fast enough, size the production cluster; if you’d rather not run the cluster, spend VeloDB’s $300 in trial credits on the same test. Get Apache Doris at doris.apache.org.

FAQ

Is Apache Doris free?

Yes. Apache Doris is released under the Apache 2.0 license with no license fee and no row or node limits. You pay for servers and the time to run them, or for VeloDB Cloud, which starts at $0.134 per vCPU-hour on Standard SaaS in US East ($0.11 on BYOC), plus storage at $0.00005 per GB-hour.

Is Apache Doris better than ClickHouse?

For joins and updates, usually yes. Doris is stronger on joins, primary-key upserts and MySQL compatibility, and the project’s own benchmarks put it ahead on SSB, TPC-H and TPC-DS. ClickHouse is the better pick for append-heavy event analytics and has a far larger community, about 50,000 GitHub stars to Doris’s 16,000.

What is the difference between Apache Doris and StarRocks?

StarRocks forked from Doris in 2020, and both are now Apache 2.0. Doris is governed by the Apache Software Foundation, and VeloDB sells managed Doris with public per-vCPU prices. StarRocks is backed by CelerData, which rebranded to PhoenixAI in 2026 and publishes no unit prices.

What hardware does Apache Doris need?

Apache Doris needs a CPU with AVX2 support on Linux x86-64 or ARM64, plus JDK 17 for version 3.0 and later. A test setup can run 1 FE and 1 BE on one server (8 cores, 16 GB for the BE). Production guidance is 3 FE and 3 BE nodes with 16+ cores and 64 GB+ of RAM each.

Does Apache Doris support vector search?

Yes. Doris 4.0 added HNSW vector indexes on ARRAY<FLOAT> columns, with ANN retrieval limited to Duplicate Key tables in that release, plus hybrid search with inverted indexes and AI Functions that call LLMs from SQL. Doris 4.1 adds IVF and IVF_ON_DISK indexes and PQ, INT8 and INT4 quantization, which cuts index memory to between 1/4 and 1/8.