ObjectBox Java: an on-device store where vectors sit beside your objects

Two builders, one box API

The two quick examples differ in exactly one line of setup and then converge. On the JVM the store is built with a name:

// Annotate a class to create a Box
@Entity
public class Person {
  private @Id long id;
  private String firstName;
  private String lastName;

  // Constructor, getters and setters left out for simplicity
}

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

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

On Android the Kotlin version passes `androidContext(context)` instead of a name, and everything after it matches:

Person person = new Person("Joe", "Green");
long id = box.put(person);    // Create
person = box.get(id);         // Read
person.setLastName("Black");
box.put(person);              // Update
box.remove(person);           // Delete

The four operations in the example are: `put` creates or updates, `get` reads by id, `remove` deletes. The annotated Kotlin example uses a `data class` with `@Id var id: Long = 0` and nullable `String` fields.

A Box comes from an annotation, and MyObjectBox is generated

There is no schema file and no migration script in the quick example. A class annotated `@Entity` with an `@Id` field becomes the unit of storage, and `store.boxFor(Person.class)` is what turns it into a `Box`. The store class itself, `MyObjectBox`, does not exist in your source tree: it is produced at build time, which is what makes the ObjectBox Gradle plugin a requirement rather than a convenience. That mechanism has consequences worth understanding before you wire it up. The entity shape is compiled into a generated builder, so changing a field means the plugin has to run again, and annotation processing has to be active in your build. The Kapt plugin id is where this becomes visible in practice, since the version catalog in the README uses `com.android.legacy-kapt` for an Android Gradle Plugin of 9.0 or newer and the older `kotlin.android` plus `kotlin.kapt` pair for 8.13 or older. Neither path is optional once you have entities.

The Gradle plugin changed plugin ids at AGP 9

The setup section documents two Gradle paths, and the split is not stylistic. With a version catalog you declare the plugin version once, and the README's example pins it as a beta:

# gradle/libs.versions.toml

[versions]
# For an Android project
agp = "AGP_VERSION"
# If using Kotlin
kotlin = "KOTLIN_VERSION"

# Define a variable for the version of the ObjectBox plugin
objectbox = "6.0.0-beta3"

[plugins]
# For an Android project, using Android Gradle Plugin 9.0 or newer
android-application = { id = "com.android.application", version.ref = "agp" }
kotlin-kapt = { id = "com.android.legacy-kapt", version.ref = "agp" }

On AGP 9.0 or newer the Kapt plugin is applied through the legacy id, while on 8.13 or older it comes through the Kotlin plugin pair, and the subproject script has a commented branch for each. `settings.gradle.kts` needs `mavenCentral()` in both `pluginManagement` and `dependencyResolutionManagement`, with `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)` so that a subproject cannot quietly add its own repository. The artifacts themselves live on Maven Central under the `io.objectbox` namespace.

Java 8 and Gradle 7, with two separate support matrices

Two different compatibility tables apply, and confusing them is easy. The SDK itself supports Java 8 or newer and Kotlin 1.7 or newer, and the database libraries cover JVM 8 or newer on Linux for x64, arm64 and armv7, on macOS for x64 and arm64, and on Windows for x64 only, plus Android 5.0 at API level 21 or newer. The Gradle plugin has its own floor: Gradle 7.0 or newer, Android Gradle Plugin 8.1 or newer, and JDK 11 or newer. So a project on AGP 8.0 satisfies neither the plugin requirement nor the catalog examples, and a project compiling with a newer JDK than 11 still needs the plugin floor to hold separately. The practical consequence for a JVM service is that Windows is the narrowest platform in the matrix, limited to x64, and that Android support starts at API 21 rather than at a recent level.

Vector data sits in the same store as your objects

The distinguishing feature against a plain embedded store is that vector data is managed alongside ordinary objects in the same database, and searched on the device. The stated use cases are retrieval-augmented generation, generative AI work in general, and similarity search, with the framing that this happens on the device rather than by calling a hosted index. Because it is the same store rather than a separate system, there is no second service to keep in sync with your relational data. If similarity search is the reason you are here, check the documentation site for vector length, metadata filtering and update cost before you commit.

The performance bullet names SQLite and Realm but shows no numbers

The feature list makes a comparative claim in a single line: exceptional speed, outperforming alternatives like SQLite and Realm in all CRUD operations. That is a strong statement, and the Key Features list states it without a benchmark, hardware description, dataset or methodology. Two other claims sit beside it. Efficient resource usage is described as minimal CPU, power and memory consumption, and the opening pitch adds battery-friendly resource usage, which matters on Android where a background database competes with everything else the phone is doing. Ease of use is argued as a concise API that removes the need for complex SQL queries, with built-in object relations for relationships between entities. Taken together the pitch is coherent: a small object API, relations, low resource use and vectors in the same store. But the comparison that would justify switching is asserted, and a reader should measure their own read and write mix before leaving an existing database behind.

Seven modules ship from one repository

The repository is more than the Java artifact. Alongside `objectbox-java` there is `objectbox-java-api` for the API surface, `objectbox-android`, `objectbox-kotlin`, and two reactive modules, `objectbox-rxjava` and `objectbox-rxjava3`. A seventh module, `objectbox-meshsync-android`, carries the sync side for Android. Build infrastructure sits in `build-logic/`, `gradle.properties`, `settings.gradle.kts` and `gradlew`, with `ci/`, `scripts/` and `tests/` for the rest. Continuous integration is configured in three places, a `.github/` directory, a `.gitlab-ci.yml` with a `.gitlab/` directory, and a `Jenkinsfile`, which is an unusual amount of duplication and worth knowing if you are reading the badges. The licence is Apache-2.0 in `LICENSE.txt`, and `CHANGELOG.md`, `AGENTS.md` and `CLAUDE.md` are present at the root.

The setup instructions pin a beta version

The version catalog in the README sets the ObjectBox plugin to `6.0.0-beta3`, and the release list agrees: the most recent tags are V6.0.0-beta3 on 2026-10-20, V6.0.0-beta2 on 2026-10-06 and V6.0.0-beta on 2026-07-15. So the quickstart on the main branch is written against a beta, and anyone copying the snippet gets the beta unless they change one line. The last push to main landed on 2026-10-20, which is recent enough that the branch is not idle, and the project is not archived. Two supporting resources are linked from the setup section: a getting started page and a documentation site, plus a separate examples repository for people who would rather read code than a build script. Where to get the artifacts is stated precisely, since the tools and dependencies are published to Maven Central under the `io.objectbox` namespace rather than to a private repository.

Editorial conclusion

Fit if you want an embedded store with a small API and on-device vector search, and you are building for Android or the JVM with Java 8 or Kotlin 1.7. Skip it if you need a stable non-beta release to pin against, or if your build sits below Gradle 7, JDK 11 or AGP 8.1 for the plugin. Before you commit, pin a version deliberately, read the changelog between the betas and the previous stable release, and measure your own workload rather than relying on the comparison bullet in the README.

Frequently asked questions

Official sources

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