The five-question brief
- 01What must the system answer quickly?
- 02Which writes must succeed or fail together?
- 03How large and uneven can the workload become?
- 04How much data loss and downtime are acceptable?
- 05Who will operate this at 3 a.m.?
Databases / Choose
How to choose a database.
Start with the work your application must do. Turn its queries, business rules, and failure limits into a decision you can explain and test.
Know the options
Choose across the database landscape.
Explore 49 engines and services from Google Cloud, Microsoft and Azure, Amazon Web Services, Oracle, and other established platforms. Compare what each does and what you would need to verify.
Browse all databases →01
Choose
Start with the question, not the product.
A database choice is a hypothesis about your workload. Make its assumptions explicit and test them.
Make complexity earn its place.
For many applications, one relational database can handle core records, transactions, and initial reporting. Start with the smallest architecture that meets your requirements.
Add another store when a measured workload or failure boundary justifies the extra coordination.Two situations. Different tradeoffs.
During a network partition
A distributed system cannot guarantee both linearizable consistency and a successful response to every request at a non-failing node.
During normal replication
Waiting for coordination can increase latency, especially across regions. Specify which reads need fresh data and which can tolerate delay.
Read the PACELC explanation ↗This is not a universal “choose two” rule. Replica freshness and transaction isolation are separate questions.
From requirements to a decision
Write a brief before building a shortlist.
List the operations that matter: create an order, reserve stock, fetch recent activity, search a catalog, or aggregate a month of events. For each one, record its filters, ordering, expected result size, peak frequency, and acceptable delay. A user count alone cannot describe database work.
Then identify the writes that must succeed or fail together. An order and its stock reservation have different correctness requirements from a dashboard that can refresh a few minutes later. Record both the transaction boundary and what readers must see after a successful write.
Finally, name the person who owns recovery. A service that saves infrastructure work may still require index tuning, access reviews, restore drills, and cost management. Compare the whole operating commitment.
Test the deciding constraint
Make the evaluation answer a question.
Use representative records, realistic data skew, and concurrent clients. If the concern is regional writes, measure coordination from the regions that matter. If it is recovery, restore an independent backup into an isolated target. If it is a growing report, inspect how its query plan changes with data volume.
Record configuration, data size, concurrency, and the result. A fast demonstration with a tiny dataset is useful for learning an interface; it cannot establish that the production workload will meet its targets.
Follow the worked orders-service example →