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!
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.
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.
All listed databases are open source.
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
Notes On Table Columns
Indicates whether the database is SQLite or NoSQL.
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.
Here we list the database’s ability to support multiple concurrent transactions.
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.
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.
If you have feedback on this summary or have a suggestion for a feature to include, please let us know on twitter @powersync_ .