Databases have failed the web

Note that in PostgreSQL, user defined functions can be written in many languages, including SQL but also Python (very well supported) and PHP (not so well supported, but doable).

It's easy sit in an armchair and point out all the warts on specific tech, but if you were to build a better solution to broad technology segments like this, and magically get adoption, you'd find that you only understood 5% of the application space, and your better version is subject to whole swaths of criticism that you didn't anticipate. Better to find one small/simple thing you can do well and build from there.

A lot of people here (and elsewhere) think is non-sense to build a full app with the full business logic inside the "db".

WHY?????

That is a VERY NARROW viewpoint.

But when we say "let's build a full-app inside a Virtual Machine, yeah that actually is ok!"

And why is ok to build a full app on lisp? Or in a OO language (a grah of objects)? Or a array language (a array is relation with 1 column!)

If you think that:

print([1, 2, 3])

Id OK. then YOU MUST ACCEPT THAT:

print([Code = 1, 2, 3; Name= Miami, New York, Bogota])

Is ALSO OK.

The relational model is just move from 1-columns arrays to 2 N-Columns (In rows of columns as internal storage) plus some universal operations.

WHERE THE RDBMS FAILED EVERYONE IS:

Because them (the guys at the DB side) insist in adding: transactions, triggers, Surrogate-Keys, Inter-Relation dependencies, storage, sub-query languages, catalogs, views, etc.

So at the end, you get a full half/big semi-OS virtual machine tailored to a specific niche.

------

Was only when the artificial divide between the RDBMS and the front-end language appear (and the death by MS of Fox/Vb to only focus in .NET) that building database apps start to suck big time.

I have talk about in HN before about this, and instead consider that make even MORE sense to build the logic inside the DB, however, is necessary to re-think how it look to make it more useful. Is not a novel concept. The dBase family was almost that, and the people like me that use it was very happy and productive.

Why make more sense? Because Program = Data + Algo.

Data is not to be treated as third-class citizen. Must be a first class. The relational model make it first class (as with lisp model and array).

And what about separation of concerns and all that? That is pure architecture and is tangential to be or not inside a DB, the same is tangential inside a VM.

I think CRUD apps are the most boring example. But think about something like Slack. There's some data and queries, sure - but the app also needs realtime feeds. It needs to have triggers running notification tasks off changes made. There's lots of stuff that need to happen as a result of data changes.

Doing all that stuff purely at the application layer is an architectural mess. What you really want is an event log of messages, with workers and search indexes listening on that. Maybe later you'll want to add full text search via elasticsearch - and that needs to be kept in sync via the event log as well.

Rolling your own version of all this stuff correctly is really hard. Either you do it inside postgres using triggers and stored procs, or you use kafka and invent your own complicated system to handle conflicting writes. Or you add hooks in all the places in your app where you do writes, but that introduces its own set of consistency problems. Samza, Datomic, Bottled Water, Couchdb and firebase all solve at least some of this stuff better than classic SQL stores. Its time for relational dbs to get on board.

Being no more than a database isn't good enough anymore.