[Micoloth]

Honest question.. Why?

I’m always thinking that a db that can also run business logic would be the ultimate backend solution for crud apps.

I know there are several options to do it, but I always assumed Postgres did not support it.

What do people have against it?

[JohnBooty]

After several decades in the business, I have learned not to underestimate the massive power of trendiness.

A lot of the argument against it is: SQL is stodgy and uncool, and I want to use Cool Language XYZ. And honestly, I don't entirely blame people for that. If you want to work in this industry you need to do things the "cool" way or you'll never even be considered for roles. Gotta keep that resume looking good.

People also don't appreciate how performant it can be. Depending on what you're doing it can be orders of magnitude more performant to do things in-database versus shuffling things back and forth. (It can also be less performant...)

There are definitely cons to that approach.

One is scalability. It's easier to scale your app layer horizontally than it is to scale your database server vertically. This isn't necessarily an issue: a modern beefy server CPU with 64-128 cores and a TB or two of RAM is more than 99.9% of companies need, is really not that expensive, and is probably a lot cheaper than more complicated setups and extra devops headcount. But that's not cool either.

Two is the language/skills mismatch. You've got an app layer in one language, a frontend in another, and now potentially a data storage layer written in a third. This is a valid concern, but also nobody seems to use it as an argument against Javascript frontends, so apparently sometimes it's cool and sometimes it isn't.

Debugging stored procedures sort of sucks. That's fair. (But also, nobody is saying to rewrite your entire app, or even most of it, in the DB layer)

Common migration tools often don't really have explicit support for stored procs and things like that, but AFAIK they do let you run arbitrary SQL DDL stuff, so I don't think this is a hard barrier.

[simonw]

I think the main thing is that most people still aren't working with a good migrations system to manage changes to their schema... which means logic held in database triggers and stored procedures quickly becomes a non-version-controlled not-properly-tested mess.

Good migration systems exist, and people should use them!

I held off on doing interesting things with triggers for more than a decade. In the past year I've started leaning into them much more heavily (actually using them in SQLite) because I have confidence that I can both write good tests for them and have good migrations automation in place for version-controlling my schema.

[marcosdumay]

Postgres has plugins for running the entire backend.

People don't like it for a lot of reasons. Making privilege escalation harder is a big one, but also, all the CPU (and memory) load on serializing that data is CPU that could be used managing the distributed processes problems that only the DBMS can solve.

Personally, I think access management on those tools needs to improve a lot before they get usable. But also, the data-oriented languages have some issues, and the non data-oriented ones don't gain much by running inside the database.

IMO, we are missing a really good data-oriented language. But I don't see any gain from running it inside the database.

[candiddevmike]

Few reasons:

- Enforce application logic with constraints so you don't have to duplicate it

- Use triggers and get access to things like old and new without having to create a bunch of transactions

- If you have multiple apps sharing a DB, you either keep your business logic consistent across them vs just doing it in the database

- You can version your business logic with your schema

[xboxnolifes]

The tooling around maintaining logic-in-db is worse than the tooling for logic-out-of-db.

[__jem]

Friction with modern devops practices is a big one.