objectbox/objectbox-dart: an object database for Flutter with a code generator and on-device vector search

A box of objects, and how you get one

ObjectBox is a Flutter database for fast Dart object persistence, and its core abstraction is the box, which holds objects of one Dart type.

// Annotate a Dart class to create a Box
@Entity()
class Person {
  @Id()
  int id;
  String firstName;
  String lastName;

  Person({this.id = 0, required this.firstName, required this.lastName});
}

final Store store = await openStore(directory: 'person-db');
final box = store.box<Person>();

var person = Person(firstName: 'Joe', lastName: 'Green');
final id = box.put(person); // Create

person = box.get(id)!;      // Read

person.lastName = 'Black';
box.put(person);            // Update

box.remove(person.id);      // Delete

The shape of that code is the point. A store is opened once with a directory, a box is requested for a type, and the CRUD operations are methods on the box. There is no SQL, no rows and no mapping between a row and an object, because the objects are the storage format.

The annotation on the class is not decoration either. `@Entity()` marks the class as storable and `@Id()` marks the identifier field, and the annotation drives code generation, which is where the query API comes from.

The project is Apache-2.0 licensed, the documentation is at docs.objectbox.io, and the default branch is `main`. The packages are published to pub.dev, and the last push to the repository was on 2026-10-12 with releases v5.3.0 on 2026-03-25, v5.3.1 on 2026-03-27 and v5.3.2 on 2026-05-20.

The generated query API is the part you feel

Queries are built from generated property accessors, and the operators are combined rather than spelled out.

final query = box           // Query
    .query(Person_.firstName.equals('Joe') & Person_.lastName.startsWith('B'))
    .build();
final List<Person> people = query.find();
query.close();

`Person_` is generated, and it exposes a property accessor per field, each with the operators that field's type supports. The `&` combines two conditions, and the result is a `QueryBuilder` that you `build()` into a query object, run and then `close()`.

That close call is worth noticing, because it is the one piece of manual resource management in an otherwise clean API, and it is a hint about how the library works. The query holds native resources, so it is not garbage collected for you.

The generator is a package of its own, `objectbox_generator`, and the repository has a `tool/init.sh` script whose stated purpose is to generate code and get you started quickly after cloning. So the workflow for a new project is to annotate the classes, run the generator, and use the generated accessors.

The claims the project makes about that API are worth quoting precisely, because they describe what the type system gives you. Relations, object links and relationships, are built in. Queries filter data as needed, even across relations. The library is statically typed, with compile time checks and optimisations. And schema migration is a supported operation, so you can change your model with confidence.

Statically typed is the word that matters in a database context. A query that references a field that was renamed is a compile error rather than a runtime exception, and for a mobile application whose model changes across releases that is a meaningful difference.

Vector search on the device, and what it changes

The headline claim is that ObjectBox is the very first on-device vector database for Flutter and Dart AI apps, and that it provides vector support for on-device AI applications, with intuitive APIs for persisting local Dart objects and managing vectors.

That is worth unpacking, because an embedded vector index is not a small feature. It means the database stores embeddings alongside the objects and can search them by proximity, which is the primitive that a local RAG pipeline, a photo search or a semantic matcher needs. The usual alternative is to run the search on a server, which means a network round trip for something the device could answer, and for an application that has to work offline that is a functional difference rather than a performance one.

The project frames this in terms of independence. By storing data locally on the device, ObjectBox allows you to cut cloud costs and create an app that does not require a connection, and the pitch for the whole stack is an offline-first application whose data never has to leave the phone.

The other headline properties are conventional for a serious embedded database, and they are listed as such. ACID compliant, atomic, consistent, isolated and durable. Multiplatform, across Android, iOS, macOS, Linux, Windows and any POSIX system. Scalable, growing with the app and handling millions of objects. And sustainable, which the project defines as being frugal on CPU, memory and battery or power use, and reducing CO2 emissions, which is an unusual thing for a database to claim but a real constraint for a mobile application.

The combination of a vector index and an ACID store in one embedded engine, with a typed query API over both, is the actual product here. The rest of the README is the standard furniture of a database project.

Sync, and the published benchmark that is five years old

Two parts of the README deserve a sceptical reading.

The first is Data Sync, which the project describes as a data synchronization solution that keeps data in sync across devices and servers, both online and offline, and which the comparison section frames as an effective self-hosted Firebase alternative. The feature list puts it simply, keeps data in sync offline or online, between devices and servers. It is a separate offering with its own documentation, and the repository ships a separate native libraries package for it, `objectbox_sync_flutter_libs`, alongside the plain `objectbox_flutter_libs`.

The second is the benchmark. The README states that it was tested across the four main database operations, CRUD, that each test was run multiple times and executed manually, and that data preparation and evaluation were done outside the measured time. The comparison is ObjectBox against sqflite and Hive, and the image is labelled as last updated on 2021-09-11.

So the published numbers are five years old, they were gathered by hand rather than in CI, and the comparison set does not include the many embedded databases that have appeared since. The project does at least tell you how to check it yourself, since the `objectbox-dart-performance` repository is a Flutter benchmark app for comparing ObjectBox and other databases, and there is an in-repository `benchmark` package used internally to microbenchmark implementations during development.

The honest reading is that the performance claim is the least verifiable part of the documentation and the most repeated. For a database, the right response is to run the comparison on your own data model rather than to accept the chart.

The monorepo layout, and where the code lives

This repository holds all ObjectBox Dart and Flutter packages as separate directories, which is worth reading because it shows the split between the API, the generator and the native code.

The `objectbox` directory holds the ObjectBox Dart APIs. `objectbox_generator` is the code generator. `objectbox_test` is the unit tests of the Dart APIs and `objectbox_test_app` is the Flutter integration tests. Then there are the two native library packages, `objectbox_flutter_libs`, which provides the native database libraries for Flutter apps, and `objectbox_sync_flutter_libs`, the same with ObjectBox Sync enabled. And `benchmark` is used internally to microbenchmark and compare various implementations during development.

The separation of the native libraries into their own packages is a practical detail with a real consequence. A Flutter app that uses ObjectBox must include the correct native binary for each platform it ships, and the `flutter_libs` package is what provides it, with the sync variant as a separate package for apps that need sync. So the dependency list of a Flutter application ends up with both a Dart package and a platform binary package.

The repository also carries a `dev-doc/` directory, an `AGENTS.md`, a `CONTRIBUTING.md`, a `.gitlab-ci.yml` alongside the GitHub workflows, an `install.sh`, and a `tool/` directory holding the setup script. The dual CI configuration is a small signal that contributions are accepted from more than one place.

Where objectbox-dart is the wrong choice

The first wrong case is a team that wants to own the whole stack. The Dart API is Apache-2.0 and open source, and the native database is delivered as a separate package containing a compiled binary, and the sync layer is a separate product. That is a reasonable commercial arrangement, but it is not a fully self contained open source stack, and a project that needs every component to be auditable in one place should price that in.

The second wrong case is an application that is really a cache of server data. ObjectBox is a local database with its own model, its own migrations and its own sync semantics, and if the server is the source of truth and the local copy is disposable, a simpler key value store or a SQL library with less ceremony may be the better answer.

The third is a project where a change to the data model has to be painless. The generator, the generated property accessors and the migration step are all costs, and they pay off only if you intend to keep using the typed model over time.

The fourth is a team that expects the benchmark to settle the argument. The chart is from 2021, and the right way to choose an embedded database is to run the comparison on your own data, which the project helpfully makes possible.

On the state of the project, the releases are 5.3.0, 5.3.1 and 5.3.2 between March and May 2026, the last push was on 2026-10-12, and the repository is not archived. The licence is Apache-2.0, the code is Dart, and the documentation, the getting started guide and the video tutorials are hosted on docs.objectbox.io rather than in the repository.

Editorial conclusion

Adopt objectbox-dart if you are building a Flutter or Dart application that stores rich objects offline and want typed queries without writing SQL, especially if the app does on-device AI work where the vector index is the deciding factor. Do not adopt it if you need a fully free and self contained stack with no vendor components, since the native database libraries are shipped as separate packages and the sync product is a separate offering, and do not rely on the published benchmark chart to justify the choice, since it was last updated on 2021-09-11. Verify first which platform binaries your Flutter targets need, that the generated code for your entity classes is regenerated after a schema change, and that the schema migration path in your plan covers the model changes you intend to ship.

Frequently asked questions

Official sources

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