Primary Key
A primary key is the column, or set of columns, in a database table whose value uniquely identifies each row and which the database engine enforces to be both unique and non-null for every single record. No two rows can share the same primary key value, and no row can have a missing one — a constraint enforced at the database level, not left to application code to maintain, which is what makes a primary key a reliable, stable way to reference one specific row from anywhere else in the system.
Primary keys come in two main design flavors: natural keys, drawn from a real-world attribute that happens to already be unique (a social security number, an email address, an ISBN), and surrogate keys, artificially generated values with no inherent business meaning (an auto-incrementing integer, or a UUID) created specifically to serve as an identifier. Natural keys have intuitive appeal — the key already means something to a human reading it — but carry a real risk: a value assumed to be permanently unique and unchanging can turn out not to be (an email address can be reused after an account is deleted and recreated; an SSN can, in rare documented cases, be reassigned or found duplicated due to data-entry error), and changing a natural key after it's already been referenced elsewhere in the database can cascade into a complicated, error-prone update across every table that references it. Surrogate keys avoid this entirely by design — an auto-incrementing integer has no external meaning that could ever need to change — which is why most modern database schema design defaults to surrogate keys even when a plausible natural key exists.
UUIDs (universally unique identifiers) — 128-bit values generated to be unique across systems without any central coordinating authority — have become a common surrogate key choice specifically for distributed systems, where multiple independent database instances need to generate new primary keys simultaneously without any risk of collision, a guarantee a simple auto-incrementing integer can't provide once more than one system is generating IDs independently. This comes with a real tradeoff: UUIDs are significantly larger than integers (128 bits versus the 32 or 64 bits of a typical integer), consume more storage and index space across a large table, and — depending on the UUID version used — can hurt insert performance on certain index structures because their effectively random ordering, unlike a sequentially increasing integer, doesn't insert cleanly into an ordered index, which is why some systems use time-ordered UUID variants specifically designed to retain most of UUID's distributed-generation benefit while preserving better insertion locality.
A composite primary key — a primary key made up of more than one column together, where no single column is unique on its own but the combination is — is common in junction tables used to represent many-to-many relationships, such as a table tracking which students are enrolled in which courses, where the combination of student_id and course_id is unique even though neither column alone is. This is distinct from, and should not be confused with, simply using multiple columns as separate unique constraints; a composite key's uniqueness guarantee applies specifically to the combination, which is exactly the structure needed to prevent a duplicate enrollment record for the same student in the same course.
Read a primary key as the database's enforced guarantee that every row can be addressed unambiguously: the choice between a natural key (meaningful but potentially unstable) and a surrogate key (meaningless but permanently stable) is a real design tradeoff most schemas resolve in favor of surrogate keys, UUIDs extend that surrogate-key pattern to distributed systems at the cost of size and insertion locality, and composite keys exist specifically for the case where uniqueness only emerges from a combination of columns rather than any single one.