ObjectBox 1.0 is a SQLite database replacement. It makes object persistence on mobile (and IoT) devices simple and fast.

Code actually tells best what ObjectBox does (yes, it also does Kotlin):

Don’t get us wrong: we think SQLite is a great piece of software and SQL is really powerful. We just do not love touching SQL so much when developing apps. That’s why we developed a very fast and easy alternative.

Being lazy or eager? Relations

ObjectBox comes with strong support for relations. How do you store a new object along with referenced objects? It’s simple:

Thus, with a single put(playlist), ObjectBox will not only persist the Playlist object but also the two associated Song objects. This also works with objects that were already persisted in the database.

A common challenge with relations is that they are typically loaded lazily. This can cause brief delays when accessing a relation for the first time, because the data must be pulled from the database at that moment. This in turn can cause the UI to slow down, e.g. when scrolling through the list (known as the “N+1 query problem”). Obviously, this may be harmful to the user experience and thus something you try to avoid. That is one of the reasons some ORMs do not support relations at all.

ObjectBox solves this challenge by enabling queries to preload relations in the background – aka “eager loading”. This makes processing the query result in the main thread super fast. Once the query is processed, eagerly loaded relations do not touch the database at all.

Eager loading is part of the Query API and not the entity itself. This gives you full flexibility over when to load what. For each query, you can specify which relations to preload like this:

POJOs

We want to keep things simple. The objects returned from ObjectBox are POJOs (plain old Java objects). When you get an object, all properties are initialized and ObjectBox will never change the values. And, of course, you can pass those objects around in different threads.

Let’s also have quick look on entity classes. First, ObjectBox does not enforce a specific base class. You are free to extend from any class. Second, the classes also define the data model in the database (the “database schema”). Adding and removing entities/properties just work. Only renames require your interaction. The days of CREATE TABLE scripts are finally gone, and typical data model updates do not require migration scripts.

Fast

We keep saying ObjectBox is fast. But how fast? And for what? We put together an open source benchmarking app, which come with a couple of performance tests for CRUD, queries, etc. Please check it out, have a look at the code, and make up your mind on the performance of ObjectBox. We really want to provide fair benchmarks.

Thank you!

We will add each and everyone that supports us and is part of the ObjectBox journey on our About us page! ObjectBox really is about you. So, let us know how you contributed (small things sometimes matter most…) and send us your picture and link (e.g. to your GitHub Account, Website or LinkedIn page).

Roadmap: bring your app to the edge

Our vision for ObjectBox is edge computing. It brings the data back to the user, to the device in his hand or home. We believe this is the future of computing. Small devices are tremendously powerful now, and it’s time to claim independence from the cloud while keeping in touch.

Before we go all edgy, we will address some essentials: Our plan for Version 1.1 is to rework the query API to and make expose object link API (aka “joins”). We also have to do our homework with some corner cases for data model changes. And of course, you may still find rough edges with the 1.0, which we’ll get rid off as soon as possible. We are dedicated to make ObjectBox a pure pleasure to work with.

We’re continually looking for feedback. Please do let us know what you think about ObjectBox: either by writing us at contact@… (our domain), or by answering these quick questions. Thank you!