3 ms·
The problem (very reliable storage of large amounts of data) is really hard too.
by spion 3y ago
The problem (very reliable storage of large amounts of data) is really hard too.
- api 3y agoSo are compilers, virtual networks, and encryption, but I have tools for all those that don’t inspire the kind of nameless terror that databases do. The failure modes are different but the problems are not really easier intellectually speaking. There are databases like CockroachDB that are more modern and a lot more approachable for high availability but for some reason everyone adores Postgres. I’m not sure why. It’s arcane and clunky and feels like 1980s Unix software.
- spion 3y agoThat's because they're not really that hard. Compilers are essentially pure functions, encryption is as well. State is another beast entirely. If I had to put on my innovator cap and do a relatively weakly informed guess, I'd say its because querying capabilities and reliable storage are still too conflated. If we focused on reliable storage that only has great replication support to other querying systems, the problem might get easier.
- smilliken 3y agoPostgreSQL is the very best of the clunky 80s unix software. Its features and reliability are unmatched. The core contributors have earned the trust of the community. You lose a lot of features and performance when you go from a single server database to a distributed system. Distributed systems are significantly more complex to set up, administer, and debug. For nearly all databases in use, the tradeoff isn't worth it. It's really no wonder that postgresql is as popular as it is.