Misconceptions about NoSQL have been around as long as NoSQL itself. It’s always good to get different perspectives, and so this blog series continues. I’ll be discussing NoSQL misconceptions, specifically when it comes to two of the top document database companies in the world: Couchbase and MongoDB.
In this post, I’ll again look at some of the misconceptions that Mongo has made about Couchbase and NoSQL, and one of the more common misconceptions and misunderstandings that I’ve heard in the developer community about NoSQL in general.
Be sure to check out the previous posts in this series:
Is NoSQL secure?
Some of the early (and even relatively recent) days of NoSQL had some glaring, high-profile security issues. Here are just a few:
Anyone casually reading news about NoSQL might have the impression that NoSQL is the wild west, when it comes to security. For a while, it was. “Easy to get started” often meant “Insecure by default”.
But NoSQL doesn’t have to mean “No Security”. Couchbase Capella and cloud service providers like AWS and Microsoft have worked hard to make security a priority.
- Couchbase Capella Security and Data Protection: this white paper covers security and data protection from the highest levels down to implementation details.
- Capella has also received SOC2 compliance certification.
- Capella automatically uses the cloud provider’s underlying encryption.
- Fine-grained access management, private networking, multi-factor authentication, monitoring, and alerts are just a few of the security features included.
And if you want to run and manage Couchbase Server instead of Capella, you still have access to the full range of security features.
Will NoSQL Lose my Data?
You may have seen headlines like this one: Jepsen Disputes MongoDB’s Data Consistency Claims.
Many NoSQL systems make different trade-offs with data operations, in order to reduce latency and increase performance (one of the key reasons people switch to NoSQL in the first place). This is a difficult thing to get right, and in the past, this has led to edge case issues that can result in data loss. “Eventual consistency” is also a cause of reticence for many.
These trade-offs were in place in order to acquire better numbers that look good in marketing benchmarks. But in reality, what modern, mature NoSQL (like Couchbase) gives you is: control.
- Couchbase is strongly consistent.
- Couchbase is fully tested with Jepsen.
- Raft is used for metadata consensus.
- If you want to reduce risk against extremely rare edge cases, you have the control to do so.
The longer story:
- Data storage within one Couchbase cluster is strongly consistent. You save data, it will save to memory, and then to disk, and then to other nodes (automatically and asynchronously).
- If you are worried about edge cases due to async, you can specify stronger durability requirements. You can do this per-operation if you want.
- Query indexes in Couchbase are updated asynchronously (eventually), to avoid slowdown, having to wait on indexes when creating/updating data.
- BUT, when querying, you can specify consistency level, again, on a per query basis. When you need to read up-to-the-microsecond query results, you can trade-off latency to do so.
Data storage when you have two or more Clusters synchronizing between data centers is eventually consistent. This means if you make a change to a document in, say, US East, the matching document in US West will get updated a few microseconds later. (And conflicts can be managed automatically). This only applies if you are using multiple data centers.
There are always edge cases with any database, not just NoSQL. However, modern Couchbase NoSQL has sensible defaults built-in, with a variety of options when you need them.
Does NoSQL mean “No ACID”?
Again, to initially provide low-latency, high-performance reads and writes, ACID transactions were not part of the early days of NoSQL. For a relational database user, this was often seen as a red flag.
However, as I’ve noted in the past, ACID isn’t only about transactions, and plenty of NoSQL databases can provide ACID guarantees.
That being said, multi-document ACID transactions have been available in Couchbase Server as far back as version 6.5.
On Mongo’s comparsion page, Couchbase’s ACID transactions are characterized as “extremely limited”. There’s no more detail than that, so I can only speculate that this is an outdated reference to transactions being initially available as a preview to Java developers (and Scala/Kotlin by extension). But in the meantime, ACID transactions have been added to .NET, Node, PHP, Go, Python, and C SDKs, with more to come. And not only that, ACID transactions are available to anyone using the new BEGIN/COMMIT/ROLLBACK feature in SQL++.
SELECT COUNT(*) FROM airport WHERE city='Stanted';
UPDATE airport SET city='London' WHERE faa='STN';
DELETE FROM airport WHERE city='London' AND faa != 'STN';
ROLLBACK TRANSACTION TO SAVEPOINT s1;
And complex sharding scenarios don’t even enter into the equation, unlike with Mongo.
- Modern NoSQL is secure.
- Modern NoSQL won’t lose your data.
- Modern NoSQL supports ACID transactions.
It’s okay for other NoSQL databases not to support these features: there’s plenty of room for niche specialization. But for Couchbase, these are mature features used by large organizations for critical use cases.
So, if you haven’t checked out NoSQL in years, maybe it’s time to sign up for a free trial of Couchbase Capella. No credit card required.
In the next post, I’ll dig into more misconceptions: is NoSQL really all that good at scaling? Which NoSQL is most popular, and why does that matter?
Want to discuss further? You are welcome to join the Couchbase Discord for further conversation, questions, and answers with the Couchbase staff and community.