ObjectBox Java: an on-device object and vector database for Android and the JVM

What ObjectBox Java solves, and who it is for

Most Android and JVM applications that need local persistence face the same choice: write SQL against SQLite, or adopt a mapping layer on top of it. ObjectBox takes a third route. The README describes it as "a lightweight yet powerful on-device database & vector database designed specifically for Java and Kotlin applications", and the API it exposes is object-centric rather than row-centric. You annotate a class with @Entity, the build generates a store class, and you put objects into a Box.

The intended audience is narrow and specific. This is for developers building Android apps or JVM desktop and server-side applications where the data lives inside the process. The README lists the supported database libraries as JVM 8 or newer on Linux (x64, arm64, armv7), macOS (x64, arm64) and Windows (x64), plus Android 5.0 (API level 21) or newer. The SDK itself targets Java 8 or newer and Kotlin 1.7 or newer. If your application talks to a remote database over a network, this is not the layer you are looking for.

The vector angle is the newer part of the pitch. The README calls ObjectBox the "first on-device vector database" and says you can "manage vector data alongside your objects and perform superfast on-device vector search". That framing targets RAG and similarity search running on the device rather than in a data centre. Treat the marketing adjectives as marketing; the structural claim, that vectors and ordinary objects share one store, is the part worth evaluating.

Boxes, entities and the generated MyObjectBox class

The mechanism is code generation plus a native store. You declare a plain class, mark it @Entity, and mark one field with @Id. The ObjectBox Gradle plugin runs at build time and produces a MyObjectBox class. Your application then builds a BoxStore through MyObjectBox.builder(), and asks that store for a Box typed to your entity. The Box is the unit of work: put, get, remove. There is no session, no transaction object in the everyday path, and no query string unless you want one.

The README's JVM example shows the whole cycle in a few lines. A Person entity with an @Id long, a BoxStore built with the name "person-db", a Box<Person> obtained from store.boxFor(Person.class), then put, get, mutate and put again, and remove. The Android Kotlin example is the same shape with two differences: the builder takes .androidContext(context), and the entity is a data class with a defaulted id field. Everything else maps one to one.

Two consequences follow from generating code at build time. First, the plugin is not optional; without it there is no MyObjectBox and no store. The README states the ObjectBox Gradle plugin supports Gradle 7.0 or newer, Android Gradle Plugin 8.1 or newer, and JDK 11 or newer. Second, the generated class is a build artefact, so it does not appear in version control and it does not exist until a build has run. An IDE that has not synced the Gradle project will show unresolved references, which is a common first-run confusion rather than a defect.

The repository layout reflects this split. objectbox-java-api holds the annotations and public interfaces, objectbox-java holds the JVM implementation, objectbox-android the Android variant, objectbox-kotlin the Kotlin extensions, and objectbox-rxjava and objectbox-rxjava3 the reactive adapters. There is also objectbox-meshsync-android in the tree, which the README does not describe. If you need synchronisation between devices, read the separate documentation rather than assuming the README covers it.

Installing ObjectBox Java with Gradle and running a first put

ObjectBox tools and dependencies are published on Maven Central under the io.objectbox namespace. The README documents two setups, Gradle and Maven, and points to docs.objectbox.io/getting-started for the full walkthrough. The Gradle path uses a version catalog: you declare the plugin version once, alias the ObjectBox plugin, and apply it in your module. The README's own example pins the plugin at 6.0.0-beta, which is the version of the most recent release listed for the repository. If you want the stable line instead, the 5.4.2 release is the one to use, and the version string in the catalog is the only thing that changes.

The catalog entry declares the plugin and its version. Note that the README shows separate blocks for Android Gradle Plugin 9.0 or newer and for 8.13 or older, because the kapt plugin id differs between them.

# gradle/libs.versions.toml
[versions]
objectbox = "6.0.0-beta"

[plugins]
objectbox = { id = "io.objectbox", version.ref = "objectbox" }

In the root build script you alias the plugin with apply false, so it is resolved but not applied at the root. The README shows this step for Android and JVM projects alike, with the Kotlin plugin aliases included when Kotlin is in use.

// build.gradle.kts
plugins {
    alias(libs.plugins.objectbox) apply false
}

After the plugin is applied to your module and the project has synced, the generated MyObjectBox class becomes available. The README's JVM example then builds a store, obtains a box, and performs one create and one read. The id returned by put is the value you pass to get.

BoxStore store = MyObjectBox.builder()
        .name("person-db")
        .build();

Box<Person> box = store.boxFor(Person.class);

Person person = new Person("Joe", "Green");
long id = box.put(person);
person = box.get(id);

On Android the same code differs only in the builder call, which takes .androidContext(context) instead of .name(). If the build fails with an unresolved MyObjectBox, the plugin has not run; if it fails on the kapt plugin id, you are on the wrong side of the AGP 8.13 / 9.0 split the README describes.

Where ObjectBox Java is the wrong tool

The README claims ObjectBox outperforms SQLite and Realm in all CRUD operations. That is a vendor claim made in the project's own README, not an independent measurement, and the README gives no methodology, hardware or dataset behind it. Nothing available here lets a reader verify it. Treat the performance framing as a hypothesis to test against your own workload, not as a settled fact.

The harder limitation is architectural. This is an embedded database. It lives in your process and it owns a directory on the local filesystem. That rules it out for anything where multiple writers on different machines must see the same rows immediately, where a DBA needs to run ad-hoc SQL against the live data, or where your operational tooling assumes a JDBC endpoint. The README does not document a server mode; a search phrase about an "objectbox java server" does not correspond to anything described in the README.

There is a build-tool coupling too. The plugin requires Gradle 7.0 or newer, Android Gradle Plugin 8.1 or newer and JDK 11 or newer. A project pinned to an older AGP, or one using a build system the plugin does not target, cannot adopt it without upgrading the build first. The README documents Gradle and Maven setups; it does not describe a path for other build tools.

The current release line adds friction of its own. The most recent release is 6.0.0-beta, dated 2026-07-15, while the newest stable release in the list is 5.4.2 from 2026-05-06. The README's own Gradle example pins the beta. A team that cannot ship a beta dependency should pin 5.4.2 and check whether the features they want exist there. The repository was last pushed on 2026-08-03 and is not archived, but the README does not document a rollback or downgrade procedure if a beta upgrade goes wrong.

ObjectBox Java against Room and raw SQLite

The realistic alternative for an Android team is Room, or SQLite through the platform API. The difference is where the schema lives. Room keeps SQL at the centre: you write @Dao interfaces with @Query annotations containing SQL strings, the compiler checks them against your entities, and the generated code wraps SQLite. ObjectBox removes the SQL layer entirely. There are no query strings in the basic path shown in the README, only box.put, box.get and box.remove against typed objects. Relations are handled by the framework rather than by foreign keys you declare.

That trade is real in both directions. Room's SQL surface means anyone who knows SQLite can read the queries, and the database file remains inspectable with standard SQLite tooling. ObjectBox's object surface means less boilerplate and no mapping code, at the cost of a build-time code generator and a store format you interact with through the library. The repository also carries objectbox-rxjava and objectbox-rxjava3 modules, so teams already using RxJava can keep that style; Room has its own coroutine and Flow integration, and the README here does not compare the two.

One more difference matters for the vector use case. Room and SQLite have no built-in vector index in the form the README describes. If on-device similarity search is the reason you are looking at ObjectBox, the alternative is not Room but a separate vector library bolted onto your existing store, which means two persistence systems and a synchronisation problem between them. The README's claim that you can "manage vector data alongside your objects" in one store is the specific thing that alternative does not give you.

Licence, maintenance and the cost of upgrading

The repository is licensed Apache-2.0, and the README links to LICENSE.txt in the repository root. Apache-2.0 is a permissive licence that permits commercial use and modification, and it includes a patent grant. It is not a copyleft licence, so it does not require you to publish your application source. Note that the licence covers the code in this repository; the README points to objectbox.io for the product generally, and the README does not state what terms apply to separately distributed components such as the sync or admin tooling. If you are evaluating those, read their own terms rather than assuming Apache-2.0 carries over. This is a description of the licence text, not legal advice.

The repository is not archived and the last push was on 2026-08-03, roughly seven weeks before the date of this article. The release cadence visible in the list is three releases between 2026-03-30 and 2026-07-15. There is a CHANGELOG.md in the repository root, which is where the README points readers for release notes.

Upgrade cost is mostly the plugin version. The ObjectBox Gradle plugin has its own compatibility floor (Gradle 7.0+, AGP 8.1+, JDK 11+), and the README shows that the kapt plugin id changes between Android Gradle Plugin 8.13 or older and 9.0 or newer. That means an AGP upgrade can force a change in your version catalog even when ObjectBox itself has not changed. The README does not document a migration procedure between 5.x and 6.x, so read CHANGELOG.md before moving a production app across that boundary.

Editorial conclusion

Adopt ObjectBox Java if your app owns its data locally and you want objects persisted without writing SQL, and if the Gradle plugin fits your build. Skip it if you need a server-side relational database, ad-hoc SQL reporting, or a plain JDBC connection. Before committing, verify the plugin version against your Gradle, Android Gradle Plugin and JDK versions, confirm your target platform is in the supported list (JVM 8+ on Linux, macOS and Windows; Android 5.0, API level 21, or newer), and decide whether you want the 6.0.0-beta line or the stable 5.4.2 release.

Frequently asked questions

Official sources

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