Maybe I never got deep enough into "NoSQL" DBs such as Mongo, but they always struck me as a bit lazy with a "design as you go" philosophy. The functionality seems to focus around fetching individual records, not the deeper analytics / queries you find frequently with RDBMS. The query languages I've seen are imperative, which encourages and processing after the fetch on the client.
And since it encourages "winging" it, the DBs tend to be poorly structured/documented. Which is OK for some applications I guess.
I don't think NoSQL vs SQL is a real debate. SQL is great and should be used wherever performance allows for it. Whenevre performance does not allow for it, use nosql.
I have some highly normalized data and every time i do a get i have to do a bunch of joins. I have to do a ton of reads on this data. So what I do is have a nosql db in conjunction with my sql db and the user can hit a "publish" button that stores a denormalized version of data in the nosql db that is automatically replicated all over the world and gets are super cheap.
>SQL is great and should be used wherever performance allows for it
I feel like this is worded poorly. SQL has better performance than most noSQL databases (eg. document databases) for many types of queries. The issue with SQL has historically been cost and scaling, (both of which have been at least partially solved in recent years)
I think what people actually want is SQL layer that runs on an engine that has NoSQL performance characteristics that supports a flexible data schema. As S3 has shown, a non-trivial amount of data applications are very basic get/put. Yes yes, now that it’s so dominant, that’s how people are designing access patterns which is skewing things, but it’s success should tell you something about what people want.
NoSQL is way harder than SQL to get right if you're trying to write something performant - and you don't want to refactor everything down the line. I pick SQL because I'm lazy, not the other way round.
The only upside of NoSQL is performance. Almost everything else is harder and worse than SQL. Sure you can get your denormalised schema and never have to join anything to get all your data. But, you need to know all of your access patterns at design-time and when you need to refactor the data model in some way you're fucked and need to, I dunno, rewrite an entire table, sometimes on the fly while the system is running, which is like changing a tyre on a moving car.
I've returned to SQL after years of "lazily" enjoying NoSQL and I gotta say, SQL would do well to stop relying on a thesaurus. It feels like I'm writing COBOL. I don't understand why I need to feed English to a Zork parser when I know exactly what operation to perform. An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant.
A poem that has been consistent and frozen for 50 years, that works 99% same across all vendors?
We tolerate the SQL as it is, warts and all, because as soon as you bikeshed it it will explode into 50 different dialects. Just look at JSON for example.
I think that is a gross overstatement. The language has evolved (and should evolve) substantially over the last few decades. Experience from the NoSQL world has influenced SQL (though obviously not always as much as I'd like). I'd also rate the mutual intelligibility of various dialects at around 80-90%, which is still really high, all things considered.
But none of that is the problem. I'm not a data analyst. I don't need a query Swiss army knife. I need a database that behaves predictably under concurrency at a level I can understand. I need primitive operations that map well to the persistence needs of an app serving multiple users at scale. I've never said SQL is incapable or even inadequate at these tasks but figuring out how to do them correctly ends up being a test of English skills rather than picking the right function to call and the right arguments to pass it.
SQL has its warts for sure, I personally long for the day we get a better declarative query lang than the stringly-typed thing we have now.
> An opcode with some arguments would be preferable to writing a poem and hoping it gets interpreted how I meant
Not sure I follow here though? Is it the declarative nature you don’t like? SQL can be a bit ugly sometimes, but I’ve never really had “no that’s not what I mean” moments?
This may be a gripe specific to Postgres but I find that the documentation can be obtuse. Yes, I'm sure it parses consistently, but what a given word or phrase does in a given context isn't always clear. I've had to write a lot more database tests to be sure I know what I'm doing than when I was calling specific operations with well defined arguments in NoSQL land. Maybe this issue is mostly in my head, but the semantics of various operations seem a lot fuzzier than I'm used to.
They will tell you what each component does further down the page though.
Mongo's documentation has a slicker and more ergonomic design though, no question. Mongo uses a "cheat sheet"/"tabular" approach, and Postgres uses a "printed reference book" approach, which is rather dated. Mongo is very good at surfacing the complexity and nitty gritty details immediately. It's all there in the Postgres docs, but you have to sit with them for longer and have more of an intuition about how they've organized it.
I've also found the Postgres.FM podcast to be a great resource. I've been working with Mongo recently and something that's bothered me is that I haven't found a comparable resource, where practitioners give you the straight dope about what stupid mistake you're going to make to bring down production and how to fix it. Substantially all of the learning material for Mongo is from Mongo the company, and is just not as candid.
And since it encourages "winging" it, the DBs tend to be poorly structured/documented. Which is OK for some applications I guess.