Partition Count Calculator

Work out partition count instantly with clear inputs, formula shown and shareable results.

About Partition Count Calculator

Range partitioning by time is chosen for retention: dropping a partition is instant where deleting rows is not. The partition count then follows from the retention window and the interval, and it must be balanced against planning overhead, since query planners examine partition metadata and thousands of partitions slow every query even when pruning works.

Formula

Partition count

time-based: retention months x intervals per month; hash-based: ceil(total rows / target rows per partition)

Worked example

With the default values below, Partition Count Calculator returns Partitions required of 24. Change any input above and every figure here is recalculated in your browser.

Inputs used

Total rowsminimum 1: 4,000,000,000
Target rows per partitionminimum 1: 50,000,000
Retention periodminimum 1 months: 24 months
Partitioning strategyone of Monthly range partitions, Weekly range partitions, Daily range partitions, Hash partitions: Monthly range partitions

Results

Partitions required: 24
Rows per partition: 166,666,667
Partitions implied by the row target: 80
Assessment: Reasonable partition count

Step by step

1Values used
2Partition count
3Partitions required= 24
4Rows per partition= 166,666,667
5Partitions implied by the row target= 80
6Assessment= Reasonable partition count

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax or fees or charges into account.
Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How many partitions is too many?

PostgreSQL handles a few thousand but planning time grows; beyond that, consider a coarser interval or sub-partitioning. Measure planning time on your real queries.

Does partitioning speed up queries?

Only when the partition key is in the predicate so pruning applies. Queries without it must touch every partition and often run slower than on an unpartitioned table.