A database record is an individual collection of related field values representing one logical item, entity, event or occurrence within a database. In a relational database, a record usually corresponds to a row of a table and is formally related to the concept of a tuple in relational theory. For example, in a Customers table, one record may contain a customer identifier, name, email address and registration date for one customer.
In an Orders table, one record may represent one order. The term record is common in practical database terminology, although relational database theory generally uses terms such as row and tuple. The record provides the unit at which applications commonly create, retrieve, update and delete individual pieces of structured information.
A record consists of values associated with fields or columns. If a Customers table contains customer_id, name, email and date_joined, a particular record might contain one value for each of those attributes. The values must conform to the corresponding column definitions and constraints. A field may contain a scalar value, while a nullable field may contain NULL to represent the absence or unknown nature of a value according to the database's semantics. NULL is not normally equivalent to an empty string, zero or a Boolean false. Understanding this distinction is important because database comparisons, sorting and aggregation can treat NULL differently from ordinary values.
Records normally have an identifier that distinguishes them from other records in the same logical collection. In relational tables, this is commonly provided by a primary key, such as customer_id or order_id. A primary key can consist of one column or multiple columns forming a composite key. The key allows an application to refer to a particular record without relying on potentially changeable descriptive attributes such as a person's name. A database may also contain unique constraints that provide additional candidate identifiers. Identifiers are especially important when records need to be updated or deleted accurately, when other tables need to reference them, or when applications expose database entities through APIs.
A record can participate in relationships with other records through foreign keys. For example, an order record can contain customer_id that references the corresponding customer record. This allows the database to represent relationships without duplicating all customer information in every order. A product record might be referenced by order-line records, while a customer record might be associated with many orders. Junction records can represent many-to-many relationships. Relationships between records are therefore a central reason that relational databases organise information into related tables rather than storing every attribute in one enormous record.
Database records can change over time through UPDATE operations. An update may modify one field, several fields or an entire row, subject to constraints and application rules. A transaction can ensure that multiple record changes are applied consistently. Some systems also maintain temporal or audit information so that historical states can be reconstructed. A normal relational table generally represents its current state rather than automatically preserving every historical version of every record. Historical tracking therefore requires explicit design, such as audit tables, temporal features, event sourcing or application-level versioning. This distinction is important when users assume that a database can automatically recover every previous version of a record.
Records can be retrieved individually or in groups using queries. A SQL query might identify one record using its primary key, or retrieve many records satisfying conditions such as a date range, status or category. Database indexes can make selective record retrieval much faster by providing structures that help locate relevant rows without scanning an entire table. Joins allow records from different tables to be combined according to relationships. Aggregation can summarise many records into totals, averages or counts. Thus, a record is not an isolated object; its usefulness depends on the table structure, relationships, indexes and query operations surrounding it.
The word record can have meanings outside relational databases. In a document database, an individual document can play a role similar to a relational record while potentially containing nested objects and arrays. In a key-value database, a stored value may not have a fixed row-like structure at all. In older file-processing systems, records could be fixed-length or variable-length sequences stored in files. Database terminology has therefore evolved across different data models. When discussing a relational database, however, record generally means an individual row containing the values associated with one logical item in a table.
A database record should not be confused with a database field, table or database itself. A field or column represents one attribute across many records, a record represents one logical instance containing multiple fields, and a table contains a collection of records governed by a common structure. For example, an email column is a field definition, one customer's complete row is a record, and the Customers table contains all customer records. This distinction provides a useful conceptual hierarchy for understanding relational data. Records are the individual units of information that applications manipulate within the larger structures defined by tables, keys, constraints and schemas.
