A primary key is a column or combination of columns in a relational database table that uniquely identifies each row in that table. It provides an unambiguous identity for records and is one of the central mechanisms used to maintain entity integrity. A primary key must be unique within the table, and its values cannot normally be NULL. A table has one primary-key constraint, although that constraint can contain multiple columns in a composite primary key. For example, an Employees table might use employee_id as its primary key, while an OrderLines table might use a combination of order_id and product_id if that combination uniquely identifies each line under the application's rules.
A primary key can be based on a natural key or a surrogate key. A natural key uses an attribute or combination of attributes that already has meaningful uniqueness in the real-world domain, such as a formally defined registration number. A surrogate key is an identifier introduced primarily for database purposes, such as an auto-incrementing integer or generated UUID. Surrogate keys are common because they can remain stable even when descriptive business attributes change. However, using a surrogate key does not eliminate the need for business-level uniqueness constraints. For example, a customer_id can uniquely identify a customer while a separate unique constraint prevents duplicate email addresses when the business rules require email uniqueness.
Primary keys are commonly referenced by foreign keys in other tables. If Customers has customer_id as its primary key, Orders can contain customer_id as a foreign key. This creates a relationship between order records and customers. The database can enforce referential integrity so that an order cannot reference a customer identifier that does not exist, subject to the defined foreign-key actions and constraints. Primary keys therefore provide the targets to which relational references point. They also make joins conceptually straightforward because a child record can identify the parent record through its key.
Composite primary keys contain two or more columns and enforce uniqueness across the combination rather than requiring each individual column to be unique. A Membership table linking users to groups might use user_id and group_id together as a primary key, preventing the same user-group relationship from being inserted twice. Neither user_id nor group_id needs to be globally unique within that table individually. Composite keys can accurately model certain relationships but can make foreign keys and queries more verbose because referencing tables may need to store every component of the key. Whether to use a composite or surrogate key depends on the data model, business semantics and operational requirements.
A primary key frequently has an index associated with it. Most relational database management systems automatically create or require an index to enforce primary-key uniqueness, although the exact implementation differs by system. Primary-key indexing can also make record retrieval and joins efficient. In some database engines, the primary key influences physical row organisation, while in others it is simply supported by a unique index or similar structure. The logical requirement is uniqueness and non-nullability; the physical implementation is database-specific. Developers should therefore distinguish the primary-key constraint from the index that may enforce or support it.
Primary keys should generally be stable identifiers. Changing a primary key can be complicated when other tables reference it through foreign keys, especially when the key is exposed externally or embedded in application logic. This is one reason surrogate identifiers can be useful when natural attributes are likely to change. However, stability does not mean that a primary key must never change under any circumstances. Database systems can support cascading updates or application-managed changes, but changing identifiers unnecessarily can increase complexity and risk.
Primary keys are related to candidate keys and unique constraints. A candidate key is a minimal set of attributes capable of uniquely identifying a row. A table may have several candidate keys, but one is selected as the primary key. Other candidate keys can be enforced using UNIQUE constraints. A unique constraint is not necessarily semantically the primary identity of the table, even though it also prevents duplicate values. Understanding this distinction helps avoid treating every unique column as a primary key. The primary key communicates the principal relational identity chosen for the table.
A primary key is therefore both a data-integrity mechanism and a relational reference point. It ensures that each row has an identifiable key, supports relationships through foreign keys, facilitates indexing and efficient retrieval, and provides a stable basis for application operations. Good primary-key design considers uniqueness, nullability, stability, size, generation method and how other tables will reference the key. A primary key does not by itself guarantee that every other field is correct or unique; additional constraints and validation are required for those properties. Its specific role is to establish the table's formal identifier for individual rows.
