ClickHouse vs Postgres for analytics at scale: real examples

Published 2026-10-19 · Built only from first-party engineering write-ups in our database. Every number below comes from the linked source.

Cloudflare's 2018 post is the direct case: it rebuilt its HTTP analytics pipeline on ClickHouse, replacing a Postgres/Citus setup, at 6M requests per second. Staying on Postgres for analytics-style data is possible too: Timescale scaled a 350 TB+ dataset (10 billion new records a day) on PostgreSQL with its TimescaleDB extension, using hypertables, columnar compression and tiered storage.

ClickHouse vs PostgreSQL: side by side

ClickHousePostgreSQL
Stories in our database219
CompaniesCloudflareAtlassian, Datadog, Figma, GitLab, Neon, Notion, OpenAI, PlanetScale, Supabase, Tiger Data (Timescale) and Zalando
Published2018–20222021–2026
Techniques alongside itcolumnar storage (2), aggregation (1), pipeline redesign (1), schema design (1)connection pooling (3), horizontal sharding (3), query optimization (3), read replicas (3)
Scale numbers stated in sources6M requests/sec (Cloudflare)one primary and multiple replicas per shard (PlanetScale); 64-bit hashed keyspace split across shards (PlanetScale); restores in seconds even at 100 TB (Neon)
Direct comparison storyCloudflare: HTTP Analytics for 6M requests per second using ClickHouse; Tiger Data (Timescale): How We Scaled PostgreSQL to 350 TB+(same story)

Verdict

Columnar storage is the common thread: Cloudflare switched to a columnar database, and Timescale added columnar compression to Postgres. The rest of the Postgres stories here are transactional workloads, not analytics.

For more on Timescale's approach, and on cold tiers at Netflix and Dropbox, see tiered storage case studies.

Counts are stories in How They Scaled tagged with each side, see the ClickHouse and PostgreSQL pages. They describe what these teams wrote about, not market share or benchmark results.

The direct comparison

Cloudflare · 2018

HTTP Analytics for 6M requests per second using ClickHouse

Cloudflare rebuilt its HTTP analytics pipeline on ClickHouse, replacing a Postgres/Citus setup.

6M requests/seccolumnar storageaggregationpipeline redesignClickHouseKafkaGo
Tiger Data (Timescale) · 2023

How We Scaled PostgreSQL to 350 TB+

Timescale dogfooded its own Postgres extension to build a database-observability product, using hypertables, columnar compression and tiered storage to keep a 350 TB+ dataset queryable.

350 TB+10 billion new records/daypartitioningcompressiontiered storagePostgreSQLTimescaleDB

ClickHouse in other scaling stories

Cloudflare · 2022

Log analytics using ClickHouse

Cloudflare moved its error-log pipeline to ClickHouse and shares schema and query lessons.

columnar storageschema designClickHouse

PostgreSQL in other scaling stories

PlanetScale · 2026

Designing a planned switchover for minimum disruption

When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.

one primary and multiple replicas per shardsynchronous replication ANY 1 across eligible replicasplanned switchoverquery bufferingsynchronous replicationPostgreSQLNekiKubernetes
PlanetScale · 2026

Shard design doesn't start from your tables

In Neki, PlanetScale's sharded Postgres, a shard group is the unit of co-location: tables in the same group that hash their shard key the same way (xxhash into a 64-bit keyspace split by key ranges) always land on the same shard. Sharding customers, orders, items and addresses by customer_id keeps single-customer queries and transactions on one shard, which matters because a transaction across two shards gets no atomic commit or shared snapshot. Lookup tables become reference tables copied to every shard, catalog tables get their own group keyed on lower(sku), range and modulo indexes support legacy schemes, and a global secondary index routes queries like orders by id without fanning out. Shard groups can be changed later with the Reshard workflow.

64-bit hashed keyspace split across shardscross-shard transactions commit per shard, no atomic commitshard groupsco-locationreference tablesPostgreSQLNekixxhash
Neon · 2026

Inside branch-based restores in Lakebase Postgres

Traditional managed Postgres PITR provisions a new compute+disk monolith, pulls a snapshot out of object storage, and replays WAL—hours at large size—while a survey Neon cites of 50 production Postgres developers found 30% down 3+ hours after a critical failure. Lakebase splits compute from durable history: safekeepers quorum-ack WAL, a pageserver materializes page versions, and object storage keeps immutable history, with 99.99999% of reads served from local caches. A restore is then a metadata branch at a timestamp rather than a copy-and-replay, so time-to-restore drops to seconds even for a 100 TB database.

restores in seconds even at 100 TB99.99999% of reads served from local cachesstorage/compute separationbranch-based PITRWAL to pagesPostgreSQLLakebaseobject storage
PlanetScale · 2026

118 million queries per second on Neki

PlanetScale benchmarked Neki, its sharded Postgres, with single-shard primary-key point selects. Targeting about 200K QPS per shard, it went from 5 shards (about 1M QPS) to 50 (9.9M QPS, per-shard rate within 0.8%) to 512 shards and 480 routers, sustaining 118.5M QPS for 16 minutes over 1.22 PiB with a p99 of 6.06 ms at the router and about one error per 1.8 million queries. PlanetScale notes the run was read-only, primary-only with no replicas, and had no failover during the measured window.

118.5M QPS sustained for 16 minutes512 shards, 480 routershorizontal shardingbenchmarkinglinear scalabilityPostgreSQLNekiAWS r8g.16xlarge
Datadog · 2026

When failover isn't safe: Building high-availability PostgreSQL on Kubernetes

A gameday that injected network latency into one availability zone left several of Datadog's Kubernetes-based PostgreSQL clusters stuck: replicas lagged past Patroni's maximum_lag_on_failover, so no standby could be promoted safely. Datadog moved to a hybrid model: standbys in the leader pool take part in synchronous replication (one synchronous standby, synchronous_mode_strict, synchronous_commit=remote_apply) while read replicas stay asynchronous. pgbench showed remote_apply raised average latency by 53% and cut throughput by 34%, yet production clusters saw no measurable impact after a gradual rollout, and synchronous replication is now enabled in all of its clusters.

+53% avg write latency with remote_apply (pgbench TPC-B)-34% tps with remote_apply (pgbench TPC-B)synchronous replicationfailoverhigh availabilityPostgreSQLKubernetesPatroni
Datadog · 2026

When upserts don't update but still write: Debugging Postgres performance at scale

Datadog tracks last-seen time for millions of ephemeral hosts so inactive ones can be deleted after 7 days. An ON CONFLICT DO UPDATE upsert meant to touch each host at most once a day still locked the conflicting row and wrote Heap LOCK plus COMMIT WAL records even when the WHERE clause skipped the update—at 500 upserts/sec that roughly doubled write IOPS and quadrupled WAL syncs, and at 25,000/sec it would overwhelm a single writer. Using pg_walinspect and a debugger on heap_lock_tuple, they replaced it with an ON CONFLICT DO NOTHING CTE plus a conditional UPDATE that generates no WAL on true no-ops, keeps HOT updates when a day has passed, and preserves correctness for coarse host tracking.

25,000 upserts/sec target in largest DCs500 upserts/sec doubled write IOPS and ~4x WAL syncs in a small DC rolloutquery optimizationHOT updatesWAL inspectionPostgreSQLpg_walinspect
OpenAI · 2026

Scaling PostgreSQL to power 800 million ChatGPT users

OpenAI runs ChatGPT on a single-primary Postgres with nearly 50 global read replicas. Reads are offloaded, write-heavy shardable workloads move to Cosmos DB, and PgBouncer, cache leasing and multi-layer rate limits keep the primary safe.

800 million usersmillions of QPSread replicasconnection poolingcachingPostgreSQLAzurePgBouncer
Zalando · 2025

Contributing to Debezium: Fixing Logical Replication at Scale

Zalando's Fabric Event Streams provisions Debezium-in-embedded micro-apps so teams declare Postgres-sourced Kafka streams on Kubernetes; at peak the connectors handle hundreds of thousands of events per second across 100+ clusters, and have processed billions of events since 2018. Uncontrolled WAL growth on low-activity databases was the top operational issue until a pgjdbc keepalive flush advanced replication slots without table traffic. When newer Debezium hard-disabled that flush, Zalando contributed lsn.flush.mode (including connector_and_driver) and offset.mismatch.strategy (including trust_slot / trust_greater_lsn) so operators can opt into keepalive flushes while choosing whether the slot or the offset store wins on restart—both shipped in Debezium 3.4.0.Final.

hundreds of event streams from Postgreshundreds of thousands of events/sec at peaklogical replicationWAL managementopen source contributionPostgreSQLDebeziumKubernetes
Atlassian · 2025

Migrating the Jira Database Platform to AWS Aurora

Atlassian migrated about four million Jira databases from RDS Postgres to Aurora, balancing reliability, downtime and cost.

4 million databasesdatabase migrationmulti-tenancycost optimizationPostgreSQLAWS AuroraAWS RDS
Datadog · 2025

Breaking up a monolith: How we're unwinding a shared database at scale

Datadog is splitting its large shared Postgres database into team-owned instances in three phases. Logical separation moves tables into about 30 private domain schemas with explicit ACLs, using query samples and interviews with 30+ teams. Access reduction routes services through per-team PG Proxies so ACLs can be narrowed safely, and physical separation replicates each schema to a managed OrgStore instance, moves reads first and then writes with under five seconds of downtime, and replicates back for rollback. Two workloads have fully migrated and more than 70 dead tables were deleted along the way.

30+ teams consulted~30 domain schemas createddatabase decompositionlogical separationproxy-based cutoverPostgreSQLPgBouncerPG Proxy
Figma · 2024

How Figma's Databases Team Lived to Tell the Scale

Figma's nine-month effort to horizontally shard its Postgres stack using a custom query proxy and logical sharding before physical splits.

horizontal shardingquery proxyonline migrationPostgreSQLAWS RDS
Supabase · 2023

Supavisor: Scaling Postgres to 1 Million Connections

Supabase load-tested Supavisor, its Elixir Postgres pooler, with a million client connections.

1 million connections20,000 QPSconnection poolingbenchmarkingPostgreSQLElixir
Notion · 2023

The Great Re-shard: adding Postgres capacity (again) with zero downtime

Notion tripled its Postgres fleet by re-sharding with logical replication and careful PgBouncer cutovers, with no downtime.

reshardinglogical replicationzero downtimePostgreSQLPgBouncer
Figma · 2023

The growing pains of database architecture

How Figma moved from one Postgres instance to multiple databases by vertically partitioning table groups.

vertical partitioningread replicasconnection poolingPostgreSQLAWS RDS
GitLab · 2022

We are splitting our database into Main and CI

GitLab.com split CI tables into their own Postgres database to relieve its main database.

vertical partitioningdecompositionPostgreSQLRuby on Rails
Figma · 2021

LiveGraph: real-time data fetching at Figma

Figma built LiveGraph, which tails the Postgres replication log so its UI can subscribe to live query results.

change data capturereal-time synccachingPostgreSQLGraphQL
Notion · 2021

Herding elephants: Lessons learned from sharding Postgres at Notion

Notion split its Postgres monolith into a fleet of logical shards keyed by workspace, using double-writes and backfills to migrate.

horizontal shardingonline migrationdouble writesPostgreSQLAWS RDS
GitLab · 2021

Why we spent the last month eliminating PostgreSQL subtransactions

GitLab traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code.

query optimizationread replicasPostgreSQLRuby on Rails

FAQ

Why did Cloudflare move from Postgres to ClickHouse?

Cloudflare's 2018 post describes rebuilding its HTTP analytics pipeline, at 6M requests per second, on ClickHouse with Kafka and Go, replacing a Postgres/Citus setup.

Can Postgres handle analytics at scale?

Timescale's post describes a 350 TB+ dataset growing by 10 billion records a day on PostgreSQL with the TimescaleDB extension, kept queryable with hypertables, columnar compression and tiered storage.

The best scaling write-ups, weekly

One email a week. No spam.

Open subscribe page

More comparisons

Cassandra vs ScyllaDB at scaleMongoDB vs Cassandra at scaleGo vs Rust for backend services at scaleEnvoy vs Nginx at scaleRedis vs MySQL at scalePostgreSQL vs MySQL at scaleetcd vs SQLite for a control planeAurora vs RDS PostgresSharding vs partitioningRead replicas vs sharding

All comparisons →