A primary key is the column, or set of columns, that uniquely identifies every row in a database table. No two rows can have the same primary key value, and the value can never be empty. That single guarantee is what lets a database find one exact record instantly, prevent duplicates, and link tables together reliably. In 2026 the concept is as fundamental as ever, whether you are using a traditional relational database or a modern managed one in the cloud. If you are learning databases, this is one of the first ideas worth getting right.
What a primary key actually is
A table is a list of rows. To work with one specific row, the database needs a way to point to it without ambiguity. The primary key is that pointer: a value guaranteed to be unique and present on every row.
When you mark a column as the primary key, the database enforces two rules automatically. The value must be unique across the table, and it cannot be null. Try to insert a duplicate or a missing value and the insert is rejected.
-- id is the primary key: unique and never null
CREATE TABLE users (
id INTEGER PRIMARY KEY,
email TEXT,
name TEXT
);
Why primary keys matter
A primary key does more than prevent duplicate rows. The database builds an index on it, so looking up a row by its key is fast even in a table with millions of records. It is also the anchor other tables point to.
| Job |
What the primary key provides |
| Uniqueness |
Guarantees one row per key value |
| Fast lookup |
An automatic index for instant retrieval |
| Relationships |
A stable target for foreign keys in other tables |
| Integrity |
Blocks empty or duplicate identifiers |
When an orders table needs to record which customer placed an order, it stores that customer primary key as a foreign key. The relationship only works because the key is stable and unique.
Surrogate vs natural keys
| Key type |
What it is |
Trade-off |
| Surrogate |
An auto-generated id with no meaning |
Stable, but an extra column |
| Natural |
An existing real-world value, like an ISBN |
Meaningful, but can change or repeat |
A surrogate key is a value the system invents, usually an auto-incrementing integer or another data type such as a generated identifier. A natural key uses data that already means something, like a country code. Surrogate keys are the safer default because real-world values change more often than you expect. People update emails and companies rebrand product codes, and if those were your key, everything pointing to them breaks.
How to choose a primary key
- Prefer a surrogate key by default. An auto-generated id is stable and never needs to change.
- Keep it simple. A single integer or generated id is easy to index and reference.
- Make sure it is truly unique and never null. That is the entire point of the key.
- Avoid sensitive data. Do not use a national ID or email as your key; it leaks into logs and references.
- Consider generated identifiers for distributed systems. When multiple machines insert rows, a globally unique id avoids collisions.
Common mistakes
- Using email as the primary key. People change their email, and the key should never change. Store email as a normal unique column instead.
- Reusing deleted key values. Recycling an old id can connect new data to stale references. Let the database keep assigning fresh values.
- Compound keys everywhere. Multi-column keys are valid but make references verbose. Reach for them only when they genuinely fit.
- No primary key at all. A table without one allows duplicate, unaddressable rows and is hard to update safely.
FAQ
Can a table have more than one primary key?
No. A table has exactly one primary key, though that key can span multiple columns. Additional uniqueness is enforced with separate unique constraints.
What is the difference between a primary key and a foreign key?
A primary key uniquely identifies rows in its own table. A foreign key in another table points to that primary key to create a relationship.
Can a primary key be text instead of a number?
Yes. A primary key can be any unique, non-null value, including text. Integers are common because they are compact and index efficiently.
Should I always use an auto-incrementing id?
It is a solid default for a single database. For distributed systems where many machines insert rows, a generated globally unique identifier avoids collisions.
Where to go next
See what an SQL query is in 2026, what a database schema is in 2026, and MySQL vs PostgreSQL in 2026.