Primary key

The column whose value identifies exactly one row, forever. Hand the database that value, get back one record.

the id columnwhat makes each row uniqueunique row identifierprimry keyprimay key columnthe column that can never repeatshould I use a uuid or an auto-increment idhow the database tells two rows apart

See it

Live demo coming soon

What it is

A primary key is the database's promise that one value points at exactly one row. It is one column, or several columns treated as one, and the combined value has to be unique and non-null. SQL will happily let you update it; you should not, because everything else in your system (foreign keys, URLs, cached ids, analytics events) hangs off it, so treat immutability as a design rule you enforce rather than a guarantee the database hands you.

Two camps. Sequential integers (bigint identity, auto-increment) are small, fast to index, and readable in logs, but they leak how many customers you have and collide when you merge two datasets. UUID and ULID keys are random, safe to generate on the client before the row exists, and merge cleanly, but they are wider and UUIDv4 scatters writes all over the index. UUIDv7 and ULID sort by time and get you most of both. A composite key (two columns treated as one) is legal and often right for join tables.

Gotcha: never key a table on a real-world value. Emails, phone numbers, usernames, and order codes all change eventually, and when they do you get to rewrite every table that referenced them. Give the row a meaningless id it can keep forever, and put a unique constraint on the email instead.

Ask AI for it

Give every table in this schema an explicit primary key. For entity tables, use a stable surrogate id column that is non-null, unique, never updated, and carries no business meaning: UUIDv7 or ULID if ids appear in URLs or get generated outside the database, otherwise a bigint identity column. For pure junction tables, either make the foreign-key pair the composite primary key, or keep a surrogate id and add a unique constraint on that pair. Do not key any table on email, slug, or other editable fields: add unique constraints on those instead. Output the CREATE TABLE statements with primary keys and unique constraints declared inline, and say in one line why each table got the key style it got.

You might have meant

foreign keyunique constraintidentifier strategyindexnormalization