Hacker News Reader

Comment by furstenheim | Hacker News Reader

This is kind of what happens with Postgres. Postgres in itself is great and simple to use. However, managing replication, maintenance, sharding... Is often quoted as very complex in the conference themselves. And that's precisely what most of the companies around Postgres live on

View on HN

There's plenty effort improving those aspects. Including by employees in companies making money on PG support. But there's plenty hard problems - there are in other areas too, but work on those often started much earlier. These days the result of complexity around replication leads users to RDS et al, which reduces income for the various PG companies, it doesn't increase it.

Which alternatively will you suggest. I know it all depends on the case, but for a fairly simple use case, what would you suggest?

Are MySQL and SQLite still the most reliable ones around?

This is why I dislike commentary like the one you are responding to.

Replace "postresql" with literally any tool and the sentence holds true: redis, mysql, mongodb, cassandra, mssql, HDFS, Kubernetes, React, Vue...

The fact that cottage industries pop up around powerful tooling is not a bad thing. Some things are just complicated, and there shouldn't be such an aversion to those things.

The thing is that SQL was originally built to be an easy accessible DSL for simple database queries, and was not intended to be used to build highly complex stuff. Datalog-like query languages would do the latter much better since they are actually capable of letting you write reusable predicates and libraries for common usecases, while SQL easily grows into a monolithic monster.

Sadly a lot of the "NoSQL" hype later on was led by people who had no clue about database theory, and proceeded to throw the baby out with the bathwater and build whatever abomination MongoDB is, rather than taking SQL's theoretical basis and building a language on top of it that is actually designed for complex usecases. There were only a few exceptions like say Datomic in Clojure world that did NoSQL right.

This is unrelated to SQL. We are using SQL as examples - but it is not important to the argument.

IBM did not spend the money it did to replace its premier database product, IMS, with another DBMS, DB2, just to enable "simple database queries". Yes, SQL was influenced by other "4th generation languages" of the era. But IBM judged -- correctly, on the evidence -- that most programmers would not take the time to master first order predicate logic or set theory.

So they came up with something that implemented the Relational Model in a simple way, one that would attract new converts. SQL has plenty of warts and defects, but its success at extinguishing every other database query language can't be denied.

Datalog isn't especially difficult to learn though, and is intuitive enough that you can fully learn it in 20 minutes.

The relational model with unions of conjunctive queries at its core is excellent. SQL on the other hand feels like some weird COBOL dialect that gives you an incredibly verbose implementation of it.

With that said, there are a few enterprisey NoSQL databases which are relational yet provide a nicer language to work with than SQL. I mentioned datomic (which also has persistence as its key feature), but there's also TypeDB which lets you use the first class support for recursive queries to support inheritance more easily. And of course there's google's Logica language which compiles to SQL and lets you use datalog syntax and the ability to write reusable queries, though it doesn't support recursion due to the nature of its target.

Here are SQLite's suggested use cases:

https://www.sqlite.org/whentouse.html

Reply on news.ycombinator.com