3 ms·
Wow Litestream sounds really interesting to me. I was just starting on an architecture, that was either stupid or genius, of using many SQLite databases on the
by paulhodge 4y ago
Wow Litestream sounds really interesting to me. I was just starting on an architecture, that was either stupid or genius, of using many SQLite databases on the server. Each user's account gets their own SQLite file. So the service's horizontal scaling is good (similar to the horizontal scaling of a document DB), and it naturally mitigates data leaks/injections. Also opens up a few neat tricks like the ability to do blue/green rollouts for schema changes. Anyway Litestream seems pretty ideal for that, will be checking it out!
- mwcampbell 4y agoAn architecture like yours has certainly been done before, though AFAIK it never went mainstream. In particular, check out this post from Glyph Lefkowitz of Twisted Python fame, particularly the section about the (apparently dead) Mantissa application server: https://glyph.twistedmatrix.com/2008/06/this-word-scaling.html https://glyph.twistedmatrix.com/2008/06/this-word-scaling.ht...
- hantusk 4y agoSame pattern is ActorDB: https://github.com/biokoda/actordb https://github.com/biokoda/actordb
- deleted 4y ago[deleted]
- Scarbutt 4y agoEach user's account gets their own SQLite file. So now you need one database connection per user...
- tptacek 4y agoAnd? It's SQLite; it's a file handle and some cache, not a connection pool.
- mwcampbell 4y agoDepending on how you define "account", that can be quite reasonable. In a B2B application, each business customer could get their own SQLite database, and the number of SQLite connections would likely be quite manageable, even though some customers have many users.
- robertlagrant 4y agoIf by connection you mean in-process database.
- freedomben 4y agoWithout knowing details about the app, it's hard to know if that would matter. If a small number of concurrent users would ever be using it, I would think it would be NBD.
- freedomben 4y agoI actually did something very similar to this for an app that produced a lot of data. I wrote a small middleware that automatically figured out which shard to use so the app logic could pretend that it was all just one big db. The app ultimately ended up in the can so it never needed to scale, but I always wonder how it would have gone.