“Relational databases don’t scale” has been repeated so often it’s outlived the era when it was mostly true. Modern Postgres and MySQL, properly designed and indexed, handle scale that would have genuinely justified a NoSQL migration a decade ago - and for the majority of business applications, with genuinely relational data (users, orders, permissions, all connected to each other), a relational database is still the right default, not the legacy choice it sometimes gets framed as.
Why relational modeling is still the right default for most business data
Most business applications have data with real, meaningful relationships - a user has orders, an order has line items, a line item references a product, permissions connect users to organizations. SQL and the relational model were built specifically to represent and query exactly this kind of connected data efficiently, with strong consistency guarantees and the ability to ask complex, ad-hoc questions across those relationships without redesigning your schema every time a new business question comes up. That flexibility is a genuine, ongoing advantage as a product’s requirements evolve - you can answer questions you didn’t anticipate when you first designed the schema.
What “modern” relational actually means in practice
- Proper indexing strategy, understood and maintained, not an afterthought - the single highest-leverage lever for query performance at scale, and the one most commonly neglected until performance problems force attention onto it.
- Read replicas for read-heavy workloads, separating read traffic from write contention - we covered this pattern in more depth elsewhere; it resolves the majority of scaling pain most applications hit before sharding is ever genuinely necessary.
- JSON and semi-structured data support built in. Modern Postgres specifically handles JSON columns natively and efficiently, meaning you don’t need to abandon relational modeling entirely just because part of your data is semi-structured - you can use the right representation for each piece of data within one coherent database, rather than splitting your data model across two different database paradigms for no strong reason.
- Extensions for specialized needs - Postgres specifically has mature extensions for full-text search, geospatial data, and even vector similarity search, covering use cases that used to require a separate specialized database entirely, further reducing the cases where you genuinely need to reach outside the relational model.
Where a relational database genuinely isn’t the right fit
Very high-volume, simple key-value access patterns (session storage, caching), genuinely unstructured or rapidly evolving schemas where relationships aren’t the primary access pattern, and specialized analytical workloads at massive scale (where a column-oriented database, as we’ve covered separately, is a better fit) are all legitimate cases for reaching outside relational. The honest architecture for most real applications is relational as the primary store, with specific, purpose-built stores layered in for these specific sub-problems - not one paradigm chosen for the whole system.
What we actually recommend
Default to a well-designed relational database for genuinely relational business data, and reach for a specialized store deliberately, for a specific, identified access pattern that relational genuinely handles poorly - not because relational databases have a scaling reputation problem that modern versions have largely outgrown.
We architect data layers as part of our backend engineering work, choosing the database paradigm based on your actual data and access patterns. Talk to us if you’re scoping a new data architecture or reconsidering a “we need to move off SQL” assumption.