Jan Mikoláš
Glossary
Database
A database holds long-term business data. A cache and search index can speed up reads, but they are not usually the source of truth for orders or payments.
Short definition
Organised data storage with rules governing how data can change.
A database stores application facts so that multiple requests, users, or services can safely read and modify them. The DBMS handles physical storage, querying, concurrency, integrity, and, depending on its configuration, backup and recovery. The application builds business rules on top of it, but important data invariants should often also be protected by the database itself.
A database is not necessarily relational. A relational source of truth is common for orders and payments, a cache for short-lived results, and a separate search index for full-text search. Multiple data stores only make sense when each has a clear role, data owner, and method for updating derived copies.
The problem it solves
Data that must persist, be shared, and remain controlled
A database gives an application a persistent home for data and rules that must not break down under concurrent use.
- products, variants, prices, and inventory movements
- customers, orders, line items, payments, and refunds
- users, organisations, roles, and internal documents
- idempotent imports with unique external identifiers
- audit data and the state of integration processes
Practical model
Dividing responsibilities among data stores
PostgreSQL keeps the order and payment as consistent data. Redis can briefly cache an assembled product detail. Elasticsearch stores a derived document for full-text catalogue search. None of the derived copies may decide on its own whether an order has been paid.
This model lets each technology do the job it was chosen for while preserving a traceable foundation for the data.
How it works
From business data to derived copies
An online store may use several data stores, but each must have a clear role.
- Identifying the facts The application treats products, customers, orders, payments, and inventory as separate business data.
- Primary data store A relational database stores relationships and rules, such as the uniqueness of an external order or the link between a line item and its order.
- Reading and modifying data The application works with data through SQL, an ORM, or a database layer, and wraps critical local changes in a transaction.
- Derived values Redis can cache a product detail, while Elasticsearch stores a document used for full-text search.
- Recovery and oversight Backups, recovery testing, and monitoring are part of operations; a backup alone does not provide high availability.
Important concepts
A data store, a system, and a source of truth are not the same thing.
A sound architecture identifies what is the primary record and what is merely a copy.
DBMS and database server
A DBMS is software that manages data, such as PostgreSQL. A database server is a running instance of that software; a database contains the data and objects it manages.
Data and metadata
Order rows are data. Table names, column types, keys, and constraints are metadata that define their permitted shape.
Relational, document, and key-value stores
The relational model works with tables and relationships. Document or key-value stores use a different model; they are not inherently better or worse.
Source of truth
Primary data changes according to the application’s rules. A cache and search index can become stale and require invalidation or synchronisation.
Backup and recovery
A backup is a copy used for recovery after a failure or data loss. The recovery procedure must be tested, not just the existence of the backup file.
Benefits and limitations
Storing data is not enough on its own.
Benefits
- persistent storage and retrieval of structured data
- control of concurrent access and transactional changes
- the ability to enforce integrity close to the stored data
- backup and controlled recovery of operational data
Common mistakes
- confusing a database, a table, and a database server
- treating a cache or search index as the sole source of truth
- assuming that a backup automatically provides high availability
- adding more data stores without ownership, synchronisation, and monitoring
- assuming that choosing a database automatically produces a well-designed data model
Practical example
Online store: primary data, cache, and search
Products, customers, orders, payments, and inventory movements can live in PostgreSQL. When a price changes, the primary record is updated safely first; the cache is then invalidated and the search index updated. A cache outage must therefore never change the business truth—it should only make retrieving it temporarily slower.
This does not mean every small application needs three data stores. As long as a relational database and suitable indexes meet real needs, another system would only increase operating costs.
What to keep in mind
Define the owner and rules for changing every piece of data.
Clear responsibilities matter more than the number of databases in use.
- identify the source of truth for every important piece of business data
- protect relationships and uniqueness with database rules as well as application validation
- test backup recovery and understand the limits of the retention policy
- measure the actual problem before adding a cache or index
- treat the synchronisation of derived data as a separate operational process
Common questions
Databases in everyday applications
Is a database the same as a database server?
No. A database consists of data and database objects; a database server or DBMS is the software that manages them.
Why can’t a cache replace a database?
A cache can expire, be deleted, or contain an older value. Primary data therefore needs its own persistent, consistent source.
Is a backup the same as high availability?
No. A backup helps restore data after a failure. High availability keeps the service running during an outage through additional mechanisms.
Does every application need multiple databases?
No. An additional data store is worthwhile only for a specific need, such as full-text search or a shared cache, and with clearly assigned responsibility for the data.
How I apply this principle in practice
I build data models around a clear source of truth.
In e-commerce and integration applications, I design data, transactions, imports, and derived caches so that important states remain traceable.