UPDATED 2024
A long time ago at Droidcon Berlin, we noticed a lot of questions around databases. Many people weren’t aware of SQLite alternatives and the differentiation between databases and Object-Relational Mappers (ORMs). Therefore, we followed up with an overview of the local database landscape (Edge Databases / On-device Databases), which we maintain ever since. We just updated the comparison table in May 2024.
Why use a local database on Mobile?
There are some advantages associated with using a local database (Edge Database):
- It always works: full offline modus for apps that depend on stored data
- Manageable costs: Frugal on bandwidth and cloud costs as most data can reside on the phone
- Speed: fast and predictable performance independent from network availability
- Data Privacy: personal data can be stored with the user, where some say they belong)
Do people still use SQLite in 2024?
In 2024, SQLite is still a widely used database. On DB-Engines, SQLite is currently in the top 10 and its ranking has been rather stable in the last 10 years.
However, with SQLite being over 20 years old, the market has changed significantly and a large number of more modern solutions, more suitable for new markets like IoT and Mobile, have become available. One has a lot more and typically faster options when choosing a local Edge Database nowadays.
Note: DB-Engines lists 420 databases as of 2024; the database of databases, which also includes hobby projects, counts 990 databases. While the database market is very crowded and indeed vibrant, the Edge Database market is still a small market with only few notable players. In short: In the realm of Edge Databases, despite such a dominant incumbent like SQLite, there is still room for innovation and advancement. With the advancement of LLMs and subsequently a boost in AI applications, vector databases have become the focus of attention and the market has seen massive fundings.
What are the advantages and disadvantages of working with SQLite?
The most established mobile database – one could even say the only “established” – mobile database is SQLite. This may be due to SQLite being around since the year 2000 and being embedded with iOS and Android since the beginning. SQLite is a relational database.
In our previous post, we presented advantages and disadvantages of using raw SQLite without any tools as we had gathered them with a group of developers. Based on this, we generated a more generic overview of advantages and disadvantages of using raw SQLite:
Advantages:
- Toolchain, e.g. DB browser
- No dependencies, is included with Android and iOS
- Developers can define exactly the data schema they want
- Developers have full control, e.g. handwritten SQL queries
- SQL is a powerful and established query language, and SQLite supports most of it
- Debuggable data: developers can grab the database file and analyze it
- Rock-solid, widely used technology, established since the year 2000
Disadvantages:
- Using SQLite means a lot of boilerplate code and thus inefficiencies (also in the long run with the app maintenance)
- 1 MB BLOB Limitation on Android
- No compile time checks (e.g. SQL queries)
- The performance of SQLite is unreliable
- SQL is another language to master
- SQL queries can get long and complicated
- Testability (how to mock a database?)
- Especially when database views are involved, maintainability may suffer with SQLite
What are SQLite alternatives?
If you want to replace SQLite completely, there are also quite a few alternative databases: Couchbase Lite, Interbase, ObjectBox, LevelDB, Oracle Berkeley DB (formerly Oracle’s mobile database was “Oracle Database Lite”), Realm, SnappyDB, Sparksee Mobile (graph database, brand-new at the time of this article), SQL Anywhere, SQL Server Compact (discontinued), and UnQLite.
Object-Relational Mappers (ORMs) are not really SQLite alternatives, but a layer that sits on top of SQLite and makes it easier to use (object/relational mapping). So, if you simply find it unpleasant to write a lot of SQL and boilerplate code, you can use an object abstraction on top of SQLite, e.g. greenDAO.
To give you an overview, we have compiled a comprehensive comparison table (if you’re on mobile, view the full table here):
| Edge Database | Short description | License / business model | Android / iOS* | Type of data stored | Central Data Sync | P2P Data Sync | Offline Sync (Edge) | Data level encryption | Flutter / Dart support | Vector Database (AI support) | Minimum Footprint size | Company | ||
| Azure SQL Edge | Designed as a SQL database for the IoT edge; however, due to the footprint it is no Edge Database | Proprietary | No | Relational DB for IoT | No | No | No | will provide encryption | No | No (no on-device vector database, but you can use the cloud) | 500 MB+ | Microsoft | ||
| Couchbase Mobile / Lite | Embedded / portable database with P2P; pricing upon request; some restrictions apply for the free version | Partly proprietary, partly open-source, Couchbase Lite is BSL 1.1 | Android / iOS | JSON Documents / NoSQL db | Yes | Yes | No | Database encryption with SQLCipher (256-bit AES) | Unofficial Flutter plugin for Couchbase Lite Community Edition | No | < 3,5 MB | Couchbase | ||
| extremeDB | Embedded relational database | Proprietary | iOS | In-memory relational DB, hybrid persistence | No | No | No | AES encryption | No | No | < 1 MB | McObject LLC | ||
| InterBase ToGo / IBLite | Embeddable SQL database | Proprietary | Android / iOS | Relational | No | No | No | 256 bit AES strength encryption | No | No | < 1 MB | Embarcadero | ||
| LevelDB | Portable lightweight key-value store, NoSQL, no index support; benchmarks from 2011 have been removed unfortunately | New BSD | Android / iOS | Key-value pairs / NoSQL db | No | No | No | No | Unofficial client that is very badly rated | No | < 1 MB | LevelDB Team | ||
| LiteDB | A .Net embedded NoSQL database | MIT license | Android / iOS (with Xamarin only) | NoSQL document store, fully wirtten in .Net | No | No | No | Salted AES | No | No | < 1 MB | LiteDB team | ||
| Mongo Realm / Realm DB (acquired by Mongo in 2019) | Embedded object database | SSPL | Android / iOS | Object Database | Yes (Mongo Atlas), tied to using Mongo DB | No | No | Yes | Officially released a Flutter binding in spring 2023 (See Flutter databases) | No | 5 MB+ | MongoDB Inc. | ||
| ObjectBox | NoSQL Edge Database and on-device vector database with out-of-the-box Data Sync for Mobile and IoT; benchmarks available as open source | Open Core (plus Apache 2.0 bindings) | Android / iOS / Linux / Windows / any POSIX | Object-oriented NoSQL edge database for high-performance on edge devices in Mobile and IoT | Yes | WIP | Yes | transport encryption; additional encryption upon request | Yes | First local vector database fo on-device Edge AI released May 2024 | < 1 MB | ObjectBox | ||
| Oracle Database Lite | Portable with P2P and central sync support as well as support for sync with SQLite | Proprietary | Android / iOS | Relational | Yes | Yes | No | 128-bit AES Standard encrytion | No | No | < 1 MB | Oracle Corporation | ||
| redis DB | High-performance in-memory Key Value store with optional durability | Three clause BSD license, RSAL and Proprietary | No | K/V in-memory store, typically used as cache | No | No | No | TLS/SSL-based encryption can be enabled for data in motion. | Unofficial redis Dart client available | No on-device vector database, but you can use the cloud | An empty instance uses ~ 3MB of memory | redislabs (the original author of redis left in 2020) | ||
| SQL Anywhere | Embedded / portable database with central snyc support with a stationary database, pricing now available here | Proprietary | Android / iOS | Relational | Yes, tied to using other SAP tech though (we believe) | No | No | AES-FIPS cipher encryption for full database or selected tables | No | No | SAP (originally Sybase) | |||
| SQLite | C programming library; high market share in the small devices space | Public domain | embedded on iOS and Android | Relational | No | No | No | No, but option to use SQLCipher to encrypt SQLite | Flutter plugins (ORMs) for SQLite, but nothing from Hwaci | No, but various early & unofficial extensions are available | < 1 MB | Hwaci | ||
| UnQLite | Portable lightweight embedded db; self-contained C library without dependency. | 2-Clause BSD | Android / iOS | Key-value pairs / JSON store / NoSQL db | No | No | No | 128-bit or 256-bit AES standard encryption | No | No | ~ 1.5 MB | Symisc systems |
What about NoSQL on Mobile?
NoSQL is a rather large bracket for database approaches that use a data structure that is non-relational. Indeed, NoSQL databases include key-value stores, document databases, wide-column stores, object databases, and graph databases. Generally, NoSQL is associated with scalability and performance. Although in some cases the speed of a NoSQL approach may come with less emphasis on reliable data storage (see ACID).
The general traits of NoSQL approaches that make it worthy for evaluation for mobile:
1. Object-oriented code in iOS and Android Apps
Developers implement apps in object-oriented languages, meaning an app works with objects. But a relational database works with columns and rows and does not allow storing objects directly. Consequently, objects need to be serialized or reassembled in possibly inefficient ways when stored or retrieved. For any database operation this takes time and imposes a natural speed limitation. The right NoSQL approach, e.g. an object database/store, may solve it without complex mappings.
2. Dynamic requirements of Mobile Apps
After the release of a mobile app, there is often an ongoing live operation process to continually adapt and enhance the app (bug fixes, new features, changes due to changes in the software or legal environment). Implementing changes in a mobile app with a relational client database requires changes to the database schema, which results in additional work. NoSQL databases usually operate without a schema (usually with some enforcing data validation rules). Adding new fields as needed and storing dissimilar data together as necessary means minimal implementing effort for the database. However, again it all depends on the specific database implementation and use case.
3. Growing need for handling lots of structured and unstructured data on Mobile
There seems to be the need for handling more and more data (roughly speaking, the amount of data is doubling every 24 months) generally and on mobile. Obviously, on mobile the storage space is still a major concern, which usually omits simply storing every possible data point for potential use.
However, other criteria like size, battery-friendliness or security may be more important factors for choosing a mobile database. All in all, we hope, we provide a good general overview of the general status of mobile databases.
