3 ms·

A brain, a manual and google is usually a pretty good way generally to make solid decisions, respect the limits of your chosen stack. What happens when there i

A brain, a manual and google is usually a pretty good way generally to make solid decisions, respect the limits of your chosen stack. What happens when there is >1 brain involved... or when brainless, manualless decisions eventually get made... or two pivots from now... I'm not disagreeing with your approach. I agree with it, especially as starting point. I'm cautioning that resilience against complexity isn't about how easy it is to make good decisions when you understand the spec, read the manual and calmly proceed. Complexity and fragility accumulate when one or all of these are absent. How easily you can (and thus inevitably will) make a mess... not how easily you can keep it clean. IRL situations with regular rdbs, a very common trend seems to be long term drift between schema and spec. The flexibility and approachability of postgres often enables a lot of kludge eventually. Data stores have this dichotomy between "look how easy" and "is limiting factor" that speaks to difficulties we don't know how to articulate or isolate.

MichaelZuo 3y ago
Of course if there are lots of bozos in the startup then even getting to and maintaining 50 million rows is going to be very difficult. But if you have a small group of folks that are at least as competent as the folks at WhatsApp pre-acquistion, then there really shouldn't be any doubt whatsoever.
- dalbasal 3y ago
  > a small group of folks that are at least as competent as the folks at WhatsApp pre-acquistion That's a success case... beware survivorship bias. > if there are lots of bozos in the startup No arguing that quality engineers are fundamental to quality engineering. That said... by this standard, there's no point in having this entire discussion. Every good db/store out there is good. They all work very well if used as they should be, with due respect to tradeoffs. Yet, almost everyone has db problems. Almost every one of these problems occur well within the technical limits of postgres or whatnot. "It shouldn't be a problem" when it usually is irl is tunnel vision. There is an empirical reality disagreeing with you. Walking into it with "this shouldn't be a problem unless everyone is a moron" is bad strategy. If you can't think of reasons why architecture can and will become a problem, then just assume that you (or some of you, some of the time) are morons, and try to make it moron proof.
  - MichaelZuo 3y ago
    > That said... by this standard, there's no point in having this entire discussion. Yes, I agree just repeating tautologies is unlikely to be meaningful.

MichaelZuo 3y ago

Of course if there are lots of bozos in the startup then even getting to and maintaining 50 million rows is going to be very difficult. But if you have a small group of folks that are at least as competent as the folks at WhatsApp pre-acquistion, then there really shouldn't be any doubt whatsoever.

dalbasal 3y ago
> a small group of folks that are at least as competent as the folks at WhatsApp pre-acquistion That's a success case... beware survivorship bias. > if there are lots of bozos in the startup No arguing that quality engineers are fundamental to quality engineering. That said... by this standard, there's no point in having this entire discussion. Every good db/store out there is good. They all work very well if used as they should be, with due respect to tradeoffs. Yet, almost everyone has db problems. Almost every one of these problems occur well within the technical limits of postgres or whatnot. "It shouldn't be a problem" when it usually is irl is tunnel vision. There is an empirical reality disagreeing with you. Walking into it with "this shouldn't be a problem unless everyone is a moron" is bad strategy. If you can't think of reasons why architecture can and will become a problem, then just assume that you (or some of you, some of the time) are morons, and try to make it moron proof.
- MichaelZuo 3y ago
  > That said... by this standard, there's no point in having this entire discussion. Yes, I agree just repeating tautologies is unlikely to be meaningful.