On: How to use Postgres for everything

[RedShift1]

> You'll inevitably get database-as-the-API

I think that's actually the point of "postgres for everything"?

[whateveracct → RedShift1]

If you don't have any discipline it becomes hell.

Not to mention that a random team writing a migration that locks a key shared table (or otherwise chokes resources) now causes outages for everyone.

[blackenedgem → whateveracct]

Right but in this "100-engineer" scenario you'd have hoped the following would have happened:

- Docs and guidelines on migrations would have been written

- Some level of approval and review is required before execution

These are things that isn't really postgres specific, any company that doesn't have those is going to be a nightmare.

[robertlagrant → blackenedgem]

If teams have technical boundaries defined at a higher level in the stack (e.g. APIs) and so they don't share a database, you don't need loads of process and docs and architectural meetings to coordinate. Letting teams delivery independently is a good architectural feature.

[ForHackernews → robertlagrant]

This is why everyone adopted "microservices" - it's Conway's law in action, a technical intervention for an organizational problem.

[whateveracct → blackenedgem]

Even with those things, blast radius for mistakes is ..the entire company is down.

e.g. User management deploy has somehow taken down core payment processing.

[xnx → whateveracct]

Not a problem until it's a problem.

[com → xnx]

And the best thing is that until it’s a problem you can focus on product/market fit and delighting your customers.

Overengineering is a plague amongst SWEs, and almost as dangerous as failing to sell the product in the market.

[whateveracct → com]

I think cargo cutting stuff like "Postgres for everything" is also a plague. I agree you don't want to overengineer, but if you're a leader and your policy is basically "engineers can't ever be trusted to do hard things" then you're a bad leader.

Sorry if this comes off as brusque, but I've seen good engineers want to use Elasticache for the right reasons and seen "leaders" tell them no because "caching is one of the hard problems in computer science."

Leadership-by-folksy-saying is sadly a real thing.

[com → whateveracct]

I worked in a Postgres for everything business, and the IPO and later value creation for customers and investors (including me) had been stratospheric.

Not dealing with loads of technology choices in the early days is a boon.

Once we hit more than $100m in rev it made sense to allow a bit more optimisation for purpose - but only when we had cash flow to pay for it. Otherwise all these fancy-shmancy choices are just dressed-up tech debt.

[whateveracct → com]

> Once we hit more than $100m in rev

Yeah my original comment was about experiences working at places with this kind of monetary success (if not more) and stubbornly not evolving. Low trust eng leadership philosophies will do that though.

[pdimitar → xnx]

"Until it's a problem" is doing a lot of heavy lifting in your sentence. For 99% of projects that "until" will never come.

[xnx → pdimitar]

I agree completely. Far more startups are sunk by the cost of hypothetical technical problems than real product/market ones.