Our events table had grown to 800 million rows and 410 GB of heap, with roughly 3,000 inserts per second at peak. Vacuum on it took most of a day, deleting expired data meant slow batched DELETE jobs that bloated the table, and every index rebuild was an event. Partitioning by month was the obvious answer. The hard part was getting there without a maintenance window, because the table sits behind an API that customers call around the clock. This post is the procedure we used on PostgreSQL 17: wh...
Partitioning a live 800M-row Postgres table without downtime: the procedure we used
We moved an 800-million-row events table to monthly range partitions with a cutover lock of under a second. The trick was to attach the existing table as one big legacy partition, with every slow step done beforehand under weak locks.
This is a paid story
Subscribe to read the full content, access all paid stories, and support the authors.
Add a label
Embed this post
<iframe src="https://www.hibug.me/postgres-partitioning-large-table-online-migration" width="700" height="420" frameborder="0" loading="lazy"></iframe>
I am a Senior Software Engineer with over a decade of hands-on experience building, scaling, and maintaining complex systems across the full stack—spanning frontend, backend, and DevOps. Over the last 10 years, I have navigated diverse architectures and untangled some of the most frustrating, elusive bugs in production. I believe that every production incident is a massive learning opportunity. Having discovered hibug.me, I am excited to contribute to this knowledge base, breaking down root causes, and sharing verified fixes to help fellow developers debug faster and build more resilient systems.
Comments
0No comments yet. Be the first to comment!
Sign In to post a comment.