Misconceptions on NoSQL have been around for a long time. This blog series is now wrapping up with a discussion of what it means to be “most dreaded” and what it means to give memory to a database.
Be sure to check out the previous posts in this series:
In this post, I’ll again look at some of the misconceptions that MongoDB has made about Couchbase and NoSQL.
Is Couchbase the “most dreaded database”?
Mongo calls attention to the Stack Overflow Developer Survey from 2020, which is now two years out of date. It’s true that Couchbase was ranked low on that survey. However, it’s not because developers ticked a box that said “I dread this database” (it’s inferred from checkboxes about projects planned over the next year).
Furthermore, the name “Couchbase” is often confused with the similarly named but otherwise very different “CouchDB” (a common mistaken assumption that even Mongo made on their webpage). That’s been proven out with the most recent results from the 2022 Developer Survey, which added CouchDB as a distinct option. Since 2020, Couchbase has continued to climb in the 2021 and 2022 survey results, with an increase of over 11 points since 2021.
And even more important to point out, is that while Couchbase certainly has work to do in terms of awareness, the top two databases in the survey are PostgreSQL and Redis. These are two databases that provide excellent SQL support and caching, as two separate products. Clearly, SQL and memory-first architecture are two things that developers want, and Couchbase already brings those things together.
For the 6,803 developers who “dread” working with Mongo, you might consider checking out Couchbase Capella, if you’re looking for the flexibility of JSON and the familiarity of SQL (two of the top three languages in the survey are JavaScript and SQL, after all).
Stack Overflow’s Developer Survey is important, and Couchbase is always working to improve the developer experience. If you’re interested in other surveys and awards where Couchbase did well, check out:
-
- TrustRadius Top Rated, awarded based on feedback directly from customers
- DBTA 100 – the companies that matter most, according to Database Trends and Applications
- Top 50 inspiring workplaces
- The Coolest Database System Companies of 2022
- 7 awards from G2, a peer-to-peer reviewing site
- A Product of the year from CRN.
Yes, we still have a lot work to do. But Couchbase cares about developers and will continue to build and improve to meet your needs.
Can’t every database use memory?
This last misconception is about how databases use memory. It can be a complex issue, but generally speaking, memory usage in databases breaks down into two categories:
-
- Buffering
- Caching
These terms describe very different things, but are often used (mistakenly) interchangeably.
What’s a buffer?
Simply put, a buffer is used to smooth out the speeds at which data is moved around. Results of a query could be put into a buffer, so that the client can read from the buffer instead of directly from the query process. Once the results are consumed, the data is no longer in the buffer.
What’s a cache?
On the other hand, caching is used to provide fast access to data repeatedly. The result of a key-value lookup fetched from disk the first time, can be stored in memory for the next time it needs to be accessed. Data will stay in the cache until it’s “invalidated” (expired, or kicked out, or whatever the caching mechanism is).
This presentation from Couchbase customer UPS discusses (among other things) Couchbase’s Managed Cache implementation, and the benefits of a managed cache:
It’s true that just about every database uses buffering and it’s true that the space for buffering could be adjusted, and that may improve performance. But it’s NOT true that every database has a built-in managed cache. This is why, for instance, Redis (a caching system) is often paired with databases that don’t have any caching capabilities.
Couchbase has a built-in managed cache, so you don’t need to bolt on any additional tooling for caching, or worry about it getting out of sync: it’s all automatic.
So, just keep this in mind when evaluating database memory configuration: does it affect buffering, caching, or both?
Should I just put everything in memory?
Well, sure. That’s one way to go. For certain databases sizes, this is feasible and affordable. For larger database sizes (e.g., multiple terabytes), that may not be the most affordable route. And you might not even be using enough of that data on a regular basis anyway.
Enter: Couchbase’s new Magma storage engine, which can bring multiple terabyte support to your data with as low as a 1% memory-to-data ratio.
What’s next?
Thanks for reading this series on NoSQL misconceptions.
Want to discuss further? You are welcome to join the Couchbase Discord for further conversation, questions, and answers with the Couchbase staff and community. Also check out the new Couchbase Community Hub.
