fbpx
Industrial IoT (IIoT) edge solution for railway operators – a Kapsch ObjectBox Case Study

Industrial IoT (IIoT) edge solution for railway operators – a Kapsch ObjectBox Case Study

Executive Summary of IIoT Edge Case Study

The biggest challenge railway providers face today is digitization to increase operational efficiency. Issues like unscheduled downtimes or track repairs are very costly and have a strong impact on customer satisfaction. On top, railway providers constantly need to work on ensuring and improving passenger security. The problem behind these issues is that railway operators are often still lacking data when it comes to knowing what is happening on the tracks, in the tunnels and trains.

This case study looks at how Kapsch and ObjectBox collaborated on a Kapsch Industrial Internet of Things (IIoT) edge solution for the railway industry. The project enables railway operators to optimize their operational efficiency and asset management via rapid processing of real time mission critical data, ensuring extremely reliable asset operations and timely decision-making.

Kapsch

Founded in 1892, today this family-owned company headquartered in Vienna is a globally-operating technology group with offices and subsidiaries on all continents. The Kapsch Group focuses on peoples’ requirements in the fields of communication and mobility. With innovative products and solutions, Kapsch BusinessCom and Kapsch TrafficCom make a significant contribution to the digital transformation and a sustainable future in public and private transportation.

ObjectBox

ObjectBox makes real time data consistently accessible from sensor to server – including sensors (client), Android and iOS devices, IoT gateways, on-premise and cloud servers. ObjectBox is 10 times faster than any alternative, smaller than 1 MB and uniquely designed for IoT and Mobile settings.

Kapsch and ObjectBox

Kapsch is a longtime partner of railway operators and is thus helping the industry with digitization. By integrating ObjectBox’ database and synchronization solution into the Kapsch railway offering, Kapsch can provide superior speed and data continuity to their railway customers. This means critical data is available when needed and can be interacted with in real-time. This heightens operational efficiency and passenger security, because speed matters in that environment. It also decreases networking costs significantly. Last not least, keeping data locally as much as possible increases data security.

The challenge: Having data up to date – fast, reliably, across devices

As a long-term partner of railway providers across the world, Kapsch addresses their major pain points with its new IIoT solution. Central to optimizing railway providers’ operational efficiency and security is having real-time information about tracks and trains available when needed where needed.

Project requirements at a glance:

    • Performance and operation on all kinds of platforms from sensor to IoT gateway to server to iOS and Android devices
    • Reliable data synchronization between devices
    • Fast (near real-time) and network-connection-independent operation on all devices, meaning on the edge. Therefore, a superfast database across entities is required.
    • Possibility of opening the APIs for external developer projects in the future.

What we developed in the course of our digitalization initiative, was an end to end solution for IIoT, and with this we have an edge computing solution. We were looking for possible partners and one of them was ObjectBox. When we saw their synchronization methodology, we understood it was a perfect fit.

Jochen Nowotny

Vice President of Product Management, R&D, Delivery & Support, Kapsch

The project environment

Developed in a co-creation process with railway operators, the Kapsch IIoT-solution is uniquely tailored to the main needs and challenges of the railway industry: Passenger experience, operational efficiency and safety / security.

The Kapsch railway cross-platform solution applies mission-critical data to avoid costly downtimes and repairs, reducing maintenance times and delays. Thus, timetables can be kept more accurately up-to-date, making travelling a better experience for end users.

At the core of the solution lies the Kapsch mission-critical network. Another essential part of this solution is the storage, processing and delivery of data, so data is accessible where it is needed, when it is needed. Doing this efficiently provides a competitive edge to railway operators. Having the data needed to make decisions in real time – across any part of the railway network – improves operational management and the experience for both employees and customers.

ObjectBox’ solution

This is where ObjectBox comes in. ObjectBox offers a fast data storage and synchronization solution that works seamlessly across devices, from sensors to mobile (iOS and Android) to server to cloud. Because of its out-of-the-box synchronization solution, it also saves time to market and costs. On top, ObjectBox’ easy APIs could easily be extended to external developers. Therefore, Kapsch decided to implement and benchmark the startup’s solution.

 

How did Kapsch find ObjectBox’ solution?

Sourcing new innovative approaches is like finding a needle in the haystack. That is why Kapsch runs the later stage accelerator program Factory1. Factory1 focuses on piloting startup solutions at Kapsch. In a rigorous process, Kapsch’ top management and experts from around the world assess startups and define pilot projects together with them. In the final evaluation step, the startups pitch these pilots to the Kapsch board. After going through this thorough process, ObjectBox convinced the board of their solution’s great potential and usefulness for Kapsch.

The solution: A unique hardware/software stack with out-of-the-box synchronization

While the rigorous sourcing process already ensured a good paper and personal fit, in software projects it always comes down to the nitty-gritty details of the technology stack.

Working together – from technology fit to project-setup

The Kapsch project was developed mainly in Java for the operating systems centOS, Android and iOS. ObjectBox supports all platforms and languages used.

So the first step was to integrate the ObjectBox database for storing data, which meant replacing the persistence layer with ObjectBox. When exchanging a database (the data persistence layer) in an existing project, four cases can be distinguished:

SQL database with abstraction layerNoSQL database with abstraction layer
SQL database without abstraction layerNoSQL database without abstraction layer

In this project, a NoSQL database with an abstraction layer needed to be exchanged.

The second step was to synchronize data between IoT edge gateways and central servers.

Each IoT edge gateway (located along the tracks and in the trains) collects local sensor data and makes it accessible to local devices like smartphones, as well as centralized locations (e.g. on the headquarter’s servers). This setup allows high speed operations independent of the availability and quality of network connections.

This is not a simple case of “sending data one way” or “full replication”, rather a more sophisticated technology referred to as “data synchronization”. It is transactionally safe (aka ACID compliant), meaning no data is lost in transit. The network and gateway can go down any time – once everything is up again, data is safely transmitted. This data synchronization is a built-in feature of ObjectBox and therefore does not require any additional, costly software development efforts from Kapsch.

The third step was to compare ObjectBox to alternatives. Therefore, KPIs were defined and a benchmarking application was set up. The KPIs used in this evaluation were: internal project goals, ease of use, the performance of the database, the speed and efficiency of synchronization, and data consistency across devices.

Pilot project results

Together, ObjectBox and Kapsch achieved their goals and created a solution that adds a competitive edge.

“ObjectBox integration in our IIoT solution has enabled significant performances improvement … far beyond other databases. More, we’ve learn a lot on how to operate efficiently a database from the collaboration with ObjectBox team.”

Farid Bazizi

Head of R&D Development - Mission Critical Communication & Industrial IoT Technologies, Kapsch

Overall goals

More specifically, the following goals were met in the 3 month project:

  • There was a successful integration of the ObjectBox database, demonstrating how fast and easy it can be implemented. Because ObjectBox is flexible and easy to use, it can help ensure that will be usable and maintainable for 10+ years.
  • The performance benchmarks done in the project clearly showed that ObjectBox outperformed the alternative solution, which was based on Couchbase, with regards to speed (CRUD operations), as well as CPU and memory (RAM) usage.
  • Last but not least, ObjectBox Synchronization proved to be easy to implement, transferring data seamlessly and reliably between devices. Benchmarked against the existing solution, measurements showed that ObjectBox synchronized the data 61 to 94 times faster.

Benchmarks

Please note, the benchmarks done here are project-specific. The benchmarks simply compare the internal existing Kapsch implementation, which is based on Couchbase, to the ObjectBox implementation. Thus, they should be read as project-specific results only.

Database Performance (CRUD), higher is better

ObjectBox is faster on all basic database operations within this project. This means you can process more data faster, and run more complex applications, like artificial intelligence or machine learning applications on the device – and respond to incidents faster, before it gets costly or dangerous.

 

CPU & Memory Usage, lower is better

All hardware comes with limited CPU and memory resources. These resources are shared between all the apps running on the device. The less CPU and memory that the data storage solution and sync uses, the more is left for other uses.

This means it is possible to:

  • install smaller (and often cheaper) hardware
  • run more applications and do more complex computing (e.g. edge AI) on the existing hardware, allowing you to capitalize on existing infrastructure.

Both are huge cost factors in the project settings.

Synchronization speed

ObjectBox’ synchronization implementation was much faster than the alternative, processing 37,629 objects in one second, as compared to the 400 synchronized by the alternative. In practice this means that in the given setup, ObjectBox supports 10 times more clients (nodes) for every server. This translates to huge cost savings on hardware as servers are expensive and only one server is now required where before 10 were needed.

Startup-Corporate Collaboration: A win-win situation

As this case study shows, it pays off for projects to evaluate solutions independent from their provider’s company maturity level.

On the journey, both companies learned and benefited from each other’s expertise. Apart from solving the concrete technological challenges, the project yielded further positive side effects. Sebastian Opitz, Head of Controlling and ObjectBox’ project mentor, gives an example: “ObjectBox helped to quickly identify a faster way forward with a new technical solution. It would have taken us much longer doing it on our own and probably only would have been discovered much later.”

From the startup perspective, the collaboration gave ObjectBox access to new departments and new markets. “Kapsch has a deep market knowledge and a lot of experience with digitization projects. This experience helped ObjectBox to reach the next level”, concludes Vivien Dollinger, ObjectBox CEO.

ObjectBox on Azure Sphere: Efficient IoT data persistence

ObjectBox on Azure Sphere: Efficient IoT data persistence

Listening to our IoT users, we implemented ObjectBox support for Microsoft’s Azure Sphere. With this extension, you can use ObjectBox on tiny devices now. But let us explain a bit more…

What is Edge computing?

Centralized computing entails a central computer storing and processing all data with multiple machines (clients) accessing it. Decentralized computing has no central instance and data is stored and processed on the machine it is used on. The currently predominant computing paradigm, namely cloud computing, is centralized.

The Internet of Things (IoT) is pushing the industry once again towards a distributed computing paradigm. In this context it is called Edge computing. Edge Computing aims to store and process data on end devices (so called edge devices or nodes) like smartphones, routers, and the IoT end devices. We view Edge Computing as an extension of the cloud, adding value and functionality on the edge of the network. 

Note: Fog Computing and Edge Computing definitions vary and overlap widely. This is just the definition we use.

What is the Azure Sphere?

The Azure Sphere is foremost an operating system for “small chips”, or more exactly, Internet-connected microcontroller units (MCUs). It was developed by Microsoft for Internet of Things (IoT) applications and comes with integrated cloud security services. As of today, it runs on a MT3620 MCU produced by MediaTek in collaboration with Microsoft.

Microsoft Azure, Microsoft’s cloud solution is closely related to the Azure Sphere. Security and user management, configuration and deployment can be analyzed and modified using that web interface.

ObjectBox on Azure Sphere 

There were a couple of reasons why we at ObjectBox support Azure Sphere:

Furthermore, we looked at the lifetime costs: Firstly, we chose Azure Sphere, because it can save maintenance costs. Secondly, because there is one unified interface to the platform, the platform itself may be used for any task imaginable (e.g. facility management, real time inventory, etc.). Thirdly, Microsoft’s security solution provides Over-the-air (OTA) updates. Therefore, it takes care of keeping the operating system up to date for you.

Azure Sphere use cases

These use cases exemplify a key consequence of using the Internet of Things in everyday devices: they may not only read and analyze sensor data, but also control the machine they are attached to, even autonomously. In connection with intelligent algorithms, these devices are able to make far-reaching decisions and thus maximize overall efficiency.

Benefits of ObjectBox on Azure Sphere

ObjectBox can greatly simplify the process of data collection, transmission, and processing. Let’s now see how ObjectBox is able to solve common problems encountered when integrating IoT into any kind of environment.

Let’s now see how ObjectBox is able to solve common problems encountered when integrating IoT into any kind of environment.

Scalability, i.e. integrating new devices into a fleet of existing ones, can be challenging because of the gigantic amount of data it generates and that must be transferred to a high-level entity. ObjectBox’s speed advantage provides a solution to this. Confirmed by 3rd party reviewers, ObjectBox outperforms alternatives in all areas. Thus, it offers higher rates for data transmission, storage and retrieval.

ObjectBox is created from developers for developers. Because ObjectBox’s programming interfaces are exceptionally easy to use, development time can be minimized and first prototypes can be delivered after a very short time.

Additionally, it is necessary to make sure data is always up-to-date and prevent unintentionally storing redundant or meaningless data. Our synchronization feature, coming up soon, will solve that out-of-the-box for you.

Find the full technical description and download on GitHub.

Let us know what you think

Last not least, we are always happy to hear from you. Post any questions you may have on stack overflow tagged ObjectBox. Please share your thoughts on ObjectBox on Azure Sphere with us via Twitter, Facebook, or Mail (contact [at] objectbox . io).

What are the benefits of Edge Computing?

What are the benefits of Edge Computing?

The benefits of edge computing stem directly from the underlying paradigm: Edge Computing is a decentralized computing architecture as opposed to a centralized/cloud computing model. 

 

Benefits of Edge Computing put simply

  • Data ownership / privacy: Data can stay where it belongs – and is produced and used (on the edge devices)
  • Security: Data on edge devices that is not transferred to the cloud is much more difficult to hack
  • Cloud costs: Cloud data volumes and costs can be significantly reduced
  • Rate of data transfer: Less need for bandwidth
  • Speed: Processing on the device instead of sending to the cloud and waiting for an answer is way faster (latency)
  • Offline-capability: Edge devices can operate independent from a network / cloud connection
  • Real-time communication on the edge: Edge devices can communicate between each other directly, which can be done much faster due to the short distances and also more efficient as the power and information of several devices can be combined (for more info see: ultra low latency networks, peer-2-peer, M2M actions)
EdgeX Interview: Why open source is key for IoT and Edge Computing

EdgeX Interview: Why open source is key for IoT and Edge Computing

We were thrilled to speak with Michael Hall, Brett Preston (the Linux foundation) and Jim White (Dell) about their open source platform EdgeX.

Jim White

Jim White

Dell, EdgeX

Jim is Vice Chair of the Technical Steering Committee of EdgeX. He is also Team Lead of the IoT Platform Development and IoT Solutions Division at Dell.

Michael Hall

Michael Hall

The Linux Foundation for EdgeX Foundry

Michael is Developer Advocate and Community Manager at the Linux Foundation.

 

Brett Preston

Brett Preston

The Linux Foundation for EdgeX Foundry

Brett is Developer Advocate and Community Manager at The Linux Foundation for EdgeX Foundry.

 

Vivien: What is EdgeX and where are you at with it?

Michael: EdgeX Foundry is a vendor neutral open source platform containing a collection of micro services that take care of different aspects of what you’re going to need to have an edge computing platform. If you’re making IoT devices, you don’t want to reinvent that layer of the stack. Having that common platform for IoT is something that is going to benefit everybody. The Linux Foundation is a neutral umbrella over EdgeX. Inside the project are all the member companies who are actually funding the development, putting developers and marketing resources in, to make it an actual, usable product for everybody. That’s the model of the project and the actual code itself. The main goal of EdgeX is processing and transporting data between IoT devices and sensors and things in the cloud and on the backend. The focus is on being able to respond locally as much as you can, so that you don’t have the latency of going on the cloud and back. And also, being able to continue working, if you loose that connection.

Jim: EdgeX is a an open source platform containing a collection of micro services that take care of different aspects of what you’re gonna have to do to have an edge computing platform. Any of those are semi-dependent: You can replace anything you need to replace. For the status of the project: We just had a year of fast pace growth and we have rewritten everything in Go, so all of our processes are a lot smaller and more efficient now.

Vivien: How are you currently tackling local on-device data persistence?

Jim: We currently use Mongo DB as the persistence engine although we could support almost any kind of persistence store at the edge as long as it was small enough. We also have used SQLite in the past for a couple of customers. However, Mongo DB is the largest element in our portfolio of services. There are a couple of reasons why we are probably going to offer an alternative to Mongo with our next big release in spring 2019: Footprint, licensing, and lack of support for ARM32.

Michael: As we are a collection of microservices, you can always swap out individual pieces depending on what your needs are.

Vivien: Is EdgeX and its components restricted to certain licenses?

EdgeX builds on Apache 2

Jim: EdgeX is an Apache 2 license open source project, so we prefer Apache 2 level or at least a compatible license, because we want to be very business friendly. We want people to take the application and use it in all sort of settings, including actually embeddeding it in gateways. We also want to be very decoupled at discrete points.

For example, if I’m a company like Dell and I use EdgeX. If some of my customers have an absolute demand that a certain database be at the heart, then I want to be able to choose the database, depending upon the customers, the use cases, and the environment that they find themselves in. EdgeX is all about the flexibility. So, for this example, we offer what we call a reference implementation database. Customers or users could take EdgeX and replace elements with their own technology, which may not be open source even.

Michael: You can take what’s open source and add proprietary file systems or hardware depending on what your specific needs are. EdgeX tries to be that common open source base. It provides all of the functionality in a open source license but that still lets you replace bits as needed with whatever it is that you want to run.

Vivien: Can you give us an example how and where EdgeX is currently used? 

Jim: There are over 70 companies now that are part of the EdgeX community and each group is using it differently. There are some that are serving EdgeX as the Red Hat model: they are providing distribution, services and support behind EdgeX. A company like mine, Dell, we’re trying to find a platform that actually goes on our gateway. So we’re going to build a commercial version of EdgeX for our own platform. There will be pieces that we will replace based on better performing mechanism to some of our cloud based products. Then you have other groups out there that are proving particular services for EdgeX, for example edge analytics. There are lots of different service capabilities where we see potential replacements. Then there are companies like Samsung that uses EdgeX in their factory floor to help run their automation. So, they are users, but they also want to make sure  EdgeX meets their needs. Our community is made of snowflakes, they are all very special *laughs* – common goals but different use cases for almost everybody that is part of the organization.

 

Vivien: That sounds really cool. In your opinion, moving the data to the edge, what is the edge, where do you see the data ending up, for example more on the sensor level or gateway level?

Latency concerns, cost of shipping up the data, and the ability to actuate locally are key reasons why you have to have edge software.

Jim White

Vice Chair of the Technical Steering Committee, EdgeX

Jim: We absolutely believe EdgeX is a mechanism for the edge. While you could run pieces of EdgeX on the cloud, we do not believe is what the future holds. There are gonna be certain use cases where that works, but latency concerns, the cost of shipping up the data, and the ability to actuate locally are all key ingredients and reasons why you have to have edge software and edge platforms. Now, these are gonna get smaller. At Dell, we are manufacturing gateways of different sizes, because we know that certain use cases are gonna dictate a larger box and other are going to dictate something like a Raspberry Pi or even smaller. We have companies in our foundry that are looking at running parts of EdgeX in things like PLCs, to help address their realtime needs. So, we absolutely believe that the edge is very much going to be a part of our IoT environments. There are going to be use cases that dictate different levels of compute all the way up from sensors to cloud.

 

Michael: And all of our member companies see a need for that platform, but that platform is not going to be their product or their service. So everybody wants it to exist, so everybody is gonna work together to make it exist, so that they can build their own value-add on top of that or below their device level. Everyone agrees that this is an important thing, that we have to have a solution there for all the innovation that people see on the horizon.

Markus: So, small device level versus gateway – would you say your current focus is on the gateway?

Levels of Edge Computing

Jim: I would say that it really isn’t that one or the other is more important. You’re gonna have situations, as we know from a Dell perspective, where what we call a brownfield device (e.g. a 1979 modbus engine) needs a gateway, because it doesn’t have the ability to communicate into any kind network otherwise. So there has to be a gateway that provides that first level of compute. There are other things that are evolving in the industry: think of say windmill generators, where there is lots of capability right there at the device level, there is a lot of compute built right into those systems. So things will run at that level, and then you have everything in between. Even something like BLE or Zigbee type of environments where there is wifi and ability to connect directly to a network. Typically, we’re finding organizations are reluctant to allow those kind of things to connect into their major networks without some security, apparatus and analytics to see what’s going on, so as not to create problems in their larger networks. So even there, a gateway may be necessary, not because of hardwiring or physical connections, but because you want some insurances in place at the edge before that data leaks on up to your enterprise.

It’s the worst way to build our product except for all others.

Jim White

Vice Chair of the Technical Steering Committee, EdgeX

Vivien: What’s the worse about open source that you’ve experienced?

Jim: *laughs* Now you are going to make me say some things in front of Brett and Michael as members of the Linux foundation… There is a quote by Winston Churchill that talks about democracy, saying it’s the worst form of government except all others. I kind of feel the same way about open source development. It’s the worst way to build our product except for all others. Because it does take time. It’s a community effort and anything done by a community automatically seeks a ground where it’s going to be the best and brightest product. So you get the best input from everybody, but it takes time. It’s easier for say something like Dell to go marching off and build a software solution that they think is the best. It will get there faster but it’s not necessarily going to get there in a way that the world and communities accept more easily. So anything built by many hands is going to take a little bit more time and a little bit more process. But it ends up getting a lot better results I think in the end.

Michael: Whenever you have a community building something you can’t just come in and say “This is what you’re gonna build” because they don’t have to do what you say. And that’s true even with EdgeX. Everybody who is working on it is working for a company invested in it, but there is no one person who can say this is what you’re all going to do. So it’s not enough to say just what you want done. You have to explain and justify why and get people to buy into that. And that takes more effort, but you have to know that what you’re proposing is the right solution, that it’s going to work. If you can’t explain that, you can’t communicate that to the community then it’s not going to get done. As Jim said, it takes time but at the end product is going to be better.

Jim: In this case with IoT, I will tell you that no one company will be able to provide it all. As Dell, we would love to be the company providing it all… (laughter) We have learnt the hard way that in an IoT landscape there are going to be certain things in the company that you can’t touch and IoT has to touch everything. Maybe it’s the network, hardware or operating systems, particular sensors and protocols. You can help to persuade customers to do some things in your way, but you’re never going to be able to get them to do everything in your way and that’s why IoT takes an ecosystem. Which is why we think the second part of EdgeX is so important; our product is important, but just as vital is the ecosystems. We have a collection of companies all trying to work together to provide for interoperability. That is just as important as the actual end product we develop.

No one company will be able to provide it all.

Jim White

Vice Chair of the Technical Steering Committee, EdgeX

Vendor lock-in is not going to work in IoT.

Michael Hall

Developer Advocate, Linux Foundation

Michael: Vendor lock-in is not going to work in IoT. There is no way any company is gonna be able to provide all the needs of somebody. So having an equal playing field for everybody, having that common ground that anybody can come to and interact with anybody else, is what’s going to allow us to fulfill the promise of IoT in general.

P.S. You can meet Brett, Michael, and Jim at the Open IoT Summit Europe in Edinburgh in October.

Please help us learn more about the data persistence landscape on the edge by filling out our small questionnaire (literally 2 minutes). Thanks!

ObjectBox 1.0

ObjectBox 1.0

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!

A big thank you goes out to everyone who helped us in our beta phase (e.g. reported GitHub issues, blogs, …). It was only with your help that we reached version 1.0 now! As a special sign of appreciation, we’ll send out exclusive “early adopter” ObjectBox T-shirt: just write to us (contact@… – our domain) by September, 15th, with a link to your contribution along with your size and address.

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!