Demystifying Flutter's Local Database Options: A Comprehensive Summary

Since we couldn’t find any easy to understand and up-to-date summary of local database options for Flutter, we created one ourselves. The table below shows the main options available with key features that should help you decide which local database will work best for you. Feedback and suggestions welcome!

Notes

Full database functionality

This summary includes only local database options that provide full database functionality (persistent, consistent and queryable data stores). We’ve ignored overly simplistic databases or caches. For example, we haven’t included shared_preferences or hive because they’re built for basic key-value storage.

Standalone

We’ve also only included local databases that can be implemented standalone. For example, since Firebase’s local data store can only be used in conjunction with the Firebase backend-as-a-service offering, it has not been included.

Open source

All listed databases are open source.

‍Cross-platform

All listed databases can support iOS, Android, MacOS, Windows and Linux. Web support is noted separately in the table.

‍

Summary Table of Flutter Local Databases

Database / Package	Description	Type	Performance Category	Asynchronous by Default?	Concurrency	Encryption Support	Web Support	Query Method	Plug-in Cloud Sync Support?	Backend Database Type
SQLite – sqflite	The original SQLite integration for Flutter, using a plugin package.	SQLite	Limited optimization possibilities	Yes	Single transaction at a time	Yes (via SQLCipher)	Experimental	SQL	No	-
SQLite – sqlite3	Low-level library exposing SQLite C APIs to Dart code using an FFI plugin package.	SQLite	Requires manual optimization	No - requires additional work to run in background Isolates	No built-in support, but can run operations on background isolates with extra work	Yes (via SQLCipher)	Experimental	SQL	No	-
SQLite – sqlite_async	Modified sqlite3 to add performance optimizations and asynchronous calls by default.	SQLite	High-performance	Yes	Built-in support for one write transaction and multiple read transactions concurrently	Yes (via SQLCipher)	No (experimental support can be added similar to sqlite3)	SQL	Yes, when used as part of PowerSync	SQL
Floor	SQLite ORM built on top of the sqflite library and inspired by Android’s Room persistence library.	SQLite	Limited optimization possibilities	Yes	Single transaction at a time	Yes (via SQLCipher)	No	SQL	No	-
Drift	SQLite ORM built on top of the sqlite3 library (by the same author).	SQLite	High-performance	Yes	Connection pool can be used for one write transaction and multiple read transactions concurrently	Yes (via SQLCipher)	Experimental	ORM but with “SQL parsing” capabilities	No	-
Isar	NoSQL database made for Flutter (written by hive author with the intention to supersede hive).	NoSQL	High-performance	Yes (has equivalent synchronous and asynchronous APIs for most operations)	Built-in support for one write transaction and multiple read transactions concurrently	Yes	Full support seems to be in the works. See open issue and documented limitations.	Domain-specific	No	-
Sembast	NoSQL database made for Flutter “for single process io applications”.	NoSQL	Unknown	Yes	Unknown	Yes	Yes, through a separate package	Domain-specific	No	-
Mimir	NoSQL database made for Flutter with heavy-weight full-text search capabilities thanks to Meilisearch.	NoSQL	Unknown	Yes	Unknown	Yes	No	Domain-specific	No	-
Realm	NoSQL “mobile database” acquired by MongoDB.	NoSQL	High-performance	No, but has partial async support	Support for concurrent transactions when using separate Isolates	Yes	No	Domain-specific	Yes through MongoDB Atlas Device Sync	Hosted MongoDB Atlas (NoSQL)
ObjectBox	NoSQL “edge database” seemingly built with IoT use cases in mind including sync to self-hosted sync server.	NoSQL	High-performance	No, but makes asynchronous operations easy from version 2.0	Built-in support for one write transaction and multiple read transactions concurrently	No	No	Domain-specific	Yes, to self-hosted ObjectBox Sync Server	Self-hosted ObjectBox Sync Server (NoSQL)
Moor	Renamed to Drift

Notes On Table Columns

Type

Indicates whether the database is SQLite or NoSQL.

Performance Category

Once a database has been optimized for performance, it will generally meet high performance standards (see our separate post on comparing database performance that partly led us to this conclusion). For this reason, databases have been grouped into one of three performance categories:

Limited optimization possibilities (for example sqflite which cannot provide access to low-level high-performance SQLite APIs because it is not an FFI package).
Requires manual optimization (where optimization is possible but must be done manually by the developer themselves).
High-performance (where the database is set up to be highly performant by default).

Asynchronous by Default

This indicates whether the database supports asynchronous operations; in other words, whether there is multi-isolate support that prevents the main isolate from being blocked.

Concurrency

Here we list the database’s ability to support multiple concurrent transactions.

Web Support

Here most SQLite are listed as experimental as their web support is based on SQLite’s WebAssembly implementation which is not yet broadly supported by web browsers.

Query Method

Here the query methods are "SQL" or "ORM" for SQLite-based databases and "domain-specific" for NoSQL databases since they each have their own query flavor.

Plug-In Cloud Sync Support

This refers to the database’s ability to plug into an existing sync system that keeps data in sync with a primary cloud database and across devices.

Backend Database Type

This indicates the cloud database type that the cloud sync solution supports.

‍

Feedback

If you have feedback on this summary or have a suggestion for a feature to include, please let us know on twitter @powersync_ .