The BMW/Mercedes honesty problem - Why are NoSQL people still trotting out myths?
In this month's column for The Stack, former divisional CTO at Worldpay and IT veteran David Walker is a little frustrated with SQL myths and a lack of database category salesperson knowledge. Or is it ethics?
Some things in life are complicated: tax; love; the point of Tottenham Hotspur FC. And some things in life are simple. Always choose the steak if it’s on the menu –(your home frying pan can’t reach the same temperature as a commercial kitchen pan, so it will cook better!), no task will ever be completed in the time you estimated, and if you ask a BMW salesman to give you a fair verdict of a Mercedes, they just can’t—the inbuilt bias is just too strong.
You’d think that last one would be obvious, but a few conversations with CIOs have made me fear that some database vendors think they can pull the wool over their eyes by misrepresenting the full capabilities of the other fellow’s wares.
A case in point: vendors of NoSQL solutions telling big customers that SQL-based competitors can’t do x, could never do y—and that whatever your use case, their solution is the best fit.
All’s fair in love and database marketing? Maybe not
Don’t get me wrong: database companies love slagging each other off. We had so much fun doing it in the 1990s Database Wars that some people never lost the habit. And I’m all for competition, beauty contests and feature battles.
What I’m less keen on is those who provide partial, or inaccurate, or outdated competitive competitor summaries to potential customers. Especially when these customers then make very expensive decisions based on partial, inaccurate, and often outdated, information.
You might score one against the competition this way (ask Spurs—actually, don’t, that’s a very unfamiliar experience for them). But long term, perpetuating the good old IBM FUD (Fear, Uncertainty and Doubt) is bad for the database market and the industry.
It's not good for CIOs either. If nothing else, it’s a massive time suck. When I was on the other side of the fence and a CTO buyer, I could never trust anything the salespeople said, and I ended up doing double due diligence to work out what was real or not.
And because I couldn't rely on people to just stick to what they're good at and leave the opposition to talk about what they're good at, I ended up duplicating a lot of work. I’d often say, Guys: I’ll buy you next time. For this one, the other mob fit better. We’re all going to win in the end, don’t worry about it.
I’d like to think this carries over into what I do now, which is promoting a tech I really believe in—but which I know is not the only or best solution for every database use case that every possible customer has.
So, I will go out on a limb and say some NoSQL vendors are actively peddling myths about SQL (feeling the heat perhaps?!). This is definitely the case if you hear that you ‘can't’ use a SQL database for a particular business problem because they're too ‘rigid’ and they ‘won't scale’.
I won’t go into it here, but you hear very similar quacking noises from the Graph people, who also claim their brilliant, but very specialised, software is a universal Turing Machine for every problem.
Let’s jump in the database wayback machine
To see why this is a particularly pernicious method of, er, marketing, we need a quick history lesson for context.
Once upon a time, all databases were monolithic, on-prem, and all SQL-based. But, we started to see that they couldn't handle complex structures—what NoSQL databases called ‘documents.’ This is that sector’s term for a big, hierarchical structure of everything about the customer or product (essentially, any business entity).
When e-commerce was taking off, it turned out that it was a handy thing to have. It meant you had records of everything you knew about the customer, everything they owned, all their orders. Basically, all their history in one handy data structure (a cache) that you could stick in the database, press ‘FIRE,’ and off you went.
Even today, document databases are often the go-to choice. If you want to update information about a user, their preferences, or their wish list, you can do all of that very simply with a document database.
BUT… now you can do it in a SQL database too! A 1990s style SQL database… not so much.
SQL myths and my hairline...
But it’s not the 1990s anymore. (A quick glance at my hairline reminds me of this brutal truth only too well.) SQL has advanced incredibly since then. So, if the document database and other NoSQL people are still trotting this myth out, it must be that they don’t know anything about relational databases, or they are wilfully ignoring huge advances in database technology over the last two decades.
Is this misinformation ignorance or ill intent? I’m sure it’s (mostly) the former.
Saying SQL can’t do 90% of what a NoSQL database can in 2023 is just not true, even for good old monolithic SQL DBs such as MariaDB, MySQL, SQL Server, or even Oracle or PostgreSQL. It’s certainly untrue for Distributed SQL databases such as Cockroach, Spanner, or my company’s YugabyteDB.
Ultimately, NoSQL is great for some things, but not everything. One size does not fit all and when you have a hammer, just because everything looks like a nail does not make it true.
SQL data engines are a helpful solution for a lot of use cases. Any enterprise that is planning a database modernisation project needs to consider more important factors than whether it's easy to get started on Day 1 (which is why many developers love MongoDB for example). It needs to still be great to work with on Day 365.
They’re also not (and have never been) great with transactional data. If you want to move money from one bank account to another you must be able to update two entities. The account details of customer A and customer B, plus a document approach just doesn’t guarantee that everyone ends up with the correct amount in the end.
So, use NoSQL. It has superb applicability for some things and should be part of your portfolio. Use SQL for other problems. Use graph too. Don’t assume that one approach (or technology) works for everything; for some problems, an abacus is the ideal tool!
BUT always check vendor claims. If they say X can’t do this because of something a bit hand-wavey, push back. That includes claims from my company! Only adopt what makes sense for you, and only ever select the technology most appropriate for the business problem.
As Dr Pepper used to say: What’s the worst that could happen?
Which brings us back to the simple things in life. You'd be mad to listen to a car salesman detail why you shouldn't buy a competitive car brand. So, why on earth would you give credence to competitive information from a rival database vendor?
At the very least, give both a test drive. You might love the other option… and save a load of money on back-pedalling when it turns out you made the wrong choice.
