Most engineering teams start customer-facing analytics on Postgres. It works great for running the app, so why not use it to answer your questions? Great question. There is a good reason people pushback. Postgres works for your analytics workloads.... until you outgrow it. If you're using Postgres for your analytics, you may recognize some of the growing pains: 🤨 Aggregates take minutes. A bigger instance buys you a few months. 😠 The analytics tab is your top product complaint. Support tickets mention it, and so do renewals. 🐢 Your analytics replica is just as slow. It runs the same row storage and the same query planner on a different machine. 💩 Materialized views are either stale or expensive to refresh, and someone has added a last_refreshed_at column so users know how old the numbers are. 🫠 Customer-facing pages hit statement timeouts. Your API gateway gives up at 60 seconds and the customer gets a 500. 🐢 Indexes added for a weekly report slow down every write your app makes. 🙅 Your ETL is a pg_dump piped to psql that runs at 3 AM, and nobody wants to be the one to touch it. Recognize 3 or more and you're already at the wall. The fix is to stop wrestling Postgres for analytics. Give analytics its own engine. Postgres stays your system of record and keeps running the app while a scheduled sync copies the analytics tables into an OLAP (like MotherDuck). Our 'Postgres is Full' field guide walks through the whole move with a runnable repo. Check it out: