JetBrains Xodus is a transactional embedded database that is being switched off in favour of a graph database

The sunset notice is the first line of the README

The README opens with a warning banner, before the logo, before the badges and before any description of the technology. The project is entering its SUNSET stage as JetBrains embarks on a migration to a new YouTrackDB graph database, and readers are pointed to that repository for announcements, detailed plans and migration guidelines as the project unfolds.

That placement is a decision and it is the right one. A database library that is being retired is still installed in production systems, and the people who find that out are often not the people who made the decision. Putting the notice above the badges means nobody can read the README without seeing it.

The release history reinforces the point without needing to be interpreted. The last tagged release is v2.0.1 from 2022-03-29, before that v1.3.232 from 2020-05-03 and v1.3.124 from 2019-10-03. The last push to the repository was on 2026-07-09 and the repository is not archived, so work is still happening, but a project with a 2022 tag and a 2026 commit is doing maintenance and preparing the exit rather than developing features.

The licence is Apache 2.0, which matters for a sunsetting project, because a team that inherited it will need to know whether they can fork it. The `LICENSE.txt` and the `license/` directory are at the repository root, and the answer for an Apache 2.0 project is yes, with the obligation to keep the notice and state changes.

For an engineer, the practical reading is that Xodus is a technology to understand and possibly to maintain, and not a technology to plan around.

What the technology actually is

Xodus is a transactional, schema-less embedded database written in pure Java and Kotlin, initially developed for JetBrains YouTrack, the issue tracking and project management tool. It is also used in JetBrains Hub, the user management platform for JetBrains team tools, and in some internal JetBrains projects.

The feature list in the README is the case for the design, and each item maps to a specific architectural decision.

It is transactional and fully ACID compliant. It is highly concurrent, with reads that are completely non-blocking because of MVCC and true snapshot isolation. It is schema-less and agile, requiring no schema migrations or refactorings. It is embedded, requiring no installation or administration. It is written in pure Java and Kotlin, and it is free under Apache 2.0.

The MVCC point is the one to understand properly, because it is what makes the read behaviour possible. With multiversion concurrency control, a reader sees a consistent snapshot of the data as of some point in time, and it does not block writers and is not blocked by writers. True snapshot isolation rather than true serialisability is the stronger claim and the more unusual one, and it is what a schema-less key-value store wants: a transaction reads a stable view, and the only conflicts that can occur are write-write conflicts on the same key.

The schema-less property is the other half. In an entity store there are no tables to migrate, so adding a property to an entity or introducing a new kind of entity is a code change rather than a migration plan. For a product like an issue tracker where the shape of an issue changes constantly, that is a substantial operational saving.

The topic list matches the internals: log-structured, nosql, key-value, embedded-database, entity-store, transactional, snapshot-isolation, and also mongodb, postgresql and neo4j, which are listed as the alternatives a reader would compare it against.

Two API layers, and the choice between them is architectural

The README is explicit that there are two different ways to deal with data, which results in two different API layers, Environments and Entity Stores. This is not a convenience split, it is a difference in how much structure you take on.

The Environment layer is closer to a key-value store. You add the `xodus-environment` dependency, open an environment, and inside a transaction you open a store with a configuration and put entries into it.

try (Environment env = Environments.newInstance("/home/me/.myAppData")) {
    env.executeInTransaction(txn -> {
        final Store store = env.openStore("Messages", StoreConfig.WITHOUT_DUPLICATES, txn);
        store.put(txn, StringBinding.stringToEntry("Hello"), StringBinding.stringToEntry("World!"));
    });
}

The store configuration is per store, and `WITHOUT_DUPLICATES` in that example means the store will not hold two equal keys, which is a physical property of the store rather than a check in your code.

The Entity Store layer is object-shaped. You add `xodus-entity-store`, `xodus-environment` and `xodus-vfs`, and you work with entities that have properties.

try (PersistentEntityStore entityStore = PersistentEntityStores.newInstance("/home/me/.myAppData")) {
    entityStore.executeInTransaction(txn -> {
        final Entity message = txn.newEntity("Message");
        message.setProperty("hello", "World!");
    });
}

The `xodus-vfs` dependency appears only in the entity store case, which tells you it provides the virtual file system layer that entities can hold blobs in. The entity type is a string, `"Message"`, so adding a new kind of entity is a matter of using a new string, and the property is a string key with a value.

Both examples are wrapped in try-with-resources over a directory path, which reflects the embedded nature. The database is a directory on disk that your application opens. There is no server, no port and no separate process to administer, and the same directory is what you back up.

The repository layout shows the storage engine, the query layer and the edge cases

The top level entries are the clearest description of how the system is put together, and several of the directory names are for things a general purpose database does not have.

There is `environment/`, which is the transaction and storage engine, and `entity-store/`, the object layer on top of it. There is `query/`, the query API, and `openAPI/`, the public artifact that consumers depend on, which matches the `xodus-openAPI` Maven coordinate in the README. There is `crypto/`, and `compress/`, which are the two pieces you would expect a storage engine to need and that most application developers never think about. There is `utils/` and `tools/`, and a `samples/` directory with its own licence file and its own `build.gradle.kts`, meaning the samples are built as a separate project.

Three directory names deserve attention because they show what this engine actually had to solve. There is a `lucene-directory-v2/` directory, which points to the use of a Lucene-derived directory implementation, likely for indexing and full text search over the stored data. There is an `environment-crash-tests/` directory, which is a category of test most databases do not have as a separate module. And there is a `benchmarks/` directory.

The crash tests are the most telling. An embedded database that must survive a process being killed while writing has to guarantee that the log can be replayed to a consistent state, and proving that requires a test harness that kills the process at arbitrary points. Having that as a named module tells you the recovery path is a first class part of the design rather than an afterthought.

The build is Gradle with Kotlin DSL, using `build.gradle.kts` and `settings.gradle.kts`, and JDK 1.8 or higher is required. To build and test the project you run `./gradlew build`, and to assemble the JARs while skipping the tests you run `./gradlew assemble`. The `gradle.properties` file is at the root alongside the wrapper.

Reading Xodus as a reference implementation

For a project that is winding down, the question of what it is still good for is worth answering directly.

It is a good reference for MVCC and snapshot isolation in an embedded store. The combination of a log-structured design, non-blocking reads and a transaction model where the only conflicts are write-write on the same key is a specific and well-executed set of trade-offs, and the code is in pure Java and Kotlin, which means it is readable by people who work in either language.

It is a good reference for the entity store pattern, which is a genuinely useful middle ground between a key-value store and a relational database. You get properties on entities and the ability to hold blobs through the virtual file system, without a schema and without migrations, and YouTrack and Hub are the proof that the pattern scales to a real product.

It is a reasonable choice for a new embedded system in a narrow case, and the case is this: you need a single-process, zero-administration, ACID store with a flexible schema, and you are prepared to own the code. The Apache 2.0 licence permits forking, and a fork of a mature, tested engine is a legitimate option when the upstream is sunsetting. What is not legitimate is starting green with no intention of maintaining it, because the upstream will not be adding the features you need.

The query layer deserves a look before you commit to it, since a schema-less store with a query language is where the design decisions concentrate. The `query/` directory is where that lives, and the wiki pages linked from the README for Environments and Entity Stores are the reference documentation for the two API layers.

Editorial conclusion

Adopt Xodus only if you are maintaining an existing system that already stores its data in it, or if you are studying transactional embedded databases and want to read a well documented MVCC implementation. Do not start a new project on it, because the README states the project is entering its sunset stage as JetBrains migrates to the YouTrackDB graph database, and the last tagged release is 2.0.1 from 2022. Verify first that the version you would depend on is available on Maven Central under the coordinates in the README, that your data model fits the environment or entity store API you intend to use, and that the migration path announced for YouTrackDB will accommodate your use case before you commit.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/xodus on GitHub
3. License: Apache-2.0
4. README
5. Releases