Real-time OLAP in 2026: revisit ClickHouse, Apache Doris and StarRocks before you build another dashboard warehouse

Manoj Shukla
October 12, 2026

Picture an ecommerce and last-mile logistics platform in Bengaluru (an invented example, not a real client). Order capture and inventory still run on PostgreSQL 16. Product events, clickstream and courier GPS already land in Kafka. The analytics team built dashboards on a nightly dump into the same PostgreSQL replica. Those dashboards now time out during festival sales, and every new report asks for multi-day joins across events, orders and city-level inventory. One architect wants ClickHouse for fast scans, a second likes Apache Doris because the BI tools already speak MySQL, and a third prefers StarRocks for primary-key upserts that track near-real-time stock.

All three are columnar OLAP engines for analytical SQL at speed. They differ in how they store updates, how strong multi-table joins are, how close they stay to the MySQL protocol, how they talk to Iceberg and other lake formats, and how you operate them day to day. This post compares ClickHouse, Apache Doris and StarRocks on those points, and asks the question that should come first: do you need a separate OLAP engine at all? Facts come from release notes, official docs, licence texts and CVE records, checked on 12 October 2026. The drill near the end is my own run on this Linux box.

The short version

A separate OLAP engine helps when dashboard and ad-hoc SQL on event or fact tables outgrow PostgreSQL replicas, and when you need seconds-level freshness from streams. It does not replace your OLTP database, and it is the wrong tool for metrics time series that belong in a Prometheus long-term store.
ClickHouse v26.9.16.11 (11 October 2026) is the current stable tip I downloaded; v26.8 is an LTS line (v26.8.24.9 also published on 11 October). The OSS core is Apache 2.0. Updates often use ReplacingMergeTree with query-time FINAL, which is eventual until merges or FINAL run.
Apache Doris 4.1.4.1 (29 September 2026) is labelled Latest on the download page; 4.0.8 (14 August 2026) is labelled Stable for production. Integrated FE+BE and decoupled storage-compute modes both exist. Unique Key tables upsert by primary key. Apache 2.0.
StarRocks 4.1.6 (30 September 2026) is the current 4.1 tip; 4.0.16 shipped the same day on the 4.0 line. FE+BE (shared-nothing) or FE+CN (shared-data). Primary Key tables use Delete+Insert with a primary-key index. Apache 2.0 since late 2022.
Doris and StarRocks speak the MySQL protocol on the query port. ClickHouse has native, HTTP and optional MySQL ports; analytical SQL dialects still differ.
In my drill with the same 500,000-row CSV, all three loaded, aggregated and kept data across a kill and restart. ClickHouse insert wall time was about 0.25 s; StarRocks stream load about 0.38 s; Doris stream load about 0.52 s on this single box. Those numbers are a smoke test, not a benchmark.

Where things stand on 12 October 2026

Dates are the release dates printed on each project’s notes or GitHub release pages. GitHub timestamps, converted to IST, agree within a day.

Project

Latest release

Release type and support

Licence

ClickHouse

v26.9.16.11-stable on 11 October 2026

Monthly stable tip; docs recommend stable by default, with the three newest stable lines receiving diagnostics and bug-fix backports

Apache 2.0 (OSS core)

ClickHouse

v26.8.24.9-lts on 11 October 2026

LTS line (LTS releases twice a year, supported for about a year after initial release)

Apache 2.0

Apache Doris

4.1.4.1 on 29 September 2026

Latest branch (features plus fixes); 4.1.5 only as RC on 11 October

Apache 2.0

Apache Doris

4.0.8 on 14 August 2026

Stable branch recommended for production on the download page

Apache 2.0

StarRocks

4.1.6 on 30 September 2026

Current 4.1 tip

Apache 2.0

StarRocks

4.0.16 on 30 September 2026

Current 4.0 tip

Apache 2.0

Date

Event

2 June 2016

ClickHouse repository created on GitHub

10 August 2017

Apache Doris repository created on GitHub

4 September 2021

StarRocks repository created on GitHub

December 2022

StarRocks moves from Elastic License to Apache 2.0 (project history / PR record)

14 October 2025

Apache Doris 4.0.0

9 April 2026

StarRocks 4.1.0

21 April 2026

Apache Doris 4.1.0

14 August 2026

Apache Doris 4.0.8 (Stable)

23 September 2026

ClickHouse 26.9 feature release blog

29 September 2026

Apache Doris 4.1.4.1

30 September 2026

StarRocks 4.1.6 and 4.0.16

11 October 2026

ClickHouse v26.9.16.11-stable and v26.8.24.9-lts

First question: do you need a separate OLAP engine at all?

OLAP engines are for analytical scans, rollups and concurrent dashboard SQL. They are not a faster PostgreSQL for order capture, and they are not a metrics store.

Keep work on PostgreSQL when:

dashboard SQL still finishes within your SLA on a replica sized for the load, after indexes, partitioning and connection pooling;
freshness of hours is enough, and a batch ETL into PostgreSQL or a simple warehouse is honest enough;
you need exact row-level OLTP behaviour, triggers and extensions that columnar engines do not copy.

My PostgreSQL HA post covers keeping the operational database healthy. If the Bengaluru team’s pain is only failover of the order primary, fix HA first. If the pain is analytical scans over tens of millions of event rows, a replica will not save you for long.

Consider a dedicated OLAP engine when:

BI and product analytics need seconds to low minutes of freshness from Kafka or CDC;
queries are wide aggregations, top-N, multi-day filters, or repeated dashboard SQL that burns CPU on PostgreSQL;
you want columnar compression and vectorised execution as the default storage shape.

Choose among the three with the workload, not the blog post:

Prefer ClickHouse when single-table or denormalised fact scans dominate, you are happy with MergeTree family semantics, and you accept that true upserts need careful table engine choice (ReplacingMergeTree + FINAL, or specialised engines) rather than MySQL-style UNIQUE overwrite by default.
Prefer Doris or StarRocks when BI clients expect the MySQL protocol, when multi-table joins are central, and when primary-key / unique-key upserts from CDC are a first-class path.
Prefer lake query engines (Trino, Spark SQL, warehouse SQL on Iceberg) when most data already lives in object storage and interactive second-latency is not required. All three of today’s engines can also query Iceberg; that does not mean you should skip a lake when the lake is already the system of record.

For distributed SQL OLTP (CockroachDB, YugabyteDB, TiDB), see the distributed SQL post. That problem is write scaling and multi-region transactions, not dashboard warehouses.

For metrics, keep Prometheus-compatible long-term storage in its own lane. My Prometheus LTS post is about samples and labels. Event analytics (orders, clicks, GPS points) is a different grain and usually a different engine.

How the three are built

ClickHouse

Apache Doris

StarRocks

Processes

clickhouse-server (and optional ClickHouse Keeper for replication coordination)

Frontend (FE) + Backend (BE); decoupled mode adds Meta Service and shared object storage

Frontend (FE) + Backend (BE) in shared-nothing; Compute Node (CN) replaces BE storage in shared-data

Storage model

Columnar MergeTree family parts on local disk (or object storage configurations); wide engine catalogue

Columnar tablets on BE local disk (integrated) or shared storage with local cache (decoupled)

Columnar tablets / segment files on BE local disk, or shared-data with CN cache

Replication

ReplicatedMergeTree + Keeper / ZooKeeper; multi-replica parts

Tablet replicas with majority write confirmation (default three replicas in docs)

Multi-replica tablets in shared-nothing; shared-data relies on the object store plus cache

Primary key / upserts

Sorting key and optional primary key index; ReplacingMergeTree deduplicates on merge / FINAL; not MySQL-style unique overwrite by default

Unique Key model overwrites by key (merge-on-write default); Duplicate and Aggregate models also exist

Primary Key tables use Delete+Insert with primary-key index and DelVector; Duplicate / Aggregate / Unique Key models also exist

Client protocol

Native TCP, HTTP; optional MySQL port

MySQL protocol on FE query port

ClickHouse

ClickHouse stores data in immutable parts and merges them in the background. That design is excellent for append-heavy analytics. For updates, ReplacingMergeTree keeps one row per sorting key eventually, but docs are explicit: deduplication happens during merges at an unknown time, so queries need FINAL (or equivalent dedup patterns) when you need the latest row now. Replication uses Replicated* engines coordinated through ClickHouse Keeper (or ZooKeeper).

ClickHouse Keeper removes the need for an external ZooKeeper in many new clusters, but you still run an odd-sized Keeper group for production HA. Treat Keeper like etcd: dedicated disks, monitored latency, and a tested replacement procedure. For analytics-only single-node labs, a non-replicated MergeTree is fine; for anything that must survive a disk, start with replication from day one.

Apache Doris

Doris FE handles MySQL-protocol SQL, planning and metadata (BDB JE in the integrated mode). BE stores tablets and runs vectorised / pipeline execution. Since 3.0, a decoupled storage-compute mode puts data files on S3/HDFS-style shared storage with a Meta Service (FoundationDB-backed in the official deploy path). Unique Key tables are the upsert path; merge-on-write is the default implementation and is fixed at table creation.

On Unique Key tables, whole-row INSERT fills missing columns with NULL or defaults unless you enable partial column update on merge-on-write. That detail bites teams who port MySQL UPDATE col=... habits without reading the Doris update docs. Partition keys must be a subset of the key columns so uniqueness stays enforceable.

StarRocks

StarRocks keeps a similar FE+BE shape to Doris historically, with its own storage and optimizer work. Shared-nothing BEs hold local data; shared-data CNs are compute-and-cache in front of object storage. Primary Key tables are the real-time update path: writes update a primary-key index and mark old rows deleted, so reads avoid merge-on-read costs that Unique Key tables can still pay.

Primary Key tables since v3.0 can separate the sort key (ORDER BY) from the primary key, which helps prefix indexes on filter columns while uniqueness stays on the business key. Persistent primary-key indexes (enable_persistent_index, default true in current docs) keep most of the index on disk so large upsert tables do not demand huge BE RAM. Shared-data Primary Key support arrived later than shared-nothing; check the feature table if you deploy CNs.

Workload fit: scans, joins, upserts, concurrency, lakehouse

Workload

ClickHouse

Apache Doris

StarRocks

Single-table scans and rollups

Very strong default fit

Strong

Multi-table joins

Possible; teams often denormalise for speed

MPP joins are a stated strength

MPP joins and cost-based optimisation are a stated strength

Real-time upserts / CDC

Possible with careful engines (ReplacingMergeTree, specialised patterns); plan for FINAL or dedup views

Unique Key upsert by key; partial column update with merge-on-write

Primary Key upsert/delete; partial updates documented; Flink CDC common

High dashboard concurrency

Good with proper sizing and limits

FE observers / compute isolation in decoupled mode

Resource groups / workgroup style isolation in modern versions

Iceberg / lakehouse

Iceberg table engines and functions documented (including writable Iceberg paths with settings)

Native Iceberg catalog (REST and other metastore types) documented in 4.x

Iceberg catalog and lakehouse quick start documented; shared-data release notes continue to invest here

Practical guidance for the Bengaluru team:

If courier GPS and clickstream are append-only and dashboards hit one wide events table, ClickHouse is enough and often simpler to reason about.
If stock and order-status CDC must overwrite by business key every few seconds, and analysts join three to five tables live, Doris or StarRocks fit better.
If most historical facts already sit in Iceberg on object storage, evaluate querying the lake directly from Doris or StarRocks catalogs (or ClickHouse Iceberg engines) before copying everything into local disks.

Operations: upgrades, backups, Kubernetes, memory and merges

Topic

ClickHouse

Apache Doris

StarRocks

Upgrade rhythm

Frequent stable releases; LTS if policy demands slower change; always test on a realistic pre-production copy

Patch releases on a maintained branch are described as compatible both ways for data; read per-version upgrade notes before jumping branches

Rolling upgrades within a series; 4.1 docs warn not to downgrade to 4.0 below 4.0.6 after moving to 4.1

Backups

Native backup/restore features and filesystem snapshots depending on setup; practise restore

Backup/restore and snapshot practices in admin docs; decoupled mode changes what “local” means

Backup and restore documented for shared-nothing; shared-data uses different disaster-recovery pieces (cluster snapshot paths in recent lines)

Kubernetes

Official and community operators / Helm charts exist; keep storage and Keeper topology explicit

Doris Operator listed on the download/ecosystem page (26.0.1 at the time I checked)

Operator / Helm options in the ecosystem; container users should read image-specific release warnings (4.1.0 container note in release notes)

Memory / merge pitfalls

Merges and FINAL can spike IO and memory; mark cache and query memory settings matter; parts can explode if inserts are tiny and frequent

Compaction and tablet scheduling load the BEs; Unique Key merge-on-write needs disk headroom; decoupled mode needs healthy object-store latency

Primary Key index memory vs persistent index trade-off; compaction and publish lags show up under CDC micro-batches; jemalloc / FE heap sizing are day-one knobs

Two operational truths that surprise teams:

Tiny, chatty inserts create many parts or versions. Batch stream loads or async inserts.
“It started on my laptop” hides Keeper quorum, FE majority, replica repair and disk full behaviour. Budget for those before production.

Ingestion paths and freshness

Freshness is an ingestion problem before it is a query problem.

Path

ClickHouse

Apache Doris

StarRocks

Batch file / object

INSERT ... FROM INFILE, s3/url table functions, clickhouse-client

Broker Load, Stream Load

HTTP micro-batch

HTTP interface

Stream Load to FE (redirects to BE)

Streaming / CDC

Kafka engine / ClickPipes-style cloud paths / peer ETL; self-managed often uses Vector/Flink

Routine Load (Kafka), Flink Doris Connector (ecosystem versions listed on the download page)

Routine Load, Flink connector patterns, Primary Key + CDC is a documented sweet spot

SQL insert

Supported; tiny inserts create many parts if you are careless

INSERT upserts on Unique Key

INSERT upserts on Primary Key

For the Bengaluru Kafka topics, a practical pattern is:

Keep PostgreSQL as the system of record for orders.
Emit CDC or application events to Kafka.
Land events into OLAP with a connector that batches (hundreds of milliseconds to a few seconds), not one HTTP call per row.
Materialise only the rollups the dashboards need; do not mirror every OLTP table “just in case”.

If freshness of one hour is enough, a nightly or hourly batch into any of the three engines is simpler than CDC. Do not buy real-time complexity for a morning business review.

Protocol compatibility and SQL dialect traps

Doris and StarRocks advertise MySQL protocol compatibility so Tableau, Metabase, Superset and many JDBC tools connect with a MySQL driver. That is valuable. It is not the same as running MySQL.

Expect differences in:

types (LARGEINT, nested types, JSON variants);
DDL for distribution, buckets and key models;
update/delete syntax and whether a statement is row-by-row or load-oriented;
system tables and admin commands (SHOW BACKENDS, ADMIN SET FRONTEND CONFIG, and so on).

ClickHouse speaks its own SQL dialect over native and HTTP protocols, with an optional MySQL port for limited compatibility. BI tools often use the official ClickHouse drivers or HTTP. If your organisation standardised on MySQL drivers only, Doris or StarRocks reduce friction. If your organisation already runs ClickHouse elsewhere, staying on one dialect may matter more than the driver.

Always run your top twenty dashboard queries on a PoC cluster before you promise a migration date.

Shared-nothing versus shared-data / decoupled

All three families now offer a path where hot compute sits in front of object storage:

ClickHouse can place data on object storage with appropriate disks and tables; local MergeTree remains the classic deployment.
Doris integrated mode keeps data on BE disks; decoupled mode (from 3.0) uses shared storage plus Meta Service.
StarRocks shared-nothing uses BE disks; shared-data uses CN nodes and a storage volume on S3-compatible stores or HDFS.

Choose local disks when you want predictable low latency and you can grow BE capacity with data. Choose shared-data / decoupled when storage cost and elastic compute matter more than the lowest possible single-query latency, and when you already trust your object store operations.

StarRocks docs are explicit that some features differ between shared-nothing and shared-data (backup/restore, some indexes, partial-update modes). Doris docs similarly separate responsibilities of FE, Meta Service and BE between modes. Read the feature matrix for your chosen mode; do not assume every blog example applies.

Capacity and failure behaviour you should practise

Before festival traffic, practise at least these failures on a non-production cluster with a copy of real schemas:

Kill one BE / one ClickHouse replica during a continuous load; measure how long inserts pause and whether the client must retry.
Fill a disk to the watermark your docs warn about; confirm the process sheds load instead of corrupting parts.
Restart FE leaders; confirm clients reconnect and DDL is safe.
Restore from backup into a clean cluster and compare row counts for critical tables.

In my drill, a ClickHouse server kill -9 returned in under a second on a tiny dataset, and a Doris BE kill -9 needed about ten seconds before FE marked it alive again. Production clusters with larger caches and more tablets will take longer. Measure yours.

Migration sketches

From PostgreSQL dashboards

List the slow queries and the tables they touch.
Decide denormalised facts (ClickHouse-friendly) versus star-schema joins (Doris/StarRocks-friendly).
Dual-write or batch-copy a week of data; match totals for revenue and order counts.
Point one dashboard at OLAP; keep PostgreSQL for operational screens.

From a general warehouse

If you already land Iceberg tables, try an external catalog from Doris or StarRocks (or ClickHouse Iceberg engines) before copying petabytes onto local disks. Copy only the hot subset that needs sub-second dashboards.

Between OLAP engines

Rewriting MergeTree DDL into Unique/Primary Key DDL is not mechanical. Upsert semantics and partition schemes will force a reload. Budget an export/load weekend and a correctness harness, not a binary swap.

Licences

I read the licence texts from the release trees and project pages on 12 October 2026.

Project

Licence

What that means in practice

ClickHouse OSS

Apache License 2.0 (copyright ClickHouse, Inc. in the v26.9.16.11 tree)

You may run and modify the OSS database under Apache 2.0. ClickHouse Cloud and separately contracted self-managed add-ons are commercial products, not the OSS licence.

Apache Doris

Apache License 2.0

FE/BE binary trees ship Apache licence notices. Decoupled mode’s FoundationDB dependency is also Apache-licensed software you must operate.

StarRocks

Apache License 2.0 (LICENSE.txt in the 4.1.6 tarball)

Same family of permissions and conditions as other Apache 2.0 databases. Confirm any enterprise offering separately if you buy support.

None of the three requires a paid licence key to start the OSS binaries I used in the drill. Support contracts, cloud services and proprietary connectors are separate buying decisions.

Security and CVEs

I only list CVE IDs I retrieved as PUBLISHED from the CVE Program API (cveawg.mitre.org) on 12 October 2026. Dependency bumps inside release notes that mention a CVE are called out as such when I could confirm the CVE record.

ClickHouse

Summary (from CVE record)

Notes for operators

CVE-2025-1385

Library-bridge input validation failure that can lead to RCE under a specific configuration

Affects older 24.x/25.1 lines listed in the record; fixed versions are listed there. Disable unused library bridge and stay current. Also tracked as GHSA-5phv-x8x4-83x5.

Older ClickHouse advisories exist (for example GHSA entries from 2023-2024). For a new 26.9 install, patch hygiene still matters whenever you enable optional bridges, user-defined code paths or expose HTTP beyond a trusted network.

Apache Doris

Summary

Affected / fixed (from CVE record)

CVE-2026-31377

Improper authentication on FE meta service endpoints

Affected 2.0.0 before 4.0.8, and 4.1.0 before 4.1.4; fixed in 4.0.8 and 4.1.4+

CVE-2026-58319

Improper authentication on some FE HTTP admin APIs

Versions prior to 3.1.0

CVE-2026-68570

Authorisation bypass leading to unauthorised data access

Fixed by upgrading to 4.0.8 or 4.1.4+ (ranges listed in the CVE)

CVE-2026-72524

Authorisation bypass allowing low-privilege read/write/drop of arbitrary tables

Fixed in 4.0.8 or 4.1.4

Doris 4.1.4.1 and 4.0.8 are the lines you want if you are on the 4.x trains. Do not stay on early 4.1.0-4.1.3 builds for production.

StarRocks

Summary

Affected (from CVE record)

CVE-2026-80346

Missing authorisation on DROP of legacy synchronous materialized views

Through 4.0.13

CVE-2026-82276

Authentication bypass on certain FE REST handlers

Through 4.0.13

CVE-2026-82306

Query detail endpoint returns other users’ SQL history

Through 4.0.13

My drill used 4.1.6, which is past the “through 4.0.13” upper bound in those three records. Still read the 4.1.x release notes: 4.1.6 documents a fix that stops /api/profile style endpoints from returning every cached profile to any authenticated user, controlled by authorization_enable_query_profile_access_check. Treat FE HTTP as sensitive even after upgrades.

StarRocks 4.1.x release notes also list many dependency CVE bumps (Thrift, Netty, Ranger, HttpClient, and others). Those are transitive fixes; verify the specific CVE records if your compliance process requires it.

Decision guide

Situation

Lean towards

Append-only events, denormalised facts, ClickHouse-literate team

ClickHouse

MySQL-protocol BI tools, Unique Key CDC, integrated FE+BE simplicity

Apache Doris

Primary-key real-time upserts, strong join + lake catalog story, shared-data elasticity

StarRocks

Metrics / PromQL long-term storage

Not these three; use a metrics LTS stack

Multi-region OLTP writes

Not these three; see distributed SQL post

Data already in Iceberg, interactive SQL optional

Lake engine first; add Doris/StarRocks/ClickHouse only if latency demands it

Checklist before you pick one

Write down the query shapes (single-table scan vs multi-table join) with two real dashboards.
Write down the freshness target (5 s, 1 min, 1 hour) and the source (Kafka, batch, CDC).
Decide whether upserts are required by business key, or append-only facts are enough.
List BI clients and whether they must use MySQL protocol.
Choose integrated disks vs object-storage shared-data / decoupled mode deliberately.
Size FE/BE memory from vendor docs, then prove it with your data volume.
Plan upgrades on a pre-production cluster that runs the same SQL.
Close FE HTTP and MySQL ports to the open internet; patch to current 4.1.4+ / 4.1.6 / 26.9 lines.
Practise backup restore, not only backup success.
Run a 30-day PoC with production-like CDC before festival traffic.

Common mistakes

Building another dashboard warehouse because PostgreSQL was never indexed or pooled.
Expecting ReplacingMergeTree without FINAL to behave like a Unique Key upsert.
Using three replicas with replication_num=1 habits from a laptop PoC.
Exposing FE HTTP (8030) and assuming authentication bugs are “old news”.
Copying vendor benchmark numbers into capacity plans without re-running on your schema.
Treating Iceberg catalog demos as a full lakehouse operating model (still need compaction, vacuum, access control).
Ignoring part/tablet explosion from single-row inserts.

Drill I ran on 12 October 2026

Environment: shared Linux VM, 8 vCPU, about 15 GiB RAM, Debian-based userspace, no root, no Docker for the engines. I used official tarballs, verified checksums, and Temurin JDK 17.0.16+8 for Doris and StarRocks. Scripts and raw results live under /workspace/revisit/drill28/.

Engine

Artefact

Checksum

ClickHouse 26.9.16.11

clickhouse-common-static amd64 tarball from GitHub Releases

SHA-512 matched the published .sha512

Apache Doris 4.1.4.1

official bin-x64 tarball

SHA-512 matched

StarRocks 4.1.6

StarRocks-4.1.6-ubuntu-amd64.tar.gz

MD5 matched the published .md5

Workload: one CSV with 500,000 event rows (same file for all three). Create table, load, count(*), aggregate by city, top SKUs by revenue, then a small inventory upsert table. Finally kill the data process and confirm counts after restart.

ClickHouse 26.9.16.11  insert CSV ~0.25 s  count=500000  agg_city ~0.08 s
StarRocks 4.1.6        stream load ~0.38 s (500000/500000)  agg_city ~0.24 s
Doris 4.1.4.1          stream load ~0.52 s (500000/500000)  agg_city ~0.05 s

Upserts:

ClickHouse ReplacingMergeTree(updated) showed both versions of SKU0001 without FINAL, and only qty 80 with FINAL.
StarRocks Primary Key table and Doris Unique Key table both returned a single SKU0001 row with qty 80 after the second insert.

Restart continuity:

ClickHouse: kill -9 on the server; ready again in about 0.7 s; count still 500000; inventory FINAL still correct.
Doris: after a careful kill -9 of doris_be, FE reported Alive=false within a few seconds; with SKIP_CHECK_ULIMIT=true (this box has vm.max_map_count=65530 and cannot raise it without root), BE became alive again in about 10 s; count still 500000.
StarRocks: load and Primary Key upserts succeeded; after stop/start of BE with priority_networks=127.0.0.1/32, counts remained 500000. An earlier attempt to register BE on 127.0.0.1 failed with “FE saved address not match backend address” until that setting forced the BE to advertise loopback.

Example ClickHouse inventory check from the drill (same idea on Doris Unique Key and StarRocks Primary Key returned one row without FINAL):

CREATE TABLE inventory (
  sku String, qty Int32, updated DateTime
) ENGINE = ReplacingMergeTree(updated) ORDER BY sku;

INSERT INTO inventory VALUES
  ('SKU0001', 100, '2026-10-12 10:00:00'),
  ('SKU0002', 50,  '2026-10-12 10:00:00');
INSERT INTO inventory VALUES
  ('SKU0001', 80,  '2026-10-12 11:00:00');

SELECT * FROM inventory FINAL ORDER BY sku;
-- SKU0001 80 ...
-- SKU0002 50 ...

Limits of the drill (read these before quoting the timings):

Single node / FE+one BE, replication_num=1, loopback only.
500k rows is a functional smoke test, not TPC-H/DS.
Doris required skipping the start script’s vm.max_map_count check.
StarRocks FE heap was lowered to 1536m to fit the shared VM.
No Kafka CDC, no multi-table join contest, no Iceberg: those need a longer PoC.
Heavy binaries were deleted after the run; scripts and results remain.

Unlearn / re-learn

Unlearn

“Columnar OLAP” means one product behaviour.
MySQL protocol means MySQL semantics for updates and isolation.
A laptop stream load predicts festival-sale capacity.
Iceberg catalog demos replace warehouse operations.

Re-learn

Upsert models (ReplacingMergeTree, Unique Key, Primary Key) change both correctness and latency.
FE HTTP and meta ports are part of the attack surface; patch lines matter.
Shared-nothing vs shared-data / decoupled is an operating model choice, not a checkbox.
Practise restore, upgrades and kill tests on your schema before you cut Kafka over.

Closing

Real-time OLAP in 2026 is less about a single winner and more about matching storage semantics to the question you ask. Learn how MergeTree parts, Unique Key merge-on-write and Primary Key Delete+Insert actually behave. Unlearn the idea that a dashboard warehouse is the default next hop from a slow PostgreSQL replica. Re-learn licences and CVE lines every release train. Practise with your own events file and a kill test, as in the drill above. Apply the engine that fits scans versus upserts versus lake queries, and keep PostgreSQL on the transactional path where it belongs.

Sources

ClickHouse

Apache Doris

StarRocks

Internal Revisit.Tech links used in the body

comments powered by Disqus

Releted Posts

Distributed SQL in 2026: revisit CockroachDB, YugabyteDB and TiDB before you shard or go multi-region

Manoj Shukla
October 12, 2026

Picture a mutual fund and stockbroking platform in Mumbai (an invented example, not a real client). Its order book and client ledger run on PostgreSQL 16 with Patroni across three VMs in one cloud region, and a rewards service runs on MySQL 8.

Manoj Shukla
October 12, 2026

Picture an online pharmacy and diagnostics booking company in Ahmedabad (an invented example, not a real client). An order goes through five steps: hold the medicine stock, take the UPI payment, book a courier slot, send the customer an SMS, and, if the courier cannot pick up within four hours, release the stock and refund.

Manoj Shukla
October 11, 2026

Picture a lending company in Bengaluru (an invented example, not a real client). Its loan ledger runs on PostgreSQL 16 across three VMs, managed by Patroni with a three-node etcd cluster and HAProxy in front.