A database is an organized collection of information that a computer system can store, retrieve, update, and manage efficiently. Databases power many everyday activities, from checking a bank balance and shopping online to searching a library catalog, booking a flight, or accessing a medical record. They also support scientific research, business operations, government services, and countless other applications.
A database is more than a digital collection of files. It is designed to keep information organized, make useful data easy to find, control who can access it, and maintain accuracy as information changes. Most databases rely on a software system called a database management system (DBMS), which provides the tools and rules needed to work with stored information.
Different databases organize information in different ways. Relational databases arrange data into tables, document databases store structured documents, key-value databases associate identifiers with values, and graph databases represent relationships between connected entities. Each approach offers advantages for particular kinds of information and workloads.
Understanding databases begins with how data is organized, how a database processes requests, and why different designs exist.
What is a database?
A database is a structured collection of related data maintained for a particular purpose. Its contents might include customer names, product prices, financial transactions, scientific measurements, shipping records, or the relationships between people and organizations.
The word data refers to recorded facts, measurements, observations, or other information that a system can process. Data becomes useful when it can be interpreted in context. For example, the number 42 has little meaning on its own, but a database field labeled temperature_fahrenheit gives it a specific interpretation.
Databases can hold relatively simple information, such as a list of employee names, or highly interconnected information involving millions of records. Their defining feature is not size but the ability to manage information systematically.
Consider an online bookstore. It may maintain separate collections of information about customers, books, orders, payments, and inventory. When a customer places an order, the system must identify the customer, determine which books were purchased, record the transaction, and update available stock. A database makes it possible to coordinate these related operations without treating every piece of information as an isolated file.
Databases also allow information to be reused. The same customer record can support order processing, shipping, customer service, and account management. Without a shared source of data, each part of the system might maintain its own copy, increasing the likelihood of conflicting or outdated information.
How a database differs from a DBMS
The terms database and database management system are closely related, but they describe different things.
A database is the organized information itself. A DBMS is the software that creates, maintains, protects, and provides access to that information. Examples of database management systems include PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, MongoDB, and SQLite.
A DBMS typically provides several essential capabilities:
- Data definition: Establishing the structure of stored information, including tables, fields, data types, and relationships.
- Data manipulation: Inserting, retrieving, changing, and deleting records.
- Integrity enforcement: Applying rules that prevent invalid or inconsistent information from entering the database.
- Access control: Determining which users or applications may view or modify particular data.
- Concurrency management: Coordinating operations when multiple users or processes access the same data at the same time.
- Recovery: Restoring data or recovering completed work after certain failures.
The DBMS also determines how information is stored and retrieved internally. It may organize data into files, maintain indexes, cache frequently accessed information, and use transaction logs to support recovery.
In practice, people often use the word database to refer to the entire system, including its software. The distinction matters, however, because the stored information and the software managing it serve separate roles.
A related term is database server. This usually refers to a computer or software service that accepts database requests from applications. The server may run on the same computer as the application, on a separate machine, or across a distributed infrastructure. Not every database requires a separate server; SQLite, for example, is commonly embedded directly in an application.
How databases organize information
A database’s structure determines how information is represented, connected, and retrieved. The design depends on the kind of data being managed and the questions the system needs to answer.
Tables, rows, and columns
In a relational database, information is organized into tables. Each table represents a category of things, such as customers or orders. Columns describe the properties of those things, while rows contain individual records.
A customer table might have columns for customer_id, name, email, and city. One row represents one customer, with a value in each column. The customer_id identifies that customer within the database.
Columns generally have defined data types. A name may be stored as text, a quantity as an integer, and an order date as a date or timestamp. Data types help the database interpret values correctly and reject certain invalid inputs. A numeric column, for example, should not accept arbitrary text as though it were a valid number.
A table’s structure is often called its schema. The schema specifies the tables or other database objects that exist, the fields they contain, their data types, and relevant rules about how the information may be used.
A schema is not necessarily permanent. Developers can change it as an application evolves, although structural changes require care when existing data and applications depend on the original design.
Primary keys and relationships
Databases frequently need to connect information stored in different places. Relational databases accomplish this through keys and relationships.
A primary key is a column, or combination of columns, that uniquely identifies each row in a table. In a customer table, a customer ID can serve this purpose. Unlike a person’s name, which may be shared by multiple people, a properly defined primary key cannot be duplicated within the table and cannot be missing.
A foreign key is a field that refers to a key in another table, or sometimes in the same table. It establishes a relationship between records.
For example, an orders table might contain order_id, customer_id, order_date, and total_amount. The customer_id field connects each order to its customer. The database can use that relationship to retrieve all orders associated with a particular customer without repeating the customer’s name and contact details in every order.
An order containing several products introduces another relationship. A separate order-items table can record the product, quantity, and price associated with each line of an order. This structure allows one order to contain multiple products and one product to appear in many different orders.
Relational databases can enforce referential integrity, meaning that a foreign-key reference must satisfy the relationship rules defined by the database. For example, an order cannot reference a nonexistent customer when the relevant constraint is enforced.
Why database design matters
A database’s structure affects how reliably information can be maintained and how efficiently it can be queried.
One important design principle is normalization. This is the process of organizing relational data to reduce unnecessary duplication and prevent certain inconsistencies. For example, storing a customer’s address in a single customer record rather than repeating it in every order makes updates easier and reduces the risk that different orders will contain conflicting addresses.
Normalization does not mean eliminating all duplication. Some applications deliberately store repeated or precomputed information to speed up common queries. This practice, called denormalization, can improve performance but introduces additional work to keep the duplicated values consistent.
Good database design also accounts for the relationships between real-world entities, the rules governing valid data, and the ways applications will use the information. A structure optimized for recording financial transactions may differ substantially from one designed for analyzing large volumes of scientific measurements.
How databases work when a user makes a request
A database request typically begins when a person performs an action in an application. Clicking a button to view an order, submitting a payment, or searching for a product can trigger one or more database operations.
In a common architecture, the application sends a request to the DBMS. The DBMS interprets the request, determines how to execute it, accesses the necessary data, and returns a result. The application then uses that result to display information or complete an action.
For example, when a customer searches an online store for a particular book, the application might submit a query asking the database to find matching products. The DBMS identifies the relevant records and returns information such as the title, price, and stock status.
When a customer places an order, the process is more involved. The application may need to create an order record, add individual order items, record payment-related information, and reduce the available inventory. Some operations may involve other services, but the database must still manage the changes assigned to it correctly.
The request itself is often expressed using a database query language. Relational systems commonly use SQL, or Structured Query Language. A simplified SQL query might look like this:
SQL
SELECT name, email
FROM customers
WHERE customer_id = 1042;This statement asks the database to return the name and email address of the customer whose ID is 1042. SELECT specifies the fields to return, FROM identifies the table, and WHERE filters the records.
SQL also supports inserting, updating, and deleting data, as well as defining tables and controlling access. Although SQL is associated primarily with relational databases, some other database systems support SQL-like interfaces or SQL itself.
How the database finds information efficiently
A DBMS does not necessarily examine every record each time it receives a query. It may use an index, a data structure that helps locate records based on particular values.
An index on customer_id, for example, can make it faster to find a customer with a specified ID. An index on a product’s name may help the system locate products matching a search condition.
Indexes improve some read operations but require storage space and maintenance. When a record changes, the DBMS may also need to update the relevant indexes. Too many indexes can therefore slow down data modifications and consume unnecessary resources.
The DBMS typically uses a query optimizer to choose an execution plan for a query. It considers factors such as available indexes, table sizes, data distribution, and the operations required to produce the result. The plan might involve scanning a table, using an index, combining records from several tables, or applying filters in a particular order.
The most efficient plan depends on the query and the data. An index is not automatically useful for every search, and the presence of an index does not guarantee fast performance.
The DBMS also manages memory and storage. Frequently accessed data may be held temporarily in memory, reducing the need to read it repeatedly from slower storage. When data must be retrieved from storage, the system reads the relevant pages or blocks rather than treating each individual field as an entirely separate physical operation.
These internal mechanisms allow a database to present a simple interface to an application while handling much of the complexity of locating and maintaining information.
The main types of databases
Databases are classified in several ways, including by their data model, their deployment architecture, and the workloads they support. The most useful starting point is the data model: the method a database uses to represent information and relationships.
Relational databases
Relational databases store data in tables and connect records through defined relationships. They are particularly useful when information has a clear structure and must remain consistent across related operations.
A bank, for example, might store customers, accounts, transfers, and transaction records in related tables. Constraints can help ensure that transfers reference valid accounts, while transactions can group multiple changes into a single logical operation.
Relational systems are widely used in banking, retail, accounting, reservation systems, inventory management, and business applications. They support complex queries, including operations that combine information from several tables.
Examples include PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, and SQLite. These systems share the relational model but differ in features, administration, performance characteristics, licensing, and deployment options.
Document databases
Document databases store information as individual documents, often using formats such as JSON or a binary representation of JSON-like data. A document can contain fields, nested objects, and lists, allowing related information to be grouped together.
A document describing a product might include its name, price, manufacturer, and a collection of specifications. Products with different characteristics can have different fields without requiring every possible property to occupy a column in one fixed table.
This flexibility is useful for applications whose data structures change frequently or vary from record to record. Document databases are commonly used in content management, application profiles, product catalogs, and other systems that work naturally with document-shaped information.
However, flexible structure does not mean an absence of rules. A document database may support schema validation, indexes, transactions, and constraints, depending on the system. Developers still need to decide which fields are required and how related information should be maintained.
MongoDB is a well-known example of a document database.
Key-value databases
A key-value database stores information as pairs: a key that identifies an item and an associated value. The key functions much like a unique label, allowing the system to retrieve the corresponding value efficiently.
For example, an application might use a session identifier as a key and store the associated session information as its value. Another application might store temporary settings or cached results under identifiable keys.
Key-value databases are useful when an application usually knows the exact identifier of the information it wants. They can be less suitable when users need to search extensively across many fields inside the stored values, although some systems provide additional querying capabilities.
Redis and Amazon DynamoDB are examples of systems commonly used for key-value workloads, though their capabilities and data models extend beyond a minimal key-value interface.
Wide-column databases
Wide-column databases organize information into rows and named columns, but their data model differs from the fixed, table-oriented structure of a traditional relational database. Depending on the system, rows may contain different sets of columns, and data is often organized around access patterns that distribute efficiently across many machines.
These databases can be useful for large, distributed workloads involving substantial volumes of records, such as event histories, time-stamped measurements, and high-throughput application data.
Their design can make certain queries very efficient, especially when the application knows how information is partitioned and retrieved. Other kinds of queries may be more difficult or expensive than they would be in a relational database.
Apache Cassandra and Apache HBase are examples of wide-column database systems.
Graph databases
Graph databases represent information as entities, commonly called nodes, and connections between them, called edges or relationships. Nodes can represent people, products, organizations, or locations. Relationships describe how those entities are connected.
A social network, for example, might represent users as nodes and friendships or follows as relationships. A graph query can then find a person’s connections, identify paths between people, or explore how several entities are linked.
Graph databases are particularly useful when relationships are central to the problem and queries must traverse many connections. Other applications include fraud detection, recommendation systems, network analysis, and knowledge representation.
Neo4j is an example of a graph database system. Graph databases are not automatically better for every connected dataset; the choice depends on the complexity of the relationships and the operations the application needs to perform.
Other important database categories
Some database categories describe a specific purpose or workload rather than a completely separate data model.
Time-series databases are designed for measurements recorded over time, such as equipment readings, application performance metrics, or environmental observations. They often provide specialized features for time-based queries and data retention.
Spatial databases manage geographic and geometric information, supporting operations such as finding locations within an area or determining whether two shapes intersect.
In-memory databases keep much of their working data in main memory to reduce access delays. Some use persistent storage or logging to help preserve data across failures, while others emphasize temporary or reconstructable data.
Vector databases store and search numerical representations called vectors. These vectors can encode features of text, images, audio, or other data, making similarity searches useful in applications such as semantic search and retrieval systems built around machine learning. A vector database is not necessarily a replacement for a conventional database; applications often use both.
These categories can overlap. A single system may support more than one data model or workload, and the label alone does not determine how well a database will perform for a particular application.
How databases keep information accurate
Storing information is only part of a database’s job. The system must also help ensure that records remain valid when many changes occur, especially when several operations depend on one another.
Relational databases commonly address this through constraints and transactions. A constraint is a rule applied to the data, such as requiring a field to be present, preventing duplicate values, or ensuring that a number falls within an acceptable range.
A transaction is a group of database operations treated as one logical unit. A classic example is transferring money between two accounts. The system must subtract money from one account and add it to another. If the subtraction succeeds but the addition fails, the database could end up with an incorrect total unless the operations are managed together.
Transactions are often described through the ACID properties: atomicity, consistency, isolation, and durability.
Atomicity means that a transaction’s operations are treated as an indivisible unit: either the transaction completes, or its changes are rolled back under the database’s transaction rules.
Consistency means that a transaction that begins with valid data must preserve the integrity rules enforced by the system when it completes. The term refers to maintaining defined rules, not guaranteeing that every stored fact is true in the real world.
Isolation concerns how concurrent transactions interact. The database controls the visibility and ordering of changes so that transactions do not interfere in ways prohibited by the chosen isolation level. Stronger isolation can provide more predictable results but may reduce concurrency or require retries.
Durability means that once a transaction is committed, its changes are intended to survive subsequent failures within the system’s stated durability guarantees. Databases commonly use transaction logs and persistent storage to support this property.
Not every database offers the same transaction behavior, and some distributed systems provide different consistency and isolation guarantees. Applications must understand those guarantees rather than assume that every operation is immediately visible everywhere.
How databases handle multiple users and failures
Modern databases often serve many users and applications simultaneously. A shopping website might receive orders while updating inventory, a payment service records transactions, and customer support checks account details.
Without coordination, concurrent operations can conflict. Two customers might attempt to buy the last available item at nearly the same time. If both requests read the same stock value and independently reduce it, the database could record an incorrect inventory count unless the operations are properly controlled.
DBMSs use techniques such as locks, multiversion concurrency control, and transaction validation to manage competing operations. A lock can restrict access to a record or resource while a transaction works with it. Multiversion concurrency control, often abbreviated MVCC, allows the system to maintain multiple versions of data so that readers and writers can often proceed without blocking one another unnecessarily.
These methods involve trade-offs. More restrictive coordination can prevent certain conflicts but reduce throughput. More permissive approaches can improve concurrency but may require applications to handle conflicts or retry failed transactions.
Databases must also prepare for hardware failures, software errors, and interrupted operations. Transaction logs record information needed to recover changes, while backups preserve copies of data that can be restored after loss or corruption. Replication, which maintains copies of data on multiple systems, can improve availability and support recovery when a machine fails.
These protections serve different purposes. Replication is not a substitute for backups: an accidental deletion or corrupted update may be copied to every replica. A reliable recovery plan therefore considers backups, restoration procedures, transaction recovery, and the possibility that several systems could fail together.
Security is another essential part of database management. Access controls limit which users and applications can read or change particular information. Encryption can protect data while it is transmitted or stored, depending on how it is configured. Auditing can record access and changes, helping organizations investigate suspicious activity and demonstrate compliance with applicable requirements.
No single feature makes a database completely secure or immune to failure. Protection depends on the combined design of the database, the surrounding application, its operating environment, and the procedures used to maintain it.
How databases scale as demand grows
A database that works well for a small application may struggle as the amount of data or number of requests increases. Scaling means increasing a system’s capacity to handle that growth while maintaining acceptable performance and reliability.
One approach is vertical scaling, which gives a database server more computing resources, such as memory, processing power, or faster storage. This can improve performance without requiring a fundamentally different architecture, although the available resources and practical limits of a single machine eventually matter.
Another approach is horizontal scaling, which distributes data or work across multiple machines. A system may replicate data to additional servers, partition records across servers, or use a combination of both methods.
Replication creates additional copies of data. Depending on the design, replicas may handle read requests, improve availability, or provide standby systems for failover. Some replication arrangements propagate changes quickly but asynchronously, meaning that a replica can temporarily lag behind the primary copy.
Sharding divides a dataset into partitions, with different partitions stored or managed by different servers. For example, records might be assigned to partitions according to a customer identifier. This can distribute storage and workload, but it also adds complexity: the system must decide where each record belongs, and queries involving records on several shards may require coordination.
Distributed databases introduce questions that are less prominent in a single-server system. Network delays can affect operations, machines can become temporarily unreachable, and different parts of the system may not observe changes at exactly the same moment. Database designs make different trade-offs between availability, consistency, latency, and coordination.
Consequently, horizontal scaling is not simply a matter of adding machines. The data model, query patterns, partitioning strategy, and consistency requirements all influence whether a distributed design improves the system.
How relational databases differ from NoSQL databases
The term NoSQL commonly refers to database systems that do not rely exclusively on the traditional relational model. It includes document, key-value, wide-column, and graph databases, among other approaches. Some NoSQL systems provide SQL-like query languages, so the label does not always mean that SQL is unavailable.
The central difference is how information is modeled and how the system supports queries, relationships, consistency, and distribution.
Relational databases are often a strong choice when information has well-defined relationships, complex queries are important, and transactions must preserve strict integrity rules. Their structured tables and constraints help developers express those requirements directly.
NoSQL systems can be a better fit when information varies in structure, access patterns are highly specialized, or a workload benefits from a particular distributed data model. Some are designed to support very high request volumes across many machines, while others make traversing relationships or retrieving document-shaped records especially convenient.
These distinctions are tendencies rather than absolute rules. Relational systems can scale across machines, and many NoSQL systems support transactions and strong consistency for at least some operations. Likewise, a flexible schema does not guarantee easier development, and a relational schema does not necessarily mean that the data is rigid or difficult to change.
Choosing between relational and NoSQL databases requires evaluating the actual workload, including how information will be written, searched, updated, connected, and recovered. Many organizations use several database types because different parts of an application have different needs.
How to choose the right database
The best database is the one whose data model and operating characteristics fit the application’s requirements.
A system managing bank transfers, invoices, and inventory may benefit from relational tables, explicit constraints, and transactions. A content platform handling varied document structures may find a document database more convenient. An application maintaining temporary session data may use a key-value store, while a network analysis tool may rely on a graph database.
Several practical questions help guide the decision. How structured is the data? Which queries will be most common? Must several changes succeed together? How much concurrent traffic is expected? Will the application need to distribute data across machines? How important are immediate consistency, low latency, recovery, and operational simplicity?
Cost and maintainability matter as well. A database may be technically capable of handling a workload but require specialized expertise, complex infrastructure, or unnecessary operational effort. A simpler system that meets the requirements reliably can be the better choice.
It is also important to distinguish the needs of an application today from its possible future requirements. Designing for hypothetical scale can introduce complexity before it is needed, while ignoring predictable growth can create expensive migration work later. A sound design starts with clear data requirements, selects a suitable model, and leaves room for change where practical.
Databases ultimately provide a disciplined way to manage information as it is created, connected, queried, and changed. Their internal structures and transaction mechanisms turn stored facts into dependable resources that applications can use. Understanding those mechanisms makes it easier to recognize why different database types exist and why choosing one involves more than simply asking how much data it can hold.