4 ms·

If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea. The biggest problem with depending on Postgres

If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea. The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing. Both of these waste valuable time on something that isn't providing any business value. They also are entirely preventable/avoidable, by simply not putting all your eggs into one basket. Basically the whole "just use Postgres" philosophy boils down to: I don't want to learn new things, and I just like making things from scratch with custom code. That's great if you're an engineer and you want job security. But it's bad strategy, engineering, and use of time and resources. Anyone who approves of using Postgres in this way should not be in charge of engineering decisions.

cpursley 3y ago
> I don't want to learn new things I've learned a bunch of new things (running all the things - not fun, putting biz logic in the application layer - slow). Putting them in the database is simply simpler and more performant. And it requires less code and time to develop (and maintain).
int_19h 3y ago
Given how things look in, say, the Node.js ecosystem, a large complex monolith has its attractions - chiefly that it doesn't fall apart at you, because it wasn't cobbled together with duck tape. It also has the benefit that it's a stable solution that has been around for decades, and will likely be around for just as long. Meaning that you won't have to constantly rewrite and update things to keep up with whatever the developers of your favorite framework decided is the Right Way to do things this year.

cpursley 3y ago

> I don't want to learn new things I've learned a bunch of new things (running all the things - not fun, putting biz logic in the application layer - slow). Putting them in the database is simply simpler and more performant. And it requires less code and time to develop (and maintain).

int_19h 3y ago

Given how things look in, say, the Node.js ecosystem, a large complex monolith has its attractions - chiefly that it doesn't fall apart at you, because it wasn't cobbled together with duck tape. It also has the benefit that it's a stable solution that has been around for decades, and will likely be around for just as long. Meaning that you won't have to constantly rewrite and update things to keep up with whatever the developers of your favorite framework decided is the Right Way to do things this year.