Hive vs. Isar vs. SQLite: Choosing a Flutter Local Database in 2026

You open a Flutter project from 2023 to add one feature. flutter pub upgrade fails because the code generator you pinned back then will not resolve against the current analyzer. Or you start a fresh app, add isar because an older comparison post told you to, and then notice its last stable release on pub.dev is from April 2023.

That is the real choice in 2026. Picking a Flutter local database used to be a speed question: key-value lookups, indexed queries, or SQL. Speed still matters. But the first question now is simpler and more awkward: who is still shipping fixes for the package you are about to build your whole app on?

The two names most comparison posts lead with, Hive and Isar, have both stalled upstream. Neither is marked discontinued on pub.dev, and both still work in apps today. But as of October 2026 the original hive package has had no stable release since June 2022, and isar has had no stable release since April 2023. Both now have community forks that are shipping. This post covers which package is which, how the options compare once you filter for maintenance, and what moving off each one involves.

Why does this matter so much? In an offline-first app the local database is the source of truth, not a cache. Reads come from the device, writes land on the device first, and a background job syncs later. Our offline-first architecture blueprint for Flutter apps walks through the full pattern. The short version: every screen sits on top of this one dependency, so a stalled package becomes your problem the day a new Flutter, Dart or Xcode release stops it building.

Maintenance status of every Flutter local database worth considering

These are the packages people actually shortlist. Dates come from pub.dev and the projects' GitHub repositories, checked on October 2, 2026.

Package	Latest stable	Last stable release	Status	What to know
hive	2.2.3	June 30, 2022	Stalled, not marked discontinued	A 4.0.0 prerelease dates from August 2023. Last repository commit August 2023.
hive_ce	2.20.1	September 27, 2026	Active community fork	Describes itself as a continuation of Hive v2. Requires Dart 3.4 or later.
isar	3.1.0+1	April 25, 2023	Stalled, not marked discontinued	The v4 prerelease is flagged as not production-ready. The most recent commit (June 2025) added a privacy manifest.
isar_community	3.3.2	March 23, 2026	Active, bug-fix focused	Fork of the Isar v3 line. Repository commits as recent as September 2026. Web is not listed as a platform.
isar_plus	1.3.9	August 4, 2026	Active, single maintainer	A divergent fork. Its changelog points to an SQLite-based core.
drift	2.35.1	September 30, 2026	Active	Flutter Favorite, MIT licensed, runs on Android, iOS, Linux, macOS, Windows and web.
objectbox	5.3.2	May 20, 2026	Active, commercial vendor	A 6.0.0 preview is in progress. No web target. Sync is a paid feature.
sqflite	2.4.4	September 2026	Maintained, slow-moving	Android, iOS and macOS. Desktop through sqflite_common_ffi. Web is experimental.
realm	20.2.0	September 24, 2025	Deprecated by MongoDB	MongoDB announced the deprecation of the Realm SDKs and Atlas Device Sync in September 2024. Version 20.0.0 removed sync.

Stalled is not the same as broken

Stalled is the accurate word, and the distinction matters. Neither hive nor isar carries pub.dev's discontinued flag, and neither repository is archived. An app built on Hive 2.2.3 in 2022 still opens its boxes today.

The risk is not that your app stops working tomorrow. It is that the package stops keeping up with everything around it: new Dart versions, analyzer upgrades that break old code generators, new iOS privacy requirements, Android Gradle changes. When one of those breaks a stalled package, nobody upstream is going to fix it for you. We cannot tell you which release will be the one.

There is an awkward twist with Hive. Its own README still points readers to Isar if they need queries, multi-isolate support or relations. That advice made sense in 2022. In 2026 it sends you from one stalled project to another. The Isar README, for its part, is blunt about the newer line: "ISAR V4 IS NOT READY FOR PRODUCTION USE", and it tells production users to stay on version 3.

Hive and hive_ce: key-value storage with very little ceremony

Hive is a lightweight NoSQL store written in pure Dart. Data lives in boxes, and you read and write by key. Because there are no native dependencies, it runs on mobile, desktop and the web without platform setup.

That model fits a lot of offline-first work. A settings box, a box per record type, and a dedicated box acting as a pending sync queue: when the user loses signal, their actions stack up in the queue box, and a background worker drains it when they reconnect. This is also why a small app can ship with no server bill at all, which we cover in running a solopreneur app on local databases with zero backend costs.

What Hive does well:

• Fast reads by key. A regular Hive box keeps its values in memory once it is open, so a read by key does not touch disk. A LazyBox keeps only keys in memory and reads values from disk, which trades speed for memory.
• Low setup cost. Initialize, open a box, read and write. For primitive values and maps there is nothing else to configure.
• Built-in encryption. The original Hive README states boxes are encrypted using AES-256. The hive_ce package page lists strong encryption as built in.

What the older comparison posts skip:

• Custom classes still need adapters. To store your own model objects you need a TypeAdapter per class, usually generated with build_runner. It is less ceremony than a SQL schema, but it is not zero.
• No query language. Filtering, sorting and joining mean loading records into Dart and using list methods. For settings, carts and small per-user datasets this is fine. For a large searchable catalog it becomes slow and memory-hungry, and you end up building indexes by hand.

hive_ce keeps the Hive v2 API and adds things the original never shipped: IsolatedHive for multi-isolate access, a DevTools inspector, automatic adapter generation, and Flutter web WASM support. Its README also claims large performance gains over Hive v4. Treat that as the maintainer's claim; we have not benchmarked it.

Isar and its forks: indexed queries with an uncertain future

Isar came from the same author as Hive and was meant to replace it. Instead of boxes, you define collections of objects with Dart annotations, and Isar generates the schema and query code. The feature list on the isar_community README is the same one that made Isar popular:

• Indexed queries with and(), or() and xor() groups
• Full-text search
• Watchers on collections, objects or queries, notified after a transaction commits
• Asynchronous, parallel queries with multi-isolate support

If you need every customer in one city with an overdue invoice, indexes are the difference between a query and a full scan. That is the job Isar was built for.

The costs are real. Code generation through build_runner is mandatory. And one claim from the earlier version of this post needs correcting: the Isar v3 line does not ship built-in encryption. Neither the original nor the isar_community README lists it. If you need data encrypted at rest with Isar, you are handling it yourself, field by field.

Then there is the maintenance question. If you choose Isar in 2026, you are really choosing between forks:

• isar_community is the conservative choice. Its README says it focuses on bug fixes and small updates for version 3, so your existing Isar code keeps its API. Web is not in its platform list.
• isar_plus is more ambitious, with one maintainer. Its changelog suggests a move to an SQLite-based engine with web support. Treat it as a different database with a familiar API, not a drop-in v3 replacement.

Either can be the right call. Both mean your storage layer depends on a small group of volunteers.

SQLite through drift or sqflite: the relational option that is still moving

SQLite is the filing cabinet: tables, rows, a declared schema. If your data is relational (customers, orders, invoices and line items that all reference each other) it is usually the safest model. In Flutter you reach it through sqflite (raw SQL) or drift (a type-safe layer with code generation).

What SQLite gives you:

• Data integrity. Foreign keys and ACID transactions mean a delete that fails halfway rolls back instead of leaving orphaned rows.
• Joins and aggregates. One query can combine and total data across several tables.
• Maturity. SQLite itself has been in production use for decades, and both Flutter wrappers are still maintained.

Drift is the strongest maintenance story on this list. It released 2.35.1 on September 30, 2026, is a Flutter Favorite, runs on all six Flutter platforms including web, and added FTS5 full-text search support in 2.35.0. Queries can be watched as streams, so the UI rebuilds when underlying rows change. For encryption, drift's documentation recommends SQLite3MultipleCiphers for new apps, with the encrypted_drift package (built on SQLCipher) as an alternative.

sqflite is stable and widely used, but slow-moving. It does not support concurrent read and write transactions, and outside Android, iOS and macOS you need sqflite_common_ffi.

The catch with SQLite is upfront work. You plan the schema, write migrations every time it changes, and either hand-write SQL with sqflite or learn drift's table classes and DAOs. There is also a mapping step from rows to Dart objects on every read. For simple reads by ID, an in-memory Hive box will usually feel quicker. As the data grows and the questions get harder, that gap closes or reverses. Measure with your own data before deciding on speed alone.

ObjectBox and Realm

ObjectBox is an object database from a commercial vendor. It is actively released, Apache-2.0 licensed, uses build_runner for code generation, and supports queries that filter across relations. It has no web target, and its sync product is a paid feature. If you want an object store with a company behind it and you only ship mobile and desktop, it belongs on the shortlist.

Realm is the one to avoid for new work. MongoDB announced the deprecation of Atlas Device Sync and the Realm SDKs in September 2024. The Flutter SDK's 20.0.0 release, also from September 2024, removed all sync functionality, and the last release was in September 2025. If you are on Realm today, plan a migration rather than waiting.

Feature comparison for the maintained options

	hive_ce	isar_community	drift	sqflite	objectbox
Data model	Key-value boxes	Object collections	Relational tables	Relational tables	Objects with relations
Queries	By key; filter in Dart	Indexed queries, full-text search, watchers	Full SQL, joins, FTS5, stream queries	Raw SQL	Queries, including across relations
Encryption	Built in	Not built in	SQLite3MultipleCiphers or encrypted_drift	Separate SQLCipher package	Check vendor docs
Web	Yes, including WASM	Not listed	Yes	Experimental	No
Code generation	For custom class adapters	Required	Required	None	Required
Setup cost	Lowest	Medium	Highest	Medium, hand-written SQL	Medium

Encryption deserves more thought than a table cell. A key stored next to the data it protects is not much protection, and where that key lives matters more than which cipher you picked. We cover key storage and threat modeling in securing local-first applications in Flutter.

A decision tree for 2026

Work down the list and stop at the first match.

1. Are you on Realm? Plan a move to drift or ObjectBox now. Deprecation was announced two years ago.
2. Does your app need to run on the web? Use drift. Use hive_ce instead if your data really is simple key-value.
3. Is your data relational? Orders with line items, invoices with payments, anything you would draw as linked tables: use drift.
4. Is it settings, caches, a sync queue, or modest per-user records you read by ID? Use hive_ce.
5. Do you need indexed object queries on mobile and desktop only? Use isar_community if you accept a bug-fix-only fork, or ObjectBox if you would rather have a vendor behind it. If neither appeals, drift does the same job with SQL.
6. Are you on original hive today? Move to hive_ce. It is the smallest migration on this page.
7. Are you on original isar today? Move to isar_community to stay buildable, then decide calmly whether drift is your long-term home.
8. Are you on sqflite and happy? Stay. Consider drift when you want type-safe queries and generated migrations.

Migration paths off stalled packages

From	To	Effort	What changes	What usually bites
hive	hive_ce	Low	Package names in pubspec.yaml and imports; hive_generator becomes hive_ce_generator; rerun build_runner	Other packages that still depend on hive transitively; stale generated adapters; cached CI builds
isar	isar_community	Low to medium	Swap the runtime and generator packages; same v3 API	Analyzer and source_gen constraint changes in the 3.3.x releases clashing with your other generators
isar	drift	High	Collections become tables, queries become SQL or drift's query builder, plus a one-time data copy on first launch	Watchers and query code rewritten everywhere they are used
realm	drift or objectbox	High	Full rewrite of models and queries; ObjectBox is closer to Realm's object model, drift if you need web or SQL	Sync was already removed, so you need your own sync layer either way
sqflite	drift	Medium	Describe your existing tables in drift and move queries over; the SQLite file format is the same	Matching drift's schema version to the one your users already have on device

Even the "low" row is not three lines of pubspec. Before you ship a hive to hive_ce swap, run flutter pub deps and look for anything else still pulling in the original package, because two copies of Hive in one app is a confusing failure. Then open a copy of a real production box with the new build and check every record type reads back. We could not find an explicit file-compatibility statement on the hive_ce package page, so test it rather than assuming it.

The rows marked high are a rewrite of your storage layer, and so is starting from scratch: a schema, adapters or table classes, a backup and restore path, and tests against real data, all before the app does anything a customer would pay for. That is days of work even when it goes well. If you would rather start from a working storage layer, StockPilot, our offline POS and inventory app, ships with its product catalog, sales and JSON backup and restore already built on Hive, and Vet Vault keeps pet medical records, reminders and documents in the same local Hive setup with no server. Both use Hive's box API, which is the API hive_ce continues, so the first row of the migration table is the path if you want either on the maintained fork.

Where to go from here

If the decision tree pointed you toward a local-first build and you would rather not wire the storage layer yourself, browse our offline-first Flutter apps, each one running with no backend. When you are ready to add a server back into the picture, data synchronization and conflict resolution in offline apps covers the part that breaks most often.

References and further reading

• Flutter docs: Offline-first support, the official repository-as-source-of-truth pattern
• hive_ce on pub.dev
• isar_community on pub.dev
• drift on pub.dev and drift's encryption guide
• objectbox on pub.dev