If I understand you correctly, your KV pairs are relational in that they form a graph, with the connections being implicit in the values. And sometimes the graph is changed. In that case it would be imperative to make "reading a graph" a transaction, to avoid som eother thread changing the graph while you are in the middle of reading it - which could lead to reading an invalid state. BEGIN; <read graph>; COMMIT; It would also be imperative to make "changing a graph" a transaction, lest concurrent changes completely mess up each others changes BEGIN IMMEDIATE; <read graph>; <compute necessary changes inside app code> <update graph>; COMMIT; Now SQLite will handle syncing properly, allowing just one writer in sequence to make changes, and isolating readers from seeing transient invalid states. It strikes me as a very roundabout way to abstract relationships into KV pairs and then painstakingly rebuilding them instead of having "nodes" and "connections" that can be traversed with CTEs in SQLite doing the heavy lifting. But then again, you have chosen to share problems with your chosen implementation instead of sharing the original problem.