4 ms·
This all sounds good until you consider high-availability, which IMO is absolutely essential for any serious business. How do you handle fail-overs when that ch
by 14u2c 4y ago
This all sounds good until you consider high-availability, which IMO is absolutely essential for any serious business. How do you handle fail-overs when that cheap VM goes down? How do you handle regional replication?
You could cobble something together with rsync, etc, but then you have added a bunch of complexity and built a custom and unproven system. Another option is to use one of the SQLLite extensions popping recently like Dqlite, but again, this approach is relatively unproven for basing your entire business on.
Or you could simply use an off the shelf DBMS like Postgres or even MySQL. They already solve all of these problems and are as battle-tested as can be.
- Skinney 4y ago> high-availability, which IMO is absolutely essential for any serious business Depends very much on the business. You can have downtime-free deploys on a single node, and as long as you've setup a system to automatically replace a faulty node with a new one (which typically takes < 10min) then a lot of businesses can live with that just fine. It's not like that cheap VM goes down every day, but just in case you can usually schedule a new instance every week or so to reduce the chance of that happening. > How do you handle regional replication? For backup purposes, you'd use litestream. Very easy to use with something like systemd or as a docker sidecar. For performance purposes, if you do need that performance you'd obviously use something else. Depending on the type of service you have, though, you can get very far with a CDN in front of your server. > Or you could simply use an off the shelf DBMS like Postgres or even MySQL. If you need it, sure.