DataScript: an immutable in-memory Datalog database for Clojure and ClojureScript

What DataScript is for, and who it is for

The README opens with a question: "What if creating a database would be as cheap as creating a Hashmap?" That framing is the whole design brief. DataScript is an in-memory database and Datalog query engine written in Clojure and ClojureScript, intended to run inside the browser. You create a database on page load, put data in it, track changes, run queries, and forget about it when the user closes the page.

That makes it a poor fit for anything that must survive a process restart on its own, and an excellent fit for applications whose real problem is state. The README lists the audience directly: client-side applications that need to track a lot of state during their lifetime. The stated benefits are a central, uniform way to manage application state, decoupling between rendering, server sync and undo/redo, and Datalog as a query language for non-trivial questions about current app state. The projects listed as users are consistent with this: Roam Research, LogSeq, Athens Research and Hulunote are all note-taking or outliner tools where the graph is the product and the browser is the runtime.

If you are a Clojure or ClojureScript developer who has been filtering vectors by hand, or maintaining a hand-rolled normalized store, this is the gap DataScript fills. If you are looking for a server database, it is not that.

Datoms, indexes and why a query is a hashmap lookup

DataScript databases are immutable and built on persistent data structures. The README is explicit that they are "more like data structures than databases (think Hashmap)". Every fact you add produces a new database value rather than mutating an existing one, which is what makes rewinding to any point in time and rendering consistent state straightforward.

The README describes query execution in concrete terms: unlike querying a real SQL database, a DataScript query "all comes down to a Hashmap lookup. Or series of lookups. Or array iteration." There is no query planner crossing a network boundary, no connection pool, no transaction log to flush. The README concedes the scaling story plainly: put a little data in and it is fast; put in a lot and at least it has indexes, which should beat filtering an array by hand.

That last sentence is the honest boundary of the project. The performance argument is relative to hand-written filtering in the same process, not to a database server. The repository layout shows the supporting material for this: a docs directory containing queries.md, tuples.md and storage.md, plus bench and bench_datomic directories for benchmarking. The docs files are where the query and storage semantics are actually specified; the README only points at them.

Installing DataScript and running a first query

The README gives two dependency declarations, one for Leiningen and one for deps.edn, both pinned to 1.8.1. The project is published as datascript/datascript on Maven. There is no separate installer and no server to start.

For a deps.edn project, add the coordinate to your dependencies map:

datascript/datascript {:mvn/version "1.8.1"}

Leiningen users get the equivalent vector form:

[datascript "1.8.1"]

One build-tool caveat is called out in the README with an explicit "Important!". If you use shadow-cljs, you must add a compiler option, otherwise the externs for the JavaScript interop are missing:

:compiler-options {:externs ["datascript/externs.js"]}

The README links three issues and one pull request as background for that requirement, so it is a known recurring source of confusion rather than an edge case. After that, the entry points are the API docs on cljdoc, the Getting started wiki page, and the queries.md file in the docs directory. The repository also ships demo applications: a ToDo app with localStorage persistence, filtering and undo/redo, and a chat demo, both with live versions linked from the README. Those demos are the fastest way to see what a complete DataScript application looks like before writing your own schema.

Where DataScript stops being the right tool

The README states the limitation itself: DataScript is "cheap to create, quick to query and ephemeral". Ephemeral is the operative word. Nothing in the core library's description promises that your data outlives the page, and the intended lifecycle ends with the user closing the tab.

Durability is deliberately pushed to a separate project. The README lists DataScript SQL Storages as a related project providing "durable storage implementations for popular SQL databases", and there is a docs/storage.md file in the repository. So persistence exists in the ecosystem, but it is not the core library's job, and the README does not document rollback, crash recovery or write-ahead behaviour for the in-memory engine. If you need those guarantees, you are reading the wrong README.

The second limitation is scale. The README's own framing sets expectations at hashmap lookups and array iteration. There is no mention of concurrent writers, replication, or a query optimizer that handles large joins across millions of datoms. The bench and bench_datomic directories suggest the maintainers measure against Datomic, but the README makes no performance claim you can rely on for sizing. Treat any capacity estimate as something you must measure on your own data.

The third is language reach. This is a Clojure and ClojureScript library. The README lists a DataScript-mori wrapper for use from JS and a datascript-transit project for serialization, but JavaScript consumers are working through an interop layer, not a first-class API. If your team is not already in the Clojure ecosystem, the cost of adopting DataScript is the cost of adopting ClojureScript.

DataScript compared with Datahike and Datalevin

The related searches around this project include Datahike and Datalevin, which are the natural comparisons. The README does not discuss either, so the honest difference has to be drawn from what DataScript itself claims: it is in-memory, it is meant for the browser, and it is a building block rather than a database service.

Datahike and Datalevin are Datalog-family stores in the Clojure world that target durable, on-disk operation. The architectural difference is where the data lives. DataScript keeps everything in the process and leans on persistent data structures for immutability and cheap snapshots; a durable store has to solve disk layout, indexing on disk, recovery and concurrent access, which is precisely the surface DataScript avoids by staying in memory. That avoidance is the feature. It is why creating a database can be as cheap as creating a hashmap.

The practical consequence: if your requirement is a queryable store that survives a restart without a separate persistence layer, DataScript is the wrong starting point and one of the durable Datalog stores is the right one. If your requirement is fast, immutable, queryable state inside a single client process, DataScript's in-memory design is the reason it is fast, and a disk-backed store would be paying for durability you do not want on every keystroke. The related project DataScript SQL Storages exists precisely to bridge the two, keeping DataScript's query model while delegating durability to an SQL database.

Maintenance, releases and licence cost

The repository is not archived. The last push was on 2026-08-15, and the most recent release, 1.8.1, carries the same timestamp, with 1.8.0 two days earlier and 1.7.8 in October 2025. That pattern, a long gap followed by a pair of releases, is worth noting when you plan upgrades: the project moves in bursts rather than on a schedule, so you should not assume a fix lands in the next quarter.

Upgrade cost is low in absolute terms because the dependency is a single Maven coordinate with no transitive service to operate. The real cost sits in the shadow-cljs externs requirement and in the fact that the API is documented across cljdoc, the wiki and the docs directory rather than in one place. A version bump means checking the CHANGELOG.md at the repository root, which is the only release-notes source present in the layout.

The licence is EPL-1.0. That is a weak copyleft licence: it permits use in larger works under other terms, but modifications to the EPL-covered code itself carry obligations, and the licence includes a patent grant. How that interacts with your distribution model, especially if you ship a modified fork or bundle the library into a compiled artifact, is a question for your own legal review. The repository ships the LICENSE file at the root, so the authoritative text is one file away.

Editorial conclusion

Adopt DataScript when the state lives and dies with the browser session and you want Datalog over it: note-taking graphs, outliners, undo/redo stacks, client-side caches. Do not adopt it as a system of record; there is no server, no durability guarantee in the core library, and the README itself calls it ephemeral. Before committing, verify what your build tool needs (shadow-cljs users must add the externs entry), check whether your persistence requirements are covered by the separate datascript-storage-sql project, and confirm the licence terms of EPL-1.0 against how you distribute your application.

Frequently asked questions

Official sources

1. Issues
2. License: EPL-1.0
3. README
4. Releases
5. tonsky/datascript on GitHub