There was an article from over a decade ago that, for many developers, "NoSQL" was really about "No DBA": <a href="https://martinfowler.com/bliki/NoDBA.html" rel="nofollow">https://martinfowler.com/bliki/NoDBA.html</a>.<p>That is, in many companies, DB schema changes require a painful, slow, "multiple approvals required" process. But devs found out that DB admins didn't really care about NoSQL data stores for all the reason Martin Fowler talks about in that article. So they'd bring in NoSQL data stores specifically to hack around slow internal processes.<p>I <i>definitely</i> found that to be the case at at least 1 previous company I worked at. These days, I can certainly understand the rationale to use a transient caching layer like Redis, but Postgres with JSON columns is going to be a better choice 95% of the time vs. what people used to use, say, MongoDB for.
Some important context..<p>> A long-time IBMer, Chamberlin is now semi-retired, but finds time to fulfill a role as a technical advisor for NoSQL company Couchbase.
While the startup I worked at, a few years back, was decidedly dabbling in the NoSQL space, using Elasticsearch, OrientDB, and Neo4j, the rockstar dba that we hired to help our crowd of mostly Java folks, was very convincing that everything those newlings could do, SQL could do perfectly well too. There are many optimizations that those Java devs couldn't dream of, and then there are recursive SQL queries, or JSON columns, to address specific features that NoSQL or graph database are supposed to be good at. I think there's a place for both, but it certainly has made me more critical about blunt assertions that SQL's time is over. Meanwhile, investors have stopped asking for NoSQL (and for blockchains, too) and NoSQL databases probably are less of a "resume builder" anymore either. So, we can go back to using the best database for the job? (In most of my cases... PostgreSQL.)
> Donald Chamberlin, who first proposed the language with IBM colleague Raymond Boyce in a 1974 paper [PDF], explains that NoSQL databases and their query languages could help perform the tasks relational systems were never designed for.<p>So the news is that a database expert, in the employ of a noSQL database company, is saying not to use SQL databases for the things they aren't made for?
I still don't understand the advantage of NoSQL over just defining a JSON column and additionally defining columns for the fields you want to query. Postgres lets you do queries over json documents too iirc.
This feels like a submarine article for Couchbase.<p><a href="https://paulgraham.com/submarine.html" rel="nofollow">https://paulgraham.com/submarine.html</a>
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.<p>And since it encourages "winging" it, the DBs tend to be poorly structured/documented. Which is OK for some applications I guess.
This technical arguments in this article aren't that coherent in my view. I'm not sure if this is the reporter's fault or some Couchbase marketing film-flam (err, which would still end up being the reporter's fault.) It could be me I suppose; judge for yourself:<p>The first half suggests Chamberlain ("SQL co-creator") supports NoSQL which avoids the relational model and in many cases is oriented around more of a key-value store with eventual consistency for better handling certain scalability use cases. Slightly eyebrow-raising that the SQL co-creator agrees, but I don't think there's a huge technical dispute that you can scale better if you allow eventual consistency. Whether it's wise is debatable but of course there will always be a use case where it is arguably wise.<p>The second half talks about SQL++ (which Chamberlain apparently worked on) which AWS calls PartiQL whose value proposition is better/easier parsing of JSON.<p>I am not clear how relaxing ACID properties to scale is related to JSON other than that a bunch of early NoSQL databases (MongoDB? Couchbase?) tried to do both.<p>I am no PartiQL/SQL++ expert but I have used PartiQL and it is pretty much SELECT... FROM... etc SQL with some fancy features for JSON handling. With standard transactional semantics. You can do similar JSON-type handling in Postgres and Snowflake and other tooling from what I can tell, although I'd be a bit surprised if some of the SQL++/PartiQL dot notation and array subscripting for working with JSON data is ANSI SQL standardized. I don't keep up with this but SQL:2016 JSON support can be seen a bit in places like: <a href="https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#json" rel="nofollow">https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016#js...</a> and SQL:2023 JSON support (esp T801 through T882... oh, it looks like the "simplified JSON accessor" that I liked from PartiQL seems to be there) is a bit covered at: <a href="http://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-finished-here-is-whats-new" rel="nofollow">http://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-fini...</a> )
nosql is great. What’s not great are people who think it’s the best at everything all the time. Same with SQL for that matter.<p>Turing complete isn’t the proper phrase, but I assert any data model can be modeled performantly both ways (normalized or not).
Yeah I agree on not being overly opinionated on this. SQL, NoSQL, for most applications as long as the data is stored somewhere reliably it doesn't matter.<p>Although, he's kind of losing me on this SQL/C++ hybrid, not sure I can get behind that one.