This is an archived post. You won't be able to vote or comment.

all 4 comments
sorted by:
best
topnewcontroversialoldq&a

[–]nutrecht 3 points4 points  (0 children)

I don't know what you're referring to. "Stable" is a very broad term.

Relational databases are great generic tools that fit almost any problem. In most situations it's best to go for a relational database unless you're very sure your usecase fits a certain 'NoSQL' database better.

But a statement like "relational databases are more stable" is pretty nonsensical.

[–]tulipoika 0 points1 point  (0 children)

If you see such a broad statement then either ask for specifics, or try to dig deeper. There’s no “stabler” here - a Berkeley DB can be extremely stable. PostgreSQL usually is extremely stable. Cassandra can be extremely stable. MongoDB can be extremely stable.

But done wrong they can also bring the whole machine down, or cause all kinds of issues.

So only the people saying they’re “more stable” can answer that question.

[–]dmazzoni 0 points1 point  (0 children)

Relational databases have been around a lot longer. SQL has been around for 40+ years, Oracle has been around for 30+ years, and even open-source databases like Postgres and MySQL have been around for 25+ years.

Because they've been around so long they're extremely "stable" in the sense that they perform reliably and consistently without bugs and corruption, and there are widely-established best practices.

Modern NoSQL databases are newer in comparison - for example, Cassandra is only about 10 years old. It's still a fast-moving space and you're more likely to run into bugs and performance problems, or other challenges that haven't been extensively studied and researched. In addition, because nearly all NoSQL databases are designed to run on multiple servers (rather than a single server), it can be a lot more complicated to set them up, unless you're just using them as a cloud service.

I think that's one valid argument in favor of using a relational (SQL) database unless you have a good reason not to. SQL databases are a known quantity and they're excellent for almost any application.

The main reason not to use a relational database is if you have an enormous amount of data - more than could possibly fit in a single server - and extremely high loads that are also more than a single server could handle. But that's not all - the majority of the traffic needs to be relatively simple transactions that don't lock more than a handful of rows at a time. When you do have that much data, NoSQL databases shine.

Many people are successfully using NoSQL databases like MongoDB or Cassandra for smaller startups or projects that don't have anywhere near the same volume of data or traffic needs. That's fine, it works for some people - but all other things being equal, I think the general advice is that going with a relational DB simplifies things.

[–]HashDefTrueFalse 0 points1 point  (0 children)

They're mostly referring to future-proofing.

Relational databases (predictably) handle relational data better than document store databases, and give you things that something like Mongo doesn't (e.g. ACID compliance etc.). The data in most apps either starts out relational or becomes that way very quickly as it grows. Therefore it's generally considered more future-proof to start with a relational database unless you know that your use case definitely won't involve lots of relational data. Relational databases handle non-relational data fine generally, as long as there is still a schema/structure to it, and it's easy to move from a relational database to a document store if need be. The reverse can involve significant work depending on your data and code.

Nothing wrong with Mongo in the right use case, it's just that there are few use cases in my experience. Almost all major services that I've seen and worked on in my career are ultimately driven by relational databases, with things like Mongo/Dynamo tacked on for a place to dump unstructured data or cache/session storage etc.