Analytics on the Reporting Replica: Five Postgres Symptoms and the Columnar Option
Presented by:
Mingyu Chen
Rayner is currently a VP of Engineering at VeloDB, Apache Member and Apache Doris PMC Chair. 12 years of experience in distributed systems, focusing on distributed scalable analytical databases.
No video of the event yet, sorry!
Most Postgres teams move reporting queries onto a read replica, and past a certain volume that replica becomes its own operations problem. It usually starts with reports getting killed mid-run, when a long analytical query and WAL replay conflict. The standard fix stops the cancellations by asking the primary to hold onto row versions the replica still needs, moving the bloat upstream. Meanwhile the replica falls behind during the hours the business is watching, large reports exhaust their memory allowance and spill to disk, and a BI tool opening a pool per dashboard finishes off the connection headroom. Each has a view or log line that confirms it and a Postgres-side answer worth trying first. Partitioning and index choice reduce how much data a report touches, materialized views absorb repeated aggregates, and the standby settings can be set deliberately rather than by default. There is also an in-database option: pg_duckdb embeds a columnar engine inside Postgres and runs analytical queries in process, which for many workloads removes the reason to add a second system. Plenty of teams should stop there. Three requirements arriving at once change the calculation: sub-second response times, thousands of concurrent users, and a constant stream of updates. That combination is where a columnar engine such as Apache Doris earns a place next to Postgres, with Postgres keeping the system of record and change data flowing one direction.
- Date:
- Duration:
- 50 min
- Room:
- Conference:
- PostgresWorld Webinars: 2026
- Language:
- Track:
- Ops
- Difficulty:
- Medium
- Requires Registration:
- Yes (Registered: 49)