[ ] Yeah. Well, I do have opinions on the topic; they’re generally favorable to the relational databases… The thing about a NoSQL database as far as I – probably I should preface this by saying that I’m not the most experienced guy in the world with NoSQL databases; I haven’t used that many of them. But the problem when you talk about them, in my opinion, is that they’re not all the same, so it gets pretty tricky to bucket them all into one category. When I talk about the pitfalls, probably different people who work on a different NoSQL database will say “Well, that one doesn’t apply to us” or “That one is more nuanced with us…” Because as I was saying earlier, some of the NoSQL databases I think are generally evolving into – they are incorporating features that were traditionally a part of relational databases.

Some of the big ones are support for general transactions - this idea that you can atomically change a bunch of stuff and do a bunch of freezes on your database, and then you decide to commit or to roll back that transaction as an atomic unit, and this unit of work is isolated from other transactions, meaning you cannot see dirty data, you cannot see something that somebody else did, but didn’t commit yet; you cannot observe partial work done by somebody else.

This is an extremely powerful concept, and you only discover how powerful it is when you try to use a system that doesn’t have it, and then you try to pile on code in your application that tries to supplement for the lack of transaction support, and then chances are it’s gonna be insufficient, or you’re most likely going to get it wrong.

In the meantime, some NoSQL databases are expanding their support for transactions towards more and more general support, but I think by and large they’re still pretty far from what your traditional Oracle or MySQL database offered from back in the day. So I think that’s one of the big pitfalls - if your NoSQL doesn’t have transactions, you probably really have to think a couple of times before committing to use it for a large project, because you will need them. And then transactions are not strictly about SQL or NoSQL, they’re not about the query language, but they tend to get associated with relational databases.

Then the other thing specifically about the SQL language - or lack thereof - is that people say “My application is pretty simple. I have a RESTful API, I need to write small units of data into one table or into one document store, I need to write one document type at a time, I need to read one record at a time… I don’t do fancy stuff; I don’t need joins or all sorts of complex analytical queries, all sorts of grouping, or ROLLUPs, or what have you. And I think pretty often that’s true, in the beginning, for a database, but then as soon as you open the door a little bit to people to have access to your data, very soon you’re gonna get people who want to do a little bit of analytics, and then a little bit more of analytics… “I just wanna see what is my biggest customer. Why can’t I just write a query that gives me that?”, stuff like that.

[ ] So the SQL language - there’s a reason why it existed for four or five decades, and it continues to live on, even though in some ways it’s not ideal. It does show its age in some ways, but it’s still the only widely used data querying language… And I think the reason is that it is very powerful, and even if you don’t need – nobody needs all of it, but most people need some of it. I don’t know, I would not be satisfied with a database that has a much less sophisticated querying language that doesn’t let me express most of the queries that I wanna make… So that’s my bias and opinionated side on this war.