4 ms·
How would mutually incompatible upstream changes from multiple SQLite edge instances be resolved? You'd need user input for that, right?
by luckystarr 3y ago
How would mutually incompatible upstream changes from multiple SQLite edge instances be resolved? You'd need user input for that, right?
- zffr 3y ago> SQLedge serves reads from it's local sqlite database, and forwards writes to the upstream postgres server that it's replicating from. I don't think SQLite data is ever written back to the postgres DB so this shouldn't be an issue
- simonw 3y agoI don't think that's a problem here, because the write queries aren't handled by the local SQLite databases - instead, the proxy forwards them directly to the PostgreSQL instance, so presumably the resulting changes show up in SQLite when they are replicated back down again.
- zknill 3y agoThe writes via SQLedge are sync, that is we wait for the write to be processed on the upstream Postgres server. So it operates as if SQLedge wasn't in the request path from application to Postgres. The writes to Postgres are only reflected in SQLite when the data is received back from the Postgres server on the replication slot. This means writes are eventually consistent, currently, but I intend to include a feature that allows waiting for that write to be reflected back in SQLite which would satisfy the 'read your own writes' property. SQLedge will never be in a situation where the SQLite database thinks it has a write, but that write is yet to be applied to the upstream Postgres server. Basically, the Postgres server 'owns' the writes, and can handle them just like it would if SQLedge didn't exist.
- luckystarr 3y agoSo, the advertised performance is just for the read-part, not the write-part? As far as I understand: writing would still exhibit the same characteristics as before, while reads would never be affected by other users.
- kiitos 3y agoWhat about migrations?