What is Database?
Definition
A database is an organized collection of data stored so that it can be reliably saved, queried and updated. Applications work with it through a database management system (DBMS), which handles storage, queries, concurrent access and permissions. Databases broadly fall into relational (SQL) systems that keep data in related tables, such as PostgreSQL and MySQL, and NoSQL systems that use document, key-value, wide-column or graph models.
Also known as: DB, DBMS, database management system

Database vs. DBMS
The two words are often used interchangeably, but the database is the data itself, while the database management system (DBMS) is the software that stores it, answers queries, coordinates concurrent requests and enforces permissions. PostgreSQL, MySQL, SQL Server, MongoDB and Redis are all DBMSs. Applications reach the data by sending queries to the DBMS, not by reading files, and when data has to be shared with other systems they usually put an API in front instead of exposing the database directly.
Relational databases
The relational model stores data in tables of rows and columns, links tables through keys and queries them with SQL. The schema is defined up front: a column's type, whether it may be empty and which table it references are all enforced by the database. Open-source PostgreSQL is a mature example of this family; alongside relational tables it handles JSON data, full-text search and, through extensions, vector search.
SELECT c.name, SUM(o.total) AS revenue
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= '2026-01-01'
GROUP BY c.name
ORDER BY revenue DESC
LIMIT 10;This query joins two tables on the customer ID and lists the ten customers with the highest revenue since the start of the year. Keeping each fact in one place and letting the database guard the relationships is what makes questions like this reliably answerable.
ACID transactions
The defining strength of relational databases is running multi-step operations, or transactions, safely. The guarantees are summed up as ACID:
- Atomicity: either every step of the transaction happens or none does. If money cannot be added to the destination account, the debit from the source is rolled back too.
- Consistency: a transaction moves the database from one state that satisfies its rules to another.
- Isolation: concurrent transactions do not see each other's half-finished work; how strictly depends on the chosen isolation level.
- Durability: once a transaction is committed, it survives even if the server crashes immediately afterwards.
The transactions chapter of the PostgreSQL documentation walks through these ideas with a concrete bank-transfer example.
NoSQL databases
NoSQL is a broad umbrella for databases that do not use the relational table model. The main families are:
- Document databases (e.g. MongoDB) store records as flexible, JSON-like documents.
- Key-value stores (e.g. Redis) read and write a value by its key extremely quickly and are often used as a cache.
- Wide-column databases (e.g. Cassandra) are built to spread very high write volumes across many servers.
- Graph databases (e.g. Neo4j) treat relationships between records as first-class data.
- Vector databases store embeddings of text or images and find items that are close in meaning.
Generalisations such as “NoSQL is faster” or “NoSQL has no transactions” are misleading. Some NoSQL systems support ACID transactions under certain conditions, and many relational databases handle flexible JSON fields comfortably. The shape of the data and how it is accessed should drive the choice, not the label.
Questions to ask when choosing
- How connected is the data, and how critical are reporting and consistency? For business records such as orders, invoices and stock, a relational database is usually the safest starting point.
- Does the structure change often and unpredictably?
- Is the workload read-heavy or write-heavy, and will the data fit on one server?
- How will backups, restores and monitoring work? A backup that has never been test-restored cannot be trusted.
In a microservices architecture each service commonly owns its own database, which can lead to several database types living side by side in the same project.

