4 ms·
The 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 reque
by zknill 3y ago
The 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?