Afterword: Where Datalevin Is Going

This guide began with a practical claim: SQL does not have to be the default center of application state. Application databases do not need to be organized around tables, SQL strings, and separate systems for every new access pattern. A database can store facts, expose them through Datalog, keep transactions small and explicit, and still support key-value access, relational joins, graph traversal, documents, text search, vectors, operations, and persistent memory for intelligent systems.

That claim is not only about features. It is about a shape of software. The same body of facts can be updated transactionally, joined relationally, traversed as graph edges, searched as text, connected to vectors, recalled as memory, and audited as evidence. Datalevin's core choice is to keep the unit of information small and explicit: an entity, an attribute, and a value. Everything else in the guide builds from that choice.

The principles are meant to remain stable even as the implementation grows. Datalevin is current-state oriented by default, because most operational systems need to read and write the present quickly. It makes history, provenance, and memory explicit when the domain needs them, instead of treating every past database state as the universal answer. It keeps storage simple, using EAV and AVE indexes for the common Datalog path, while letting specialized indexes act as additional capabilities. It is embedded-first, because locality and simplicity matter, but it also has a server mode for teams, tools, and multi-language clients.

The next directions follow from the same model.

One direction is semiring provenance. Chapter 15 described this as a more general answer than transaction history alone. The full book's exclusive AI memory chapters develop the practical need: confidence, utility, source episodes, supersession links, and explanation trails should not be informal comments around the data. They should be queryable facts. A semiring-provenance layer can make this systematic: joins combine supporting annotations, alternative derivations merge competing explanations, and derived facts can carry the evidence that produced them. That opens a path to confidence propagation, rule-application tracing, RAG source attribution, min-cost explanations, and incremental maintenance of derived views.

Another direction is fuller distribution. Datalevin already uses Raft for high-availability control-plane work. A natural next step is to extend the distribution story from leader coordination toward data placement and data-plane replication, so Datalevin can grow beyond an embedded database with server and HA modes. That is a larger engineering project, but the fact model is a good fit for it. Datoms are small, typed, and independently addressable. Transactions have clear write sets. Index maintenance is explicit. Those properties make distributed boundaries easier to reason about than they would be in a system where the primary unit is an opaque document or a table row with many unrelated columns.

Distribution also leads naturally to entity-oriented sharding. If facts are partitioned by entity id, stable entity identity, or another entity-aware placement key, each shard can run the same Datalog query plan over its local facts. For many query shapes, the coordinator's work is then to merge compatible result sets, apply limits, combine aggregates, or perform a small amount of cross-shard joining. Not every query becomes trivial, and cross-entity joins still need careful planning, but a fact-oriented model gives the system a clean unit of placement. The same logical query can be sent to many nodes without rewriting the user's application model around the physical layout.

A third direction is richer Datalog for analytics. This guide used Datalog mostly for operational queries, rules, recursion, and memory assembly. But the same language can express more analytical computation if the syntax grows in the right way. One important extension is aggregation in rule heads. That would allow derived relations to summarize data as they are defined, instead of forcing every aggregation to live only at the outer query boundary. With recursive rules, indexes, and controlled aggregation, Datalevin could support more analytical work inside the database, including graph analytics and selected iterative algorithms over facts.

These directions should not be read as promises about release dates or compatibility details. They are design directions. The important point is that they do not require abandoning the model developed in this guide. Semiring provenance adds annotations to facts and derivations. Distribution places facts and indexes across nodes. Analytical Datalog extends how derived facts are computed. In each case, the center remains the same: small facts, explicit transactions, Datalog query forms as data, and application policy grounded in queryable state.

That is the larger bet behind Datalevin. Replacing SQL's default role is not only about storing bytes durably. A database for modern applications should help a system remember what it knows, explain why it knows it, revise that knowledge when the world changes, and carry the same model from a local process to a distributed service. The work ahead is to make more of that power direct, reliable, and easy to use without losing the simplicity that makes the current system practical.