4 ms·

> You'll inevitably get database-as-the-API I think that's actually the point of "postgres for everything"?

whateveracct 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      This is why everyone adopted "microservices" - it's Conway's law in action, a technical intervention for an organizational problem.
  - whateveracct 2y ago
    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 2y ago
  Not a problem until it's a problem.
  - com 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        > 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 2y ago

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 2y ago
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 2y ago
  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 2y ago
    This is why everyone adopted "microservices" - it's Conway's law in action, a technical intervention for an organizational problem.
- whateveracct 2y ago
  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 2y ago
Not a problem until it's a problem.
- com 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        > 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 2y ago