Live data from Hacker News

NoSQL: The Baby and the Bathwater

brooker.co.za

11–20 of 59 posts

Re: NoSQL: The Baby and the Bathwater

#11
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

> Bless them, but PostgreNoSQL would be so much better for all the use cases I have than MongoBD And for some of us MongoDB is a better option than PostgreSQL. Many of us simply can't rely on scalability and high availability being something that isn't part of the core product.

The built in horizontal scaling of Mongo is nice, but I would still put PG's reliability per-instance higher than Mongo's.

The reason being that Mongo is written in C++ with lots of RAII and will simply die on a memory allocation failure. Postgres won't. It'll keep running in many low memory scenarios and the operation will error out.

Re: NoSQL: The Baby and the Bathwater

#12

Sure SQL DBs can have all the advantages of NoSQL DBs and then some... but they will never have a lower price tag. And that's because NoSQL DBs use very, very little CPU. All that's needed is giving up reliance on SQL. Design your NoSQL "schema" with this in mind, and you're golden

Very little CPU depending on sorting, indexes, etc...

Have a lot of indexes on a collection? Mongo will eat 5-10ms of CPU time per query even with cached query plan stats just to start executing the query. So no different than PG here.

What you're getting at is Joins, but I haven't seen a company that didn't end up doing joins with Mongo at some point. Or, they do it in the app layer, in Java/Node/PHP which requires more CPU than it would in the DB.

Also, wanna store an array in a document in Mongo? Every time you add to that array, the whole array is replicated to your secondaries. That eats a lot of CPU.

Re: NoSQL: The Baby and the Bathwater

#13

Structure is important, that's where NoSQL fails from the get go. We should stop investing so much time into NoSQL and look more into combining SQL and Graphs

You can use NoSQL with a schema and have strict enforcement. What the NoSQL db does is make storing objects easy with less boilerplate or abstraction.

Re: NoSQL: The Baby and the Bathwater

#14

Structure is important, that's where NoSQL fails from the get go. We should stop investing so much time into NoSQL and look more into combining SQL and Graphs

You may be interested in https://www.gqlstandards.org/ and https://www.iso.org/standard/79473.html

TL;DR the ISO standards committees behind SQL are working on bring graph query languages and SQL databases closer together.

Obviously there is work to be done at the storage/query planning layer after that, but I’m hopeful once the surface exists more widely that will drive more work in those areas.

Re: NoSQL: The Baby and the Bathwater

#15
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

I think the right way to think about NoSQL databases is you have an application where traffic is expected to be heavy enough that it's worth throwing out what SQL gives you for free and having a highly optimized solution where you deal with those problems yourself. Of course, it was a big enough trend that many people jumped on it without having a practical use for it. Arguably psql does offer a NoSQL-like experience…

> Arguably psql does offer a NoSQL-like experience with JSON columns.

I hope not. JSON columns purge all the good things a relational database offers and keeps the SQL. It is the worst of every option.

That really should be the opposite of the NoSQL experience. Disbarred by the fact that SQL is involved.

Re: NoSQL: The Baby and the Bathwater

#16
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

> Bless them, but PostgreNoSQL would be so much better for all the use cases I have than MongoBD And for some of us MongoDB is a better option than PostgreSQL. Many of us simply can't rely on scalability and high availability being something that isn't part of the core product.

In what way is scalability and high availability not part of Postgres' core?

Re: NoSQL: The Baby and the Bathwater

#17
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

I agree completely.

When I first heard about NoSQL I thought some databases were finally introducing some replacement for abominable SQL. But no, they were just creating schemaless databases.

Re: NoSQL: The Baby and the Bathwater

#18
I'm surprised to see so many opinions on what is "objectively" the best database paradigm. My incredibly boring take: databases are such a generic tool that it really depends on your use case, there are times when noSQL is stand out the best choice, and lots more when it isn't- the real pain point comes from people blindly cargo culting into a db paradigm without considering their use case.

Re: NoSQL: The Baby and the Bathwater

#19
post #8
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

NoSQL really means NoRDMS. The SQL language, or lack there of, has little to do with it. The unfortunate naming leads to this kind of confusion. Probably a technology should never be named for what it is not.

This explains a lot about the GNU project.

Re: NoSQL: The Baby and the Bathwater

#20
post #17
post #5

I don't like NoSQL databases. "NoSQL" should be manna from heaven. It may be impossible to create a less pleasant language than SQL. It isn't composable, it isn't internally consistent, it isn't easy to parse, it claims to be declarative but the ordering of the clauses is completely rigid, it fights every attempt at writing testable or maintainable code. It is hard to read. It is hard to programatically generate. Eve…

I agree completely. When I first heard about NoSQL I thought some databases were finally introducing some replacement for abominable SQL. But no, they were just creating schemaless databases.

I'm so glad this sentiment is being spread more. So tired of explaining that when I complain about SQL I *emphatically do not mean relational databases in general*, only to have everyone counter with "but relational stuff is good!"
Post reply on HN