Open wtatum opened 3 years ago
@wtatum Yes, I think that'd be a good feature. Once the read replica (https://github.com/benbjohnson/litestream/issues/8) feature is done, I don't think it'd be difficult to write a Swift library to act as a client to the HTTP replication.
Note: I'm updating the title to reflect this as a feature rather than a question.
I see. Very cool. Presumably since the replication client only needs a subset of the capabilities (basically, a client SDK to consume the WAL over HTTP and the ability to write to a live DB) the components involved on client-side are simplified relative to the footprint of the full Golang module?
Yes, the client side operations are pretty minimal. It essentially streams down snapshots & WAL frame blobs over HTTP and then uses SQLite to apply the WAL and invalidate the shared memory file (-shm
).
Would you not need Schema changes to also be replicated via the stream ?
Schema changes would be replicated automatically since they're just stored in the b-tree in the sqlite_master
table.
@benbjohnson ok thanks. good to know
Hi,
Thanks for releasing such an interesting and exciting project. I'm curious if you have any input on whether this project is suitable for a single-writer, multi-reader project for replicated data to mobile devices for offline use. I know the question has been asked before about using this for replication, but mostly as relates to clustering or data at edge use cases.
I've done this in the past at the API layer but found there to be performance and reliability challenges. Wondering if simply feeding the device as a read replica would be simpler and easier to deliver.