Partitioning vs sharding: same word, two different things

A team adds PARTITION BY RANGE (created_at) to their events table and calls it “sharding the database.” A month later they wonder why write throughput has not improved. Partitioning and sharding are often conflated — they solve different problems on different scales.

Partitioning: one Postgres, table split for pruning

Declarative table partitioning (introduced in PostgreSQL 10) splits a single table into named sub-tables called partitions, all living on the same Postgres instance.

-- One Postgres, one machine, many partitions
CREATE TABLE events (
  id BIGINT,
  tenant_id INT,
  created_at TIMESTAMPTZ,
  payload JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_01 PARTITION OF events
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
CREATE TABLE events_2026_02 PARTITION OF events
  FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

Postgres gains two things from this:

1. Partition pruning: a query with WHERE created_at >= '2026-02-01' only scans the relevant partitions, not the whole table.
2. Instant retention DROP: deleting a month of data is DROP TABLE events_2026_01 — instantaneous, no long DELETE, no dead-tuple bloat, no massive VACUUM.

The critical limitation: partitioning does not increase throughput beyond one machine. All writes still go to the same Postgres primary; all reads share the same CPU and RAM.

Sharding: many Postgres instances, routed by key

Sharding distributes rows across N physically separate Postgres instances. Each instance holds a subset of the data. Writes and reads for a given shard key go to that shard’s Postgres — parallel, independent IO and CPU.

How they compose in production

Real production systems typically use both — partition within each shard:

Shard 0: Postgres instance holding tenant_id 1–500
  └── events table: PARTITION BY RANGE (created_at)
        ├── events_2026_01 (Jan rows for tenants 1-500)
        ├── events_2026_02 (Feb rows for tenants 1-500)
        └── ...

Shard 1: Postgres instance holding tenant_id 501–1000
  └── events table: same month partitions
        ├── events_2026_01
        └── ...

The shard key (tenant_id) routes traffic to the right Postgres instance. Within that instance, the time partition means: query WHERE tenant_id = 42 AND created_at >= '2026-02-01' prunes to just the February partition. Retention is DROP PARTITION events_2026_01 per shard.

The senior intuition: partition for what you would do on a single machine anyway (time-series retention, query pruning for large tables); shard only when single-Postgres throughput and storage limits are measured and proven binding.