NoSQL may be a “complete game changer,” but that doesn’t mean it’s right for your next application.
Or, rather, for you.
As with any technology, the “mileage” you get from NoSQL varies depending on your team’s expertise and culture. As Uber’s recent switch from PostgreSQL to MySQL indicates, sometimes the right technology fit can be a poor culture fit.
Is NoSQL the right technology choice?
As data gets “bigger,” measured in terms of volume, velocity, and variety, NoSQL is increasingly the right choice for application data. For applications (and developers) that prioritize speed, manageability, agile development, and easier horizontal scale, NoSQL is becoming the default.
But, as MongoDB used to highlight on its community site, sometimes a relational database is a better fit:
- Problems requiring SQL. If your application depends upon SQL for queries, you’re likely going to be better off with an RDBMS.
- Systems with a heavy emphasis on complex transactions such as banking systems and accounting. There are workarounds and databases like Cassandra and MongoDB have evolved since this was written, making them better fits for applications that require multi-object transactions, for example. But these still aren’t the ideal use case for NoSQL databases.
- Traditional Non-Realtime Data Warehousing. This is decreasingly the case, but historically this hasn’t been a strong suit for NoSQL.
And, of course, if your application data is already relational in nature, swapping it out may not gain you much.
But if you’ve noticed, I’m hedging on several of these, because since MongoDB first penned the Use Cases page, many things (at MongoDB and in other NoSQL databases) have changed, expanding the universe of potential applications for which they’re useful.
Even so, NoSQL may not be right for you. Just ask Uber.
Uber swaps like for like
As described in a blog post, Uber was looking for a PostgreSQL replacement. Most of its data was stored in the venerable (and popular again) open-source database.
As Uber grew, its trips data (by far the majority of its data) exploded, and “the trips table in PostgreSQL had grown so big that any operation that needed to add a new column or add a new index caused downtime. This made it increasingly cumbersome to develop new features.”
In my last post, I described how Craigslist, faced with a similar quandary, dumped MySQL for MongoDB and was able to significantly accelerate product innovation.
Uber chose a different path.
Intriguingly, the company clearly saw that it had a problem well-suited for a NoSQL fix: “We decided that a column-oriented, schemaless approach where data (JSON blobs) are organized in a grid indexed by trip-UUID, column name, and optionally a timestamp would work well as an overall data model.”
In other words, a NoSQL database.
However, “we didn’t feel confident [the NoSQL databases we evaluated] were a good fit for storing our trip data, because of either our operational experience or the product’s maturity.”
And so Uber went with MySQL, another open-source RDBMS, which it then had to manipulate to make it more like a NoSQL database.
You’re not Uber
Most companies, however, don’t have the engineering chops (or the patience) to make the considerable investment required to transform an RDBMS into a NoSQL-like product. And yet, NoSQL still may not be the right tool for you.
As Etsy’s CTO told me, his company favors “a small number of well-known tools” geared toward “long-term operability of the software.” For them, that meant going with the comfort of MySQL, even when the data didn’t necessarily lend itself to an RDBMS.
Because company DNA matters.
I still think we’ll see enterprises heartily embrace NoSQL over the long term, even those that today remain skittish. But it’s normal that DBAs and developers steeped in RDBMS learning would resist NoSQL.
The question is how long they can get away with it. Jobs data already suggests that NoSQL interest is blowing past the most popular relational databases in terms of relative growth. This suggests that companies, once hesitant, are embracing NoSQL. Whether your company should, too, depends largely on your own DNA.