pgpartman/pg_partman

What it does

You install it as a database extension and tell it which table to partition and by what — a date column or a number column. It converts the table into PostgreSQL's native declarative partitioning, which means one parent table and many child tables behind it, with the database choosing the right child automatically. It then keeps the set healthy: creating child tables ahead of time so a new month never arrives unprepared, and dropping or detaching old ones according to a retention setting. Maintenance runs either from an optional background worker inside PostgreSQL, so no external scheduler is needed, or from a job you run yourself. It can also undo the work and put the rows back into one table. What it no longer does is trigger-based partitioning: that approach was dropped from version 5.0.1, so an older setup has to be converted first.

Why it matters

Who it suits. Anyone with a PostgreSQL table that grows by date and that nobody ever deletes from — event logs, measurements, order history, anything append-only. The moment it becomes useful is the moment a DELETE FROM ... WHERE created_at < ... starts taking long enough to be frightening. Skip it if your largest table fits comfortably in memory; partitioning adds planning overhead and is not free.

Verdict. Worth half an hour on a copy of the database first, and the retention setting is the part to think about hardest, because dropping a child table is instant and final. The licence file tells a small story worth knowing: the copyright has passed from OmniTI in 2017 to Crunchy Data from 2018, and to Snowflake from 2025, so this is corporate-stewarded rather than a solo side project. It is a maintenance-grade tool rather than a fast-moving one — 330 commits in fourteen years, three releases in 2026 — which is the right shape for something managing a production table. Two practical notes: the background worker needs a line in postgresql.conf and a server restart, and partitioning many children raises the number of locks a single query needs, so the project suggests raising max_locks_per_transaction from the default of 64 to 128.