3 ms·
> SQLite isn't just on the same machine as your application, but actually built into your application process. How is that different than whats commonly happen
by vmception 4y ago
> SQLite isn't just on the same machine as your application, but actually built into your application process.
How is that different than whats commonly happening? Android and iOS do this... right? ... but its still accessing the filesystem to use it.
Am I missing something or is what they are describing just completely commonplace that is only interesting to people that use microservices and never knew what was normal.
- mrkurt 4y agoThis is how client apps use sqlite, yes. Single instance client apps. Litestream is one method of making sqlite work for server side apps. The hard part on the server is solving for multiple processes/vms/containers writing to one sqlite db.
- vmception 4y agointeresting, such a weird way to describe it then. but I guess some people are more familiar with that problem.
- nicoburns 4y ago> the hard part on the server is solving for multiple processes/vms/containers writing to one sqlite db. I feel like if you have multiple apps writing to the database then you shouldn't be using SQLite. That's where Postgres etc completely earn their place in the stack. Where litestream is really valuable is when you have a single writer, but you want point-in-time backups like you can get with postgres.
- mrkurt 4y agoWe disagree, a little. I feel like that if you have multiple apps writing to the DB, Litestream is pretty close to making sqlite viable for a lot more apps.
- tlb 4y agoIt's normal (and HN does something similar, working from in-process data) for systems that don't have to scale beyond one server. If you need multiple servers you have to do something, such as Litestream.