DOCS
← Back to Glossary
Composite key
A composite key is a primary key made up of two or more columns whose combined values uniquely identify a row, used when no single column is unique on its own.
Overview
A composite key (also called a compound key) combines multiple columns into a single primary key, because no individual column is unique by itself but the combination is. A classic example is a bridge table linking students to courses: neither student_id nor course_id alone identifies a row, but the pair (student_id, course_id) does.
Composite keys show up often in junction/bridge tables that resolve many-to-many relationships, in fact tables at a fine grain (e.g., order_id + line_number), and in time-series data where uniqueness requires both an entity identifier and a timestamp.
Related terms
primary key →
A primary key uniquely identifies each database row. Learn SQL definitions, examples, UUID vs auto-increment best practices, and how to fix constraint errors.
foreign key →A foreign key links one table to another by referencing its primary key. Learn how foreign keys enforce referential integrity, with SQL syntax, composite key examples, and data warehousing use cases.
UNIQUE constraint →A UNIQUE constraint ensures that all values in a column, or combination of columns, are distinct across every row in a table.
Surrogate key →A surrogate key is a system-generated identifier — typically a sequential integer or UUID — assigned to a row that has no business meaning of its own, used as the primary key in dimension and fact tables.
Natural key →A natural key is an identifier that comes from real-world business data — like an email address, SSN, or product SKU — as opposed to a surrogate key generated purely for database use.
Data normalization →Data normalization is the process of structuring relational tables to reduce data redundancy and prevent update anomalies, typically by applying a sequence of rules called normal forms.
FAQS
Composite keys work well for bridge/junction tables and fine-grained fact tables where the natural uniqueness genuinely spans two or more columns. Many teams still add a single surrogate key on top for simpler downstream joins, keeping the composite columns as a unique constraint.
