TL;DR: Postgres is a transactional database, not an analytical one. When dashboards and customer-facing analytics start timing out, the fix isn't a bigger instance — it's routing analytical reads to a columnar engine. Mehdi Ouazza shows how to keep Postgres as your system of record while MotherDuck handles the heavy queries.
When Postgres hits its analytical ceiling
Postgres is a transactional database. When you start running large aggregations and concurrent dashboard reads against row-based storage, it shows. Pages take ten seconds to load, API gateways time out, read replicas don't actually help. These aren't tuning problems. You've outgrown Postgres for analytical work.
The usual patches stop scaling
Read replicas, materialized views, bigger instances — they all buy time but none fix the underlying mismatch. Replicas still do row-based scans. Materialized views go stale or get expensive to refresh. Scaling up costs more every quarter and you're still running OLAP queries on an OLTP engine.
Keep Postgres, add a columnar engine
Postgres stays as the system of record. Analytical reads go to an engine built for them. Columnar storage reads only the columns a query touches, so aggregations over millions of rows come back in milliseconds instead of seconds. MotherDuck runs DuckDB in the cloud — you get that speed without standing up a full data warehouse.
Pick the right ingest pattern
Mehdi walks through four ways to move Postgres data into MotherDuck: batch loads, change data capture (CDC), in-place reads, and the Postgres wire protocol. Each trades off freshness against complexity differently. The session ends with a live demo connecting a Postgres database to MotherDuck, running analytical queries, and feeding results into a dashboard. You can try it yourself in a few minutes.
