It Works on My Database
October 20–23
The query runs in 4ms in dev. In production it takes 12 seconds. The usual response is more CPU, more memory, a larger instance. The bill goes up, but the query is still doing the same wrong thing. The problem is not your code and it is not your indexes. The development database is lying to the planner.
PostgreSQL does not look at your data when it plans a query. It looks at statistics about your data: row counts, value distributions, most common values, and the correlation between column values and physical storage order. These live in pg_statistic and pg_class. In dev, those numbers describe a table with 10,000 rows. In production, the same table has 50 million, and that distribution changes which indexes the planner will touch.
Most developers know data volume matters. Almost none have looked at what pg_statistic actually contains or how directly it controls plan shape. Those statistics are just data. They can be serialized to a file, moved to another machine, and injected into a local PostgreSQL instance using pg_restore_relation_stats(), shipped in PostgreSQL 18. The local planner then makes the same decisions the production planner would make. No production access. No copy of the data. Just the statistics.
pg_statistic has columns most developers have never opened. Each one is a direct input to the planner's cost model. A production snapshot goes into a local database and the plan changes: the query that took 4ms starts sequential-scanning 8 million rows, exactly as it does in production. Fix the query, verify the plan locally, ship something that actually works on the other database too.
