How Polymarket Scaled Their Data Stack with Postgres + ClickHouse

How Polymarket Scaled Their Data Stack with Postgres + ClickHouse

Prediction markets move fast — and so does their data. As Polymarket grew to billions in monthly trading volume, their PostgreSQL database started struggling under the weight of analytical workloads. Here's how they solved it by introducing ClickHouse as a dedicated analytics engine.

The Problem: Postgres Hits the Wall

Like many fast-growing startups, Polymarket initially ran everything on PostgreSQL:

Transactional operations (trades, orders, user accounts) Internal dashboards Public leaderboard

As on-chain activity exploded, two major pain points emerged:

Analytical queries for dashboards began timing out

The leaderboard feature became extremely resource-heavy, slowing down the entire database

They needed a better way to separate OLTP (transactional) from OLAP (analytical) workloads.

The Solution: Hybrid Postgres + ClickHouse Architecture

Polymarket kept PostgreSQL for transactional workloads (where it excels) and offloaded all heavy analytics to ClickHouse — a blazing-fast columnar database optimized for real-time analytics.

They built a modern data warehouse with three main ingestion paths:

On-chain trading data → ingested via Goldsky (subgraphs/streaming)

Web analytics → loaded from S3 using ClickPipes

Off-chain metadata → synced from Postgres

Rebuilding the Leaderboard with Materialized Views

The biggest win came from rewriting the leaderboard:

Previously: Complex queries on Postgres → frequent timeouts Now: ClickHouse materialized views → computation in milliseconds

This change delivered dramatic improvements:

Leaderboard queries went from timing out to sub-50ms

Enabled much more granular categorical leaderboards (by market type, volume tiers, etc.) API now handles hundreds of requests per second at ~25ms average latency

Key Benefits

Freed Postgres — now focused purely on transactional work with much better performance

Real-time analytics at scale

Easier feature development — new leaderboard categories and dashboards are cheap to build

Cost-efficient scaling for analytical workloads

Lessons for Developers Building High-Scale Apps

Separate OLTP and OLAP early — Don’t wait until you’re in pain.

ClickHouse shines for high-ingestion, high-query-volume analytics (especially with time-series or event data).

Materialized views in ClickHouse are incredibly powerful for pre-computing expensive aggregations.

Modern ingestion tools (Goldsky, ClickPipes, dbt, etc.) make building a data warehouse much faster than in previous years.

Hybrid architectures win — Use the right tool for the right job instead of forcing everything into one database.

Polymarket’s stack is a great example of pragmatic scaling: keep Postgres for what it’s great at, and add ClickHouse where raw analytical speed matters most.

Have you migrated analytical workloads to ClickHouse or another OLAP database? What challenges did you face?

Tags: #ClickHouse #PostgreSQL #DatabaseScaling #DataEngineering #Polymarket #PredictionMarkets #Backend #Performance #OLAP #TechStack