To SQL or NoSQL: Why Not Both?

There are many arguments for NoSQL over SQL. For example, it is undeniable that with MongoDB® you don’t have schema constraints, which makes MongoDB more flexible than SQL Server. Whether your data is formatted or it’s completely unstructured, you can easily store it in a document/JSON (non-tabular) format.

Similarly, many argue for SQL as superior, since your querying and data retrieval speed depend on the database schema. As a relational database, SQL Server has a predefined schema in the form of tables. All structured data is defined in a specific number of columns and rows within specific tables, ensuring the data stored is not incomplete or of low quality.

Early ease, later difficulties

No doubt in the 2010s, NoSQL  — and MongoDB in particular — was a popular first choice with large tech success stories like Stripe and Scale AI. However, infrastructure that worked for your company previously does not necessarily work well as your company continues to grow.

Both Stripe and Scale AI had to devote engineers to create solutions for working around the constraints of scaling MongoDB. One of the issues Scale AI faced in particular was incompatible aggregation queries:

“For aggregate queries, in the $lookup stage, the “from” collection can’t be a sharded collection. Also for single updates like findOneAndX, deleteOne, updateOne and update with {multi:false}, either _id or shard keys need to present the query."

And, this led to them having to build their own solution:

“We encountered a case for which we had to replace a heavily used, highly raced findOneAndUpdate query. We ended up replacing it with a function, which first executes a cursor find, then repeatedly loops through the cursor and tries updateOne until it succeeds.”

In Stripe’s case, they faced availability, performance and concurrency issues:

“On top of MongoDB, we wanted to operate a robust database infrastructure that prioritized the reliability of our APIs, but we could not find an off-the-shelf DBaaS that met our requirements:

• Meeting the highest standards of availability, durability and performance
• Exposing a minimal set of database functions to avert self-inflicted issues due to suboptimal queries from client applications
• Supporting horizontal scalability with sharding
• Offering first-class support for multitenancy with enforced quotas
• Providing strong security through enforcement of authorization policies

And similar to Scale AI, they built their own solution: “DocDB — with MongoDB as the underlying storage engine — a truly elastic and scalable DBaaS, with online data migrations at its core.”

Unfortunately, not every development or engineering team has the resources that Scale AI or Stripe has, nor the time to build a customized in-house solution. In these scenarios, there is a need for an out-of-the-box solution that is interoperable with your existing MongoDB — but has the ability to scale up, serve analytics and power client applications. This is why we built SingleStore Kai™.

Your road, not the high road

Instead of having to manually manage shards, then hitting $lookups limitations once you have them, Singlestore provides a distributed database with inbuilt and automatic shard management and scale out architecture that handles scale with ease, offering full support for all types of joins.

With SingleStore Kai,  we bring our technical innovations on the query engine and storage to you via your choice of interface and tooling. That means you can keep any existing business logic you had in Mongo query language, or augment/replace your back-end logic with SQL. To see how you can do this with any data you have in MongoDB, try out a demo on one of our Notebooks.