Zero Planned Downtime with Partitioned Tables: A 600M Row Postgres Case

A routine autovacuum ANALYZE on a 600M-row Postgres table at Slice led to a planner misestimation that caused a sequential scan instead of an expected fast query. This resulted in a query running for 714 seconds instead of the usual 150 ms. Immediate measures included a statement timeout and a partial index, while the long-term solution involved range partitioning on a UUIDv7 column. The transition was executed over four months with zero planned downtime, unnoticed by anyone outside the team.