OrientDB: one Java engine for graphs, documents and full-text

Graph traversal through pointers instead of runtime joins

The README makes one architectural claim louder than the rest: no expensive runtime JOINs, because connections are managed as persistent pointers between records. That is the whole difference between a graph store and a relational one, stated in a sentence. In a relational engine, an edge is a row in a table and traversing it costs an index lookup or a hash join at query time. Here the link between two records is stored with the record itself, so walking from one vertex to its neighbours is pointer arithmetic rather than a join.

The stated consequence is that you can traverse thousands of records quickly. That is the project's own claim about itself, and the README pairs it with an unusually bald marketing tone for a database README, calling the engine amazingly fast. Treat that as positioning rather than measurement.

What the claim does mean concretely is that the query planner has less work to do. A traversal is a loop over already-resolved pointers, which is why OrientDB can offer both graph traversal languages and SQL over the same data without the SQL layer feeling like an imitation of something else. A graph query and a SQL query hit the same records.

The README is direct about classification. Asked whether it is a relational DBMS, it answers no, while noting that ACID transactions and SQL are supported, so it is easy to start if you already know relational work. That is the honest framing for a database that borrows relational syntax without being relational.

The tree shows a dozen plugins, not one monolith

The repository tree is the fastest way to understand what OrientDB is. `core/` is the engine. Everything else is a capability that can be added or left out: `distributed/` for the multi-master mode, `server/`, `client/` and `jdbc/` for the various ways to reach it, `lucene/` for full-text search, `gremlin/` for Apache TinkerPop traversal queries, `etl/` for the pipeline loader, `security/` for users, roles and predicates, `studio/` for the web administration console, and `object/` for object mapping back into Java.

Two of those deserve attention because they explain design choices you would otherwise find puzzling. The presence of `lucene/` means full-text search is Lucene underneath rather than a home-grown inverted index, which is the sane choice and also a real dependency to weigh. The presence of `nashorn/` is more interesting: Nashorn was removed from the JDK at version 15, so shipping a module for it means OrientDB bundles a JavaScript engine rather than relying on the one in the runtime. That is what lets server-side functions be written in JavaScript, and it is why the module exists at all on a modern JDK.

`polyglot/` and `packages/` sit alongside those. The Maven wrapper (`mvnw` and `mvnw.cmd`) and the single root `pom.xml` confirm a standard multi-module Maven build.

Distributed mode is Hazelcast with its own rules

The database runs distributed in multi-master mode, and the release notes show what that costs. Version 3.2.55, published on 2026-07-20, lists under Distributed a downgrade of the Hazelcast Kubernetes version to one compatible with the Hazelcast core version, and a fix to handle transaction status during delta sync so that independent transactions are not created. Both changes are about making replication behave when nodes are also discovered by Kubernetes.

Delta sync is the part to understand. In a multi-master topology there is no single writer, so nodes exchange changes to catch each other up. Handling transaction status during that exchange is not a detail, because a half-applied transaction arriving out of order is how a distributed database ends up with a state no single node ever committed.

Version 3.2.56, from 2026-09-02, is quieter and entirely about the query engine: correct handling of `@this` compared against record ids, the `in` syntax with square brackets and multiple values, deletion of a lightweight edge, and null ordering. Every one of those is the kind of edge case that only appears once real schemas exist.

The practical reading is that OrientDB in multi-master mode is a system with a configuration surface of its own, and one that has needed corrective work as recently as July 2026.

The CUSTOM type change is the one upgrade risk to check

Of the three recent releases, one carries an explicit breaking change and it is worth finding before you upgrade. In 3.2.55, OrientDB added a check on configuration to enable CUSTOM types across all serialization cases. Where CUSTOM values previously worked even when they were disabled, they now fail. The escape hatch is a configuration option, `db.custom.support`, which re-enables them but is off by default.

Read that carefully, because it is more than a schema concern. CUSTOM types are how OrientDB stores instances of arbitrary Java classes. Serialization behaviour changing underneath stored values is the sort of thing that surfaces months later as records that will not deserialize.

The other two releases are safer. Version 3.2.56 updates tool and object dependencies alongside the query fixes. Version 3.2.54, from 2026-07-06, fixes null handling when ordering by index, and hardens the binary protocol by closing a connection immediately when the very first request fails authentication, which closes an unauthenticated connection window.

The project publishes community builds as a tar.gz and a zip through Maven Central, so upgrading means pulling a new archive rather than following a package manager channel.

Security, schema modes and who actually licenses this

OrientDB describes a strong security profiling system based on users, roles and predicate security. Predicate security is the interesting third piece: rather than granting a role access to a whole class, you can write predicates that a record must satisfy for that role to touch it. Combined with the schema-less mode, that is how a single collection can hold documents belonging to different tenants without a schema-level partition.

On schema, the README names three modes: schema-less, schema-full and schema-mixed. Mixed is the pragmatic one for most applications, and it is also where the CUSTOM type question from the previous section becomes relevant, since typed classes are how custom Java objects get stored.

The licensing section is worth reading carefully rather than skimming. The README states OrientDB is licensed by OrientDB LTD under the Apache 2 license, and that it relies on third party libraries which are compatible with that licence: Javamail and the Java persistence API under CDDL, JNA under Apache 2, the Hibernate JPA 2.0 API under the Eclipse Distribution License, and ASM under OW2. Contributions are Apache 2 unless stated otherwise, and the repository carries a `REUSE.toml` plus a `LICENSES/` directory, so per-file licence headers are managed rather than ad hoc.

This is a commercial company shipping an Apache 2 core. That is a normal arrangement, but it means the community edition and any enterprise offering are related without being identical, and the README says nothing about the difference.

Documentation links that disagree with each other

A small inconsistency in the README tells you something about how much attention it gets. The homepage for the project is orientdb.dev, but most documentation links in the README point at orientdb.org, and several of them point at the 3.1.x documentation while the current release line is 3.2.x. One link is labelled as the main reference with text reading Documentation Version below 3.2.x, and it goes to the 3.1.x tree.

The getting started link is the exception and points at 3.2.x, so that is the one to follow. The SQL links in the body of the README still point at 3.1.x, which means syntax documentation you land on from the README may describe a version behind the release you are running.

The default branch is `develop`, not `main` or `master`. For a Java project that has shipped this long, that is a deliberate workflow choice rather than an oversight, but it has a practical consequence: the branch you land on is the integration branch, and stable tags are what you should read. The tree also carries `history.txt`, `readme.txt` and `license.txt` alongside the real `README.md`, a small sign of accumulated cruft that the marketing-oriented opening sections have outgrown.

The README closes with a BibTeX citation to a 2021 workshop paper describing recent architecture refactoring, which is the most honest summary of the project available: it has been reorganising itself for years and the release notes are where you can see whether any of it helps you.

Editorial conclusion

OrientDB makes sense when one problem genuinely needs a graph and a document store at the same time, and when the team can accept a Java runtime and a project that ships its default branch as develop. What the repository settles is the module split, the query languages, the transaction guarantees, and the operational cost: a Hazelcast-backed distributed mode with its own configuration surface, plus a strict CUSTOM type rule introduced in 3.2.55 that fails requests previously tolerated. What it does not settle is how any of this compares to Neo4j or Postgres on your workload, and the README is candid that its speed claims are its own. Start at orientdb.dev, read the 3.2.x getting started page rather than the 3.1.x links still embedded in the README, and decide on multi-master only after you have measured single-node behaviour.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. orientechnologies/orientdb on GitHub
3. Project website
4. README
5. Releases