Primary Key

Die einfache Form

CREATE TABLE customers (
    id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email text NOT NULL UNIQUE,
    name  text NOT NULL
);

PRIMARY KEY bedeutet implizit:

• NOT NULL — keine Zeile darf NULL in dieser Spalte haben
• UNIQUE — keine zwei Zeilen dürfen den selben Wert haben
• automatischer Index — Postgres legt einen B-tree-Index auf der PK-Spalte an

Pro Tabelle gibt es genau einen Primary Key — aber beliebig viele zusätzliche Unique-Constraints.

GENERATED ALWAYS AS IDENTITY statt SERIAL

Modern (ab PG 10): IDENTITY-Spalten — SQL-Standard-konform und idiomatisch.

-- empfohlen
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY

-- alt, immer noch erlaubt aber weniger sauber
id bigserial PRIMARY KEY

Vorteile von IDENTITY:

• klarer SQL-Standard
• OVERRIDING SYSTEM VALUE schützt vor versehentlichem Setzen
• Sequence ist Owned-By der Spalte (auto-Cleanup bei DROP TABLE)
• saubere Trennung von Werttyp (bigint) und Sequence-Logik

Mehr Details im Artikel SERIAL vs. IDENTITY.

Composite Primary Key

Manche Tabellen brauchen einen zusammengesetzten PK — typisch Junction-Tables für Many-to-Many:

CREATE TABLE order_items (
    order_id   bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity   int    NOT NULL CHECK (quantity > 0),
    unit_price numeric(10,2) NOT NULL,
    PRIMARY KEY (order_id, product_id)
);

PRIMARY KEY (order_id, product_id) — die Kombination muss eindeutig sein. Eine einzelne order_id darf mehrfach vorkommen, eine einzelne product_id auch — aber ein Paar (order_id=42, product_id=7) nur einmal.

Reihenfolge der Spalten ist wichtig: sie bestimmt, wie der zugrundeliegende Index sortiert ist. Faustregel: zuerst die Spalte, nach der häufiger gefiltert wird.

Natural Key vs. Surrogate Key

Pragmatischer Konsens: Surrogate Key als PK + Natural Key als zusätzliche UNIQUE-Constraint.

CREATE TABLE products (
    id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    sku  text   NOT NULL UNIQUE,
    name text   NOT NULL,
    ...
);

id ist stabil und kompakt — alle Foreign Keys verweisen darauf. sku ist die geschäftliche Kennung, kann sich theoretisch mal ändern (etwa bei Umstellung des Nummernsystems), ohne dass alle FKs nachgezogen werden müssen.

UUID als Primary Key

Manchmal sinnvoll: UUID statt sequenzieller Identity.

-- PG 18+ mit eingebauter UUIDv7-Funktion
CREATE TABLE events (
    id         uuid PRIMARY KEY DEFAULT uuidv7(),
    event_type text NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now()
);

Vorteile von UUID-PKs:

• Client kann ID generieren, ohne erst INSERT zu machen
• IDs aus verschiedenen Instanzen kollidieren nicht (kein zentraler Counter nötig)
• Schwer zu erraten — gut für public-facing IDs

Nachteile:

• 16 Byte statt 8 Byte → mehr Speicher pro Index-Eintrag
• UUIDv4 (random) führt zu Index-Fragmentierung — UUIDv7 (zeitsortiert) ist deutlich besser

Mehr im Artikel UUID.

PK später hinzufügen

-- nachträglich
ALTER TABLE legacy_data
ADD PRIMARY KEY (id);

Vorsicht bei großen Tabellen: das Anlegen des Indexes blockt Schreib-Zugriffe. Sicherer Pfad:

-- 1. Unique-Index ohne Tabelle zu sperren
CREATE UNIQUE INDEX CONCURRENTLY legacy_data_pk_idx
ON legacy_data (id);

-- 2. Existing Index als Primary Key ausweisen
ALTER TABLE legacy_data
ADD CONSTRAINT legacy_data_pkey
PRIMARY KEY USING INDEX legacy_data_pk_idx;

CREATE INDEX CONCURRENTLY blockt nur kurze Locks, dann ist der Constraint per USING INDEX schnell drangehängt.

Weiterführende Ressourcen

Externe Quellen

• Constraints – PostgreSQL Documentation
• CREATE TABLE
• Identity Columns

Verwandte Artikel

• Foreign Key
• Unique-Constraint
• SERIAL vs. IDENTITY
• UUID