One database file, but who closes it?
LatticeDB brings graph and search into one file. Ownership, update boundaries and a tested way back still need a place in the application.
Fewer boxes to move
You edit a document, but search still returns its old wording. Where do you look? The document store, the vector store, the place that holds its relationships? It feels like finishing a move while your mail keeps going to the old address.
The phrase that caught my attention in the LatticeDB README was ‘one file.’ Its README describes an embedded database combining a graph, vector search and full-text search. That is an appealing shape for a local application.
Imagine a personal research app. Authors connect to documents, paragraphs are searchable, and results lead back to the original. In this example, keeping versions together matters more than the number of files.
An edit saves, then embedding generation fails. The reader sees the new wording while search retrieves yesterday’s paragraph. Separate stores leave the application tracking which step finished and which one is still waiting.
Bringing the data together offers a chance to reduce that coordination. The app must still choose what becomes visible together. Keep the previous version until the new embedding is ready? Show the edit as pending? Sharing a file does not make that decision.
How many keys?
The next detail in the README is less glamorous: one owning process on one machine, with a single-writer model. It recommends a different architecture for multiple independent applications writing to the same database or clients connecting over a network.
Now give the imaginary research app a background importer. It is tempting to have the interface open the file and let the importer open it too. All they would need to exchange is a path.
But that changes the meaning of ‘one.’ We have put the data in one home, then proposed two independent owners.
For this app, I would first consider routing writes through the process that owns the database. The importer hands over prepared material; the owner manages ordering and failure. If that arrangement is awkward, a server database serving several processes may fit the workload better.
Closing the app also needs a decision. Cancel an import, or finish it before exiting? Where should a restart pick up? Removing a separate database service does not remove the application’s shutdown sequence.
Open the box you copied
The README documents WAL recovery, a live lattice backup command and continuous backup. It distinguishes that backup from clustering. Shipping changes elsewhere does not make the destination another operating database server.
Suppose the research app moves to a new laptop. Seeing its file on the desktop is reassuring. The more useful question is which committed edit came with it.
I would include opening the backup in a separate location in this hypothetical move. Check the last committed document version, then search for that document and compare the content. A completed copy is answering a different question.
A process stopping unexpectedly, a lost disk and an accidentally deleted document also call for different recovery plans. Someone still has to decide which point the application should return to.
This is a reading of the project’s documented boundaries, followed through an imagined small app. I have not operated LatticeDB or reproduced its performance claims.
One file certainly reduces the luggage. I would send one question along with it for the person opening it on the new laptop.
How much of the last edit is actually in here?