PostgreSQL partitioning after an Oracle migration

The key question

A successfully created partitioned table is not yet an operating model. Future partitions must exist on time; retention, statistics and maintenance need clear ownership.

What to inventory

• Derive data growth and time ranges from real history.
• Capture late-arriving corrections to older periods.
• Compare common query filters with the intended partition keys.

Design the target deliberately

Define a repeatable process for creation, loading, validation and archiving. During live migration, locking and concurrent access belong in the pilot. The number of partitions should follow operational and query needs rather than a preference for maximum granularity.

A concrete validation step

Create an operating sheet per table family: owner, creation horizon, retention period, validation query and behaviour after failed maintenance. That turns DDL into an operable process.

Evidence required before sign-off

• Simulate period rollover and a missing target partition.
• Run load and query traffic concurrently.
• Measure maintenance with a realistic number of partitions.
• Restore and query archived data deliberately.