In short
Use a relational database for most new products. Relational databases now handle JSON well, scale further than most applications need, and give you constraints, joins and transactions that prevent whole categories of bug. Document databases suit genuinely schema-variable data and specific access patterns, but the flexibility they offer usually turns into inconsistency once several developers and a few years are involved.
The categories converged
Much of the original argument is obsolete.
Relational databases now have strong JSON support with indexing, so "we need flexible fields" no longer requires leaving. They scale far beyond what most applications reach, and managed services handle replication and failover.
Document databases added transactions, stronger consistency options and schema validation — the features whose absence was the original objection.
So the choice is narrower than it was, which is why the honest answer for most teams is unexciting.
Why relational is the right default
Constraints prevent bugs you would otherwise write. Foreign keys stop orphaned records. Unique constraints prevent duplicates without a race condition. Not-null catches missing data at write time rather than three screens later. These are guarantees, and application code cannot provide them because application code can be bypassed by a script, a migration, or a bug.
Joins are genuinely useful. Most real data is relational — users belong to organisations, orders contain items, invoices reference customers. Modelling that in a document store means either duplicating data or doing joins in application code, which is slower and easier to get wrong.
Ad-hoc querying. Someone will ask a question nobody anticipated. SQL answers it without a migration or a new index designed in advance.
Transactions across records are well understood and reliable.
The ecosystem is deeper. More tooling, more expertise available to hire, more answers when something goes wrong at 2am.
When a document database genuinely fits
Truly variable structure. Documents where fields differ meaningfully per record and no sensible common schema exists — event payloads from many sources, product catalogues spanning unrelated categories.
Whole-document access patterns. If you always read and write an entire document and never query across them by their internals, that maps well.
Extreme write throughput where you can accept weaker guarantees.
A document model matching the domain exactly, where relational modelling would mean many joins to reassemble one object on every request.
The flexibility trap
The most common reason teams choose a document store is we don't know the schema yet.
That is genuinely appealing at the start and expensive later. The schema still exists — it just lives in the application code, and in several versions of it, and in whatever the data actually contains after two years.
What happens in practice: three shapes of the same document, written by three developers at different times. Code full of checks for whether a field exists. Migrations that must be written in application code and run over millions of documents. And no single place to discover what the data is supposed to look like.
A relational schema forces the decision earlier, when it is cheap. That constraint is the feature, and it is why "we'll figure out the structure later" is usually a decision to figure it out repeatedly, in production.
What actually decides performance
Not the category. Indexing, query patterns, and schema design.
A well-modelled relational database with appropriate indexes outperforms a badly modelled document store, and the reverse holds too. Teams that switch databases hoping to fix performance usually find the same problems reappear, because the problem was the access pattern.
Before concluding your database is the constraint, look at the slow query log. It is almost always a missing index or a query doing something in application code that should have been one statement.
Using both
Common and often sensible. Relational for core business data where correctness matters — users, orders, payments — and something else for the workload that genuinely suits it: a document store for event payloads, a cache for hot reads, a search index for text.
The cost is operational: another system to run, monitor, back up and reason about. Worth it when there is a real need, and not worth it for variety.
Note also that a relational database can often cover several of these. Postgres handles JSON, full-text search and vector similarity competently, which frequently removes a second system from the architecture entirely — the Postgres or MySQL question matters less than whether you needed the second database at all.
The recommendation
Start relational. Use JSON columns for the genuinely variable parts rather than abandoning the model for them. Add a specialised store when you have a specific workload that justifies it.
The teams that regret this decision are almost always the ones who chose flexibility early and spent two years discovering what their schema was — not the ones who wrote a migration.
If you are choosing a data model for something that will hold real data for years, book a call.
Common questions
Should I use SQL or NoSQL for a new product?
Relational, in most cases. It gives you constraints that prevent entire categories of bug, joins for data that is genuinely relational, ad-hoc querying for questions nobody anticipated, and a deeper ecosystem. Modern relational databases also handle JSON well, which removes the original reason to leave.
Isn't NoSQL better because you don't need a schema upfront?
The schema still exists — it just moves into your application code, in several versions written by different people at different times. Teams typically end up with three shapes of the same document, code checking whether fields exist, and migrations written by hand over millions of records.
When does a document database genuinely make sense?
When structure truly varies per record with no sensible common schema, when you always read and write whole documents and never query across their internals, when you need extreme write throughput and can accept weaker guarantees, or when the document model matches the domain exactly.
Will switching databases fix my performance problem?
Usually not. Performance is determined by indexing, query patterns and schema design rather than by category, so the same problems tend to reappear after a migration. Check the slow query log first — it is almost always a missing index or work being done in application code that should be one statement.
Can I use both SQL and NoSQL?
Yes, and it is often sensible — relational for core business data where correctness matters, something else for a workload that genuinely suits it. The cost is another system to run and monitor, so it should answer a real need. Note that Postgres already covers JSON, full-text search and vector similarity.
