[lelanthran]

> Most of the edge cases can be handled using stored procedures on the database,

This is what actually turned my off about it when I used it for a small hobby project: the tooling around programming in SQL is absolute crap.

Expressing business logic in stored procedures is great in theory, but in practice only the very simplest business logic will be written as stored procedures, because anything non-trivial is impossible to debug, impossible to log properly and there is never a call-stack available when the inevitable runtime error/exception occurs.

If the tooling for writing, debugging, deploying and testing stored procedures were up to the level of what Turbo Pascal was in the 80s, I'd do it in a heartbeat.

As things stand, the only way to figure out bugs in the system is to visually inspect the stored procedure source code.

[xupybd]

I've seen a very complex payroll written in stored procedures. You're right about debugging, it's horrible. Once you get good at it there is an elegance to the solution but refactoring sux. Then there is performance tuning. You can get things so fast because you don't have to fetch from the db, you're already at the data source. You can also get things so slow as your loaded up on complex queries.

[CuriouslyC]

The tooling support definitely needs to improve. Postgres has support for emitting notices in stored procedures, but the lack of debugging is big a minus.

If you write code in PLV8 you can mock Postgres specific global variables to debug code using Node, and testing is pretty smooth with PGTAP. The deployment story is still something every shop has to reinvent at this point though.