A Practical Guide to Choosing a Database
Deciding between relational databases, document stores and other options for a project.
Why does it matter?
Most web projects are well served by a relational database, and the wrong choice creates work that never ends.
What are the numbers?
- Relational databases handle structured data and transactions well
- Document stores suit flexible or nested documents
- Key-value stores excel at caching and simple lookups
- Operational cost each additional system needs monitoring and expertise
What should I do?
- Start with a relational database unless there is a clear reason not to
- Match the model to how data is queried
- Limit the number of data stores
- Plan backups for every store
- Test with realistic data volumes
What should I avoid?
Avoid:
- Choosing by trend
- Several data stores for one small product
- Schema-less designs without discipline
- Ignoring transaction needs
When should I get help?
Short answer Bring in help when data requirements are unusual.
Where this comes from
- Microsoft Learn — Choose a data store
- Laravel Documentation — Database: Getting started
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.