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 database214
CompaniesCloudflareAtlassian, Datadog, Figma, GitLab, Notion, OpenAI, PlanetScale, Supabase and Tiger Data (Timescale)
Published2018–20222021–2026
Techniques alongside itcolumnar storage (2), aggregation (1), pipeline redesign (1), schema design (1)connection pooling (3), horizontal sharding (3), read replicas (3), benchmarking (2)
Scale numbers stated in sources6M requests/sec (Cloudflare)118.5M QPS sustained for 16 minutes (PlanetScale); +53% avg write latency with remote_apply (pgbench TPC-B) (Datadog); 800 million users (OpenAI)
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.

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

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
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
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.

Subscribe

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 →