[elwinar]

It works well until you've got an issue, and then you're completely fucked.

I think the sense of the comment was "how can I deploy or test anything once it goes in production". You know, were starting again from scratch is not an option ever.

Using the database as a service layer is dumb for non-trivial scenarios were you need garantees that your service keeps running, or when you want to test new code with the production data.

It's interesting, and probably useful to have a set of functions with the database, but there is real problems once your database stops being a dumb store.

[chaps]

How would you be completely fucked when the rollback is to just rerun the workflow? Worst case scenario here is downtime, which is a far stretch from "completely fucked". It very much sounds like the databases that you work with and the databases that the article writer works with are used for two very, very different purposes. The author made no mentions about SLO-type requirements, so I think it's fair to say that SLO isn't a huge priority. But that can be mitigated, like I said, with a hot/warm/cold standby.

Do you think it's a bad idea to use something like PostGIS because it uses functions that live on the database?

[qaq]

"when you want to test new code with the production data". Take a snapshot and start a new instance from that snapshot.