[roenxi]

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. Everyone seems to be trying to develop systems that mean they don't have to write SQL code.

Add all that up and NoSQL should be fine. But then the actual NoSQL databases let people throw out all the concepts that make SQL so sticky. Schemaless databases are in the same class as goto statements - there are people I trust to use them to do amazing things. The projects I inherit to maintain are never written by those people. Transactions and consistency guarantees are necessary to get a group of programmers together writing a reliable application. The relational model is the best idea to come out of database research.

I wish NoSQL was a postgres extension. Instead we get MongoDB advocates. Bless them, but PostgreNoSQL would be so much better for all the use cases I have than MongoBD.

[masklinn]

> It may be impossible to create a less pleasant language than SQL.

It’s not by the way, there’s an entire segment of the esolang space for which it’s the goal (starting with the canonical example that is INTERCAL).

But ignoring esolangs, there are lots of very unpleasant programming languages out there. M/MUMPS is a well known one (especially with “legacy” coding styles, or so I gather). I also consider XSLT to be abhorrent, especially given the nice underlying conceptual idea (not entirely dissimilar to SQL really, just worse).

About SQL, an idea I saw surface recently in a related discussion was how nice it’d be if databases could expose the data model interaction and allow building on that directly: most every SQL database compiles the query into some sort of bytecode (combining direct translation and planner information) to actually run it on its storage layer, some databases allow peeking at the bytecode (sqlite actually prints the bytecode as part of its EXPLAIN output) but I don’t know that any allows bytecode input.

TBF the bytecode is very much considered an internal detail, it can change a lot between versions and (most importantly) tends to be more or less completely unchecked, it relies on the compiler generating it being correct (not unlike cpython for instance).

[BeFlatXIII]

MUMPS always reminds me of Perl code golfing.

[emodendroket]

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 with JSON columns.

[roenxi]

> 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.

[zztop44]

JSON columns are very useful in some circumstances but you shouldn’t use them as a replacement for a database schema, and if I’m honest I’m yet to see anyone truly suggest that.

[sudhirj]

I use schema for everything relational, and put everything else (all the nice-to-know data) in JSONB. Works really well. Stacks like Rails lean into this with `store_accessor` which lets you designate a JSON column as storage for arbitrary data that looks and feels like a separate column.

[emodendroket]

I guess it depends what part of NoSQL you’re looking for, but if you want a bit of schemaless data it makes sense.

[jdiff]

How about EdgeDB? Never used it, but I found it when looking for a similar thing to you after reading this article. It's built on top of PostreSQL, uses it as a storage engine and provides a NoSQL interface to it. It calls itself a "graph-relational database."

[Sankozi]

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.

[strbean]

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!"

[fifilura]

Your argument seems a bit childish to me. Like you never really cared to learn the tool.

SQL is relational algebra. Sure you can write it some other way. Lots of projects tried, none succeeded. Wonder why is that?

End of the day - if you just learn the syntax, the hard part will be in the logic. As it should be.

[strbean]

I can't tell if you are being sarcastic or not.

In case you aren't: I didn't state my argument at all. Unless you dug through my comment history to find my complaints. This is precisely the kind of nonsense you get in response to even stating that you dislike the language.

> SQL is relational algebra. Sure you can write it some other way.

The same applies to general purpose programming languages, yet they have improved immensely since COBOL.

> Lots of projects tried, none succeeded. Wonder why is that?

Because of inertia, the mixed userbase of SQL, and ORMs and things like LINQ. The fact that most projects avoid direct use of SQL when possible is telling enough on its own.

[wvenable]

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.

[strbean]

It originally was the name for a non-SQL RDBMS: https://en.wikipedia.org/wiki/Strozzi_NoSQL

It malappropriated in 2009.

[labster]

This explains a lot about the GNU project.

[ttfkam]

The note about composability annoys me. Does it have composability akin to functional programming languages? No. But SQL isn't a functional programming language. Never has been. It's the world's most popular 4th generation language. (Most popular high level languages are 3rd gen in case a reader was wondering.)

With the lens that SQL is a DSL for set theory and set transformation (which it is), composability takes the form of views, temp tables, and CTEs. Not what you're looking for? That's fine. But they 100% make SQL composable.

I take issue with saying it's inconsistent as well. Are there warts? Sure! Like any language. But fundamentally inconsistent from the lens of DSL for set theory and transformation? No.

Folks keep trying to make relational system access like their favorite programming language, and it's not going to happen. Are folks' favorite general purpose programming languages 4th gen languages with an emphasis on set theory and transformation? No? Then stop trying to shoe horn it on! It only leads to frustration. Embrace the set theory and 90% of SQL's issues don't register as issues anymore.

As for NoSQL like MongoDB as a Postgres extension, that's what jsonb and its related operators and functions are for. Seriously. to_jsonb(…) and jsonb_populate_recordset(…) are seriously under-appreciated. They're like rocket fuel for JSON processing. Of course you're also welcome to keep a jsonb column lying around to keep things "schemaless", but experience has shown that defining your data (with types) rather than allowing free-form blobs in your database is better in the long term. You obviously see this already by your trust statement with regard to coworkers. "Better" meaning more performant and easier to maintain.

Just like thinking "functionally" takes training and practice to grok when you've been object-oriented all your life, that "set theory" takes training and practice as well. And it's so worth it. Feels like a goddamn superpower sometimes.

[brightball]

You can always use JSONB columns to get the Postgres experience.

[anotherhue]

PRQL: a simple, powerful, pipelined SQL replacement

https://news.ycombinator.com/item?id=34181319

Also: https://github.com/ajnsit/languages-that-compile-to-sql

[ttfkam]

On the one hand, FROM first makes conceptual sense. On the other, it doesn't offer anything significantly better than SQL. Is it marginally more terse? Yes. Is terseness paramount in a database manipulation and transformation language? I'm not convinced.

[threeseed]

> 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.

[winrid]

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.

[kaoD]

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

[moehm]

Master-master replication probably, think Galera.