The first two linked resources:

  Simplify: move code into database functions
  Just Use Postgres for Everything

Are disqualifying enough to not warrant further reading.

A relational database is one form of persistent storage. They are great for managing persistent representations of key abstractions and their relationships.

They are not application frameworks nor scalable messaging systems by design.

▲ nine_k 3 hours ago | parent | next [-]

Did you see that implementation of Quake in CSS? Or Tetris in awk? You can do a similar thing with Postgres, and it will be much less insane. Should you run your entire app stack in Postgres? Likely not. Can you? Likely you can.

	▲	AdieuToLogic 3 hours ago \| parent [-]
		> Did you see that implementation of Quake in CSS? Or Tetris in awk? Do you want to support either of those in production? Get support calls and/or enhancement requests for same? > Should you run your entire app stack in Postgres? Likely not. Can you? Likely you can. I have experience with non-trivial systems which have put business logic in database stored procedures. They were not pretty. One example was a single stored proc having north of 40 parameters and was central to a high-volume transaction workflow. That is how I learned at the time Oracle had a max of 4 threads available to stored procs and that SGA usage can reach out and bite you in "fun and interesting" ways.

▲ LPisGood 4 hours ago | parent | prev [-]

Not everything needs to “scale.” I think needing scale is relatively rare, actually.

	▲	AdieuToLogic 3 hours ago \| parent [-]
		> Not everything needs to “scale.” I think needing scale is relatively rare, actually. The ability to scale a system is not limited to throughput metrics. If it where, I would agree with your point. Scaling in complexity and/or ability to feasibly introduce significant change is also a desirable system attribute and the one which I predominantly had in mind. The likelihood of also being to scale from a throughput perspective is a nice bonus.