[RcouF1uZ4gsC]

https://litestream.io/ does streaming replication to S3 (or similar service). With this, you probably have better data durability than a small database cluster.

[adamkf]

My understanding is that it provides asynchronous replication, so you'd still lose some data if you lose a machine. This is documented here https://litestream.io/tips/#data-loss-window

[itake]

even with litestream, how do you do deployments? do you just terminate the process and re-launch it on the same machine?

[killingtime74]

I guess this is an interview level question. 1) Drain connections from your instance. Stop taking new connections and let all existing requests timeout. This could be by removing it from a load-balancer or dns. This ensures your litestream backup is "up-to-date". 2) Bring up the new deployment, it restores by litestream. When restore is complete, register it with the load balancer (if you are using one) or dns. 3) Delete the old instance.

Instance can be process, container or machine.

[itake]

Yes... and all I see here is downtime. How do we do this without services failure? With a postgres db, you can spin up and down ec2 instances to your hearts content. Every 1-4 years, you can upgrade your db by using a replica with no down time.

[sroussey]

Depends on what you are doing. But a hobby project should definitely just do downtime, lol.

If your db does lots of work, I buy new ones, install them in the datacenter, bring them up from backup.

BTW: you skipped a step for a busy database: warming it up with shadow traffic.

Under certain scale just switching like you describe will cause just as much downtime.

[sanderjd]

Yeah if I were a user of this application I would consider this a very poor solution...

[guluarte]

litestream is more for data recovery, for replication LiteFS is better.

[colobas]

Came here to say this