The five-question brief
- 01What must the system answer quickly?
- 02Which writes must never be partially applied?
- 03How large and uneven can the workload become?
- 04What happens when a region or node disappears?
- 05Who will operate this at 3 a.m.?
Field manual / 01
Choose the rightdatabase. Build it right.
Practical guides and decision tools for selecting, modeling, and operating databases without vendor noise.
- 01
- Workload first
- 02
- Tradeoffs visible
- 03
- Operations included
Database selector / Decision plateInputs → recommendation
Selection notes
- ACID transactions
- Rich SQL
- Broad ecosystem
- Growing app deployment profile
Strong starting point
PostgreSQLRelational
A durable default for applications that need transactions, relationships, and flexible querying.
See the comparison →Field note: Start simple, measure the workload, and add complexity only when the evidence demands it.
Topology diagram / example only
users
orders
products
inventory
payments
— primary┄ derived□ data store
01
Choose
Start with the question, not the product.
Every database is a bundle of tradeoffs. Describe the shape of the work before comparing feature lists.
Use the boring default until it stops being boring.
For many products, a relational database covers transactions, reporting, JSON, search extensions, and geospatial work well enough to start.
Complexity is a cost. Make it earn its place.ConsistencyAvailabilityLatencyChoose deliberately
Comparison plate / 02
Know the families before the brands.
Database categories describe how information is organized and which questions are cheap to answer. Products often span more than one family.
| Family | Good fit | Core model | Examples |
|---|---|---|---|
| Relational | Orders, accounts, core business data | Rows + relationships | PostgreSQL, MySQL |
| Document | Flexible records, content, catalogs | JSON-like documents | MongoDB, Couchbase |
| Key-value | Caching, sessions, fast lookups | Keys + values | Redis, DynamoDB |
| Columnar | Analytics, telemetry, reporting | Columns + partitions | ClickHouse, BigQuery |
| Search | Full-text discovery, relevance | Inverted index | Elasticsearch, Typesense |
| Graph | Fraud, networks, dependencies | Nodes + edges | Neo4j, Neptune |
Not a leaderboard. Product examples are reference points, not endorsements. Validate current capabilities, pricing, and operational fit before committing.
02
Design
Model the decisions the system must preserve.
A good schema makes valid changes straightforward, invalid states difficult, and common questions inexpensive.
Name the nouns and the rules between them.
Start with business meaning. Decide ownership, cardinality, optionality, and what deletion should do before drawing tables.
Customer1placesNOrder
Design for the questions you will actually ask.
List critical reads and writes with expected frequency, latency, and result size. Index from evidence, not instinct.
GET orders WHERE customer_id = ? ORDER BY created_at DESCAssume the model will evolve.
Prefer reversible migrations, observable rollouts, and explicit compatibility windows. Data outlives most application code.
v1→v2→v3
One database is often the right first architecture.
Split systems when workloads, ownership, scale, or failure boundaries clearly differ. Every additional store creates coordination work.
03
Operate
A database is a responsibility, not just a dependency.
The design is incomplete until recovery, observability, ownership, and cost are part of the plan.
Backups
Automated, encrypted, and tested with real restores.
Observability
Latency, errors, saturation, replication, and slow queries.
Capacity
Headroom for peaks, growth, maintenance, and failure.
Security
Least privilege, rotation, auditability, and network boundaries.
Ownership
A named team, documented runbooks, and escalation paths.
Cost
Storage, compute, transfer, licenses, and human operations.
Field notes / Updated continuously
Build database judgment, one practical guide at a time.
SQL or NoSQL is the wrong first question
Replace the false binary with a workload brief.
Read field note →Indexes: the performance feature with a write bill
Understand what each index accelerates and what it costs.
Read field note →A backup is not real until you restore it
Turn recovery objectives into a routine, testable process.
Read field note →The database briefing