One reason I use SQLite in production is because of Litestream. I can setup 2 or more VPSes hosting my Django app backed by the same SQLite database behind a load balancer for redundancy.

Thanks to Litestream, it's easier to scale horizontally when using SQLite than with other databases when self-hosting.

▲

nop_slide 4 days ago | parent [-]

I thought litestream was just for streaming backups? How does it enable you to coordinate with multiple instances of an application? Is one instance the "primary" where writes all go and either can serve as a reader?

▲

brokegrammer 4 days ago | parent | next [-]

This is a quirk that could cause data loss in rare scenarios but basically, in most cases, you'll have a single instance of your application because your load balancer will only send traffic to the other instances if the main instance isn't responding. But the load balancer will have to be setup to send traffic to a single instance at a time, and only try other nodes if the current node isn't responding.

The other instances are mostly redundant. That's how sites like Hacker News tend to operate, and why I chose this architecture. It's simple and stupid but doesn't work in scenarios where you have multiple servers in different locations for example. There's LiteFS to solve this problem but I don't have experience with it yet.

	▲	nop_slide 3 days ago \| parent [-]
		Ah got it, thanks for explaining and clarifying! Cheers

▲

porker 4 days ago | parent | prev [-]

I'm interested in knowing more about this too as I like the database localised with my app server (no network RTT!) but I also like to have a standby for HA and not being paged with everything down.

How litestream handles master-master or promoting a slave and switching back later isn't clear to me.

	▲	nop_slide 4 days ago \| parent [-]
		The closest thing I could find on the parent commenters blog was this https://joshkaramuth.com/blog/django-deployment/ But it doesn't go over multi-instance coordination