SQL or NoSQL for your system?

The choice between SQL and NoSQL sounds like a technical detail, but it shapes how your system behaves for years. It’s also a choice where trends and enthusiasm often lead you astray. Here’s the decision at the paradigm level, with a practical rule of thumb you can lean on.

What the relational model gives you for free

A relational database (SQL) stores data in tables with a fixed schema and clear relationships between them. That structure can feel rigid, but it gives you three things without your having to build them yourself.

• Transactions. Multiple changes happen completely or not at all. An amount is debited from one account and lands in another in the same stroke – never halfway. The moment money, inventory, or bookings are involved, this is invaluable.
• Consistency. The database watches over how data hangs together. An order can’t point to a customer that doesn’t exist, if you’ve told it to care about that.
• Ad hoc queries. You can ask questions you didn’t think of when you built the system – “how many customers in Gothenburg ordered more than three times last quarter” – without having prepared that exact view in advance. That’s enormously valuable when reporting needs come up, and they always do.

What you pay for that is a schema you have to stick to and a bit more upfront thought. For the vast majority of systems, that’s a good trade.

When NoSQL actually wins

NoSQL is an umbrella for databases that deliberately depart from the relational model. They solve real problems – but specific ones.

A document database stores whole objects (for example, a product with all its variants) as a single document. It fits when data naturally clumps together and rarely needs to be cross-referenced with other data, or when the structure varies widely between records.

A key-value database is essentially a giant lookup table: give it a key, get a value, lightning fast. Perfect for sessions, caching, and simple storage at large scale.

The shared upside is scale and flexibility. NoSQL databases are built to spread across many servers and swallow massive data volumes, and they don’t force you into a fixed schema. The price is that you often have to give up free-form queries and strong transaction guarantees – exactly what the relational model gave you for free.

The rule of thumb: relational until proven otherwise

If you’re unsure, choose SQL. That’s the ground rule experienced teams land on, and the reason is simple: the relational database is forgiving. It handles an unexpected report, a new relationship, and a growing requirement without you having to rebuild. A modern relational database also scales a long way – most systems never reach the volume where SQL becomes the bottleneck.

Switch to NoSQL when you have a concrete, proven need: data volumes a single relational database can no longer handle, a pure key-value load, or data whose structure varies so much that a schema becomes a straitjacket. Note the word proven. “We might need to scale like a global giant” is rarely a real need for a Swedish company that hasn’t even launched yet.

The common NoSQL regrets

The typical mistake looks the same time after time. A team picks a document database early, often because it felt modern and quick to get started with. Everything goes fine – until reality catches up.

First, someone wants a report that cross-references data in a new way. In a relational database, that would have been a query; now it becomes a build project, because the database wasn’t made to connect things that way. Then relationships grow in anyway: the order needs to know about the customer, the customer about their invoices. You end up building relationships by hand on top of a database chosen specifically to avoid them.

The ending is often an expensive migration back to SQL, or a half measure where business logic the database should have handled leaks into the application code. It’s not that NoSQL is bad – it was just used for a problem it wasn’t built for.

So weigh the choice against what the system actually needs to do. If you’d like help reading where your build is heading, we at Weapp are happy to look at the data model together, and talk through the choice before it sets in the code.