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