Awesome stuff, this resolves my #1 feature request of being able to replicate an entire directory of SQLite *.db's from a single Litestream process - happy it's finally here.
Should make replicating Multi tenant per-user SQLite databases a lot more appealing.
I still don't really understand the real "advantages" of such an architecture, over, say, a centralized Postgres server, which can process just as much data no?
The network round trips of queries to a database server add up, so much that they influence query design (though we don't much think about that anymore, because n-tier database designs are so prevalent that everyone writes queries that way). The advantage to SQLite is that queries are incredibly fast.
So it's often "presented" as "a local database which is replicated by streaming", but perhaps it would be more natural to view it as a kind of "centralized database, but with local caches that are kept near your server code, and sync'd"
I understand it's the same, but it makes the intent clearer: the intent is more to have a local cache to read/update (which is then sync'd), or at least it seems clearer to me presented that way :)
Comments
Awesome stuff, this resolves my #1 feature request of being able to replicate an entire directory of SQLite *.db's from a single Litestream process - happy it's finally here.
Should make replicating Multi tenant per-user SQLite databases a lot more appealing.
I still don't really understand the real "advantages" of such an architecture, over, say, a centralized Postgres server, which can process just as much data no?
The network round trips of queries to a database server add up, so much that they influence query design (though we don't much think about that anymore, because n-tier database designs are so prevalent that everyone writes queries that way). The advantage to SQLite is that queries are incredibly fast.
I see! Thanks.
So it's often "presented" as "a local database which is replicated by streaming", but perhaps it would be more natural to view it as a kind of "centralized database, but with local caches that are kept near your server code, and sync'd"
I understand it's the same, but it makes the intent clearer: the intent is more to have a local cache to read/update (which is then sync'd), or at least it seems clearer to me presented that way :)