Designing an append-only time-series table in PostgreSQL

Goal

A table that accepts a steady stream of timestamped rows, answers "series X between t1 and t2" quickly, and discards old data cheaply without bloat.

Prerequisites

A known retention period, the dominant query shapes (one series over a window; aggregates per window), an estimate of rows per day, and the clock type: timestamptz, the documented abbreviation of timestamp with time zone, stores an absolute instant and avoids daylight-saving ambiguity.

Steps

1. Define the row: series_id (foreign key to a metadata table), ts timestamptz NOT NULL, measured columns with NOT NULL where a missing value is impossible, and no surrogate id unless rows are referenced individually. A primary key on (series_id, ts) also serves the main query; the documentation requires a primary key or unique constraint on a partitioned table to include all partition key columns.
2. Create the table with PARTITION BY RANGE (ts) and one partition per day, week or month, chosen so that a typical query window spans few partitions and the retention period is a whole number of them. The documentation warns that too many partitions lengthen planning and raise memory use.
3. Create future partitions ahead of time from a scheduled job (or a tool such as pg_partman). An insert into a missing range fails; a DEFAULT partition catches such rows silently, and the documentation notes that attaching a later partition then scans it under an ACCESS EXCLUSIVE lock unless a CHECK constraint rules the new range out.
4. Index per query shape: the primary key (B-tree) for per-series range queries; a BRIN index on ts for whole-table time scans. The index-types documentation describes BRIN as storing summaries per range of physical blocks, effective where values correlate with physical position, which append-only data does.
5. Implement retention as ALTER TABLE ... DETACH PARTITION ... CONCURRENTLY, optionally archive, then DROP TABLE. The partitioning documentation states that this is far faster than a bulk DELETE and avoids the VACUUM overhead it would cause.
6. Add a rollup table (hourly or daily aggregates) filled by a job when dashboards query long ranges.
7. Load in batches (COPY or multi-row INSERT) ordered by time so that BRIN ranges stay tight.

Expected result

Queries with a time predicate touch only the partitions in range (partition pruning), inserts land in the newest partition, old data disappears as a metadata operation, and deletion causes no bloat.

Limits and test basis

Pruning needs a predicate on the partition key; a query by series without a time bound reads every partition's index. Updates and out-of-order arrivals weaken BRIN's correlation. Follows the cited documentation; no throughput or size figures are claimed.