Every "best Flutter database" post benchmarks insert speed. Almost none of them ask the question that actually decides your architecture: will this thing still be maintained when you ship v2?
That question matters more than raw throughput, because three of the local databases the Flutter community once loved — Hive, Isar, and Realm — are now effectively unsupported. Hive and Isar were abandoned by their original author; Realm's sync was killed by MongoDB. Teams that bet on them are writing migration code instead of features. Speed and features got them in; maintenance is getting them out.
So this guide ranks the options by a different axis. Performance is table stakes; all of these are fast enough for the overwhelming majority of apps. What separates them in 2026 is maintenance health, platform reach, and how much pain a wrong choice costs you two years from now.
Context: written against Flutter 3.44 and Dart 3.12 (both May 2026).
---
TL;DR
SharedPreferences or flutter_secure_storage is enough.---
Why maintenance is the real benchmark
A local database is one of the stickiest decisions in your codebase. Your schema, your queries, your migrations, your reactive layer — all couple tightly to whatever you picked. Swapping it out later means a data migration on devices already in users' hands, which is among the riskiest things you can ship.
That asymmetry is the whole argument. A database that is 5x faster but unmaintained is a worse bet than one that is "fast enough" and actively developed, because the cost of the unmaintained one shows up later, larger, and at the worst possible time — when a new Dart SDK, a new Android NDK, or a new platform breaks the package and nobody is there to fix it.
So before benchmarks, ask three questions of any candidate:
1. Is the original author or a credible team still shipping releases?
2. Does it keep up with new Dart/Flutter SDKs and platform requirements?
3. If it died tomorrow, how expensive is my exit?
Now the contenders, ordered by how confidently I'd start a new production app on them today.
---
Drift — the default
Drift (formerly Moor) is a reactive persistence library built on top of SQLite. It isn't a database engine itself; it's a type-safe ORM and query layer over the most battle-tested embedded database in existence.
Maintenance: healthy. Actively developed by Simon Binder with regular releases through 2026, and now sponsored by Stream and PowerSync. SQLite underneath means the storage format will outlive all of us.
Why it's the default:
drift_flutter package added shareAcrossIsolates, so multiple isolates hit the same database without you wiring up ports by hand.Trade-offs: You think in SQL and tables. There's a build_runner codegen step. For a dead-simple key-value need it's heavier than it needs to be — but that's not what it's for.
Pick Drift when: you have relational data, need migrations you can reason about, want reactive queries, or are building anything offline-first. Which is most apps.
---
ObjectBox — the sync-ready NoSQL option
ObjectBox is a fast NoSQL object database with a native Dart API. Its distinguishing feature isn't speed — it's the built-in Data Sync engine.
Maintenance: healthy. Commercially backed, with frequent releases (5.3.2 stable, 6.0 in preview as of mid-2026) and current platform support.
Why it stands out:
Trade-offs:* NoSQL means no SQL — relational reporting and ad-hoc analytical queries are weaker. It's a larger native dependency. The most compelling feature (Sync) ties you to ObjectBox's model. And **schema migration demands real care: ObjectBox tracks every entity and property by a stable UID stored in objectbox-model.json and the generated objectbox.g.dart. Those files are source-of-truth and must be version-controlled and kept in sync — regenerate them carelessly (a wrong UID, a clobbered model file) and you risk a *destructive schema change against data already on users' devices. Unlike Drift, there's no SQL migration script you can read, diff, and test step by step; you're trusting the binding files to stay consistent, which is why production setups gate them behind CI checks.
Pick ObjectBox when: you want object persistence plus device sync without building the sync layer yourself, or you need on-device vector search.
---
sqflite — the raw baseline
A thin, well-maintained wrapper around SQLite. No ORM, no codegen, no reactive layer — just SQL and Map<String, dynamic>.
Maintenance: healthy and stable. It's the long-standing baseline the community falls back on.
Pick sqflite when: you want full control over SQL, you're comfortable mapping rows yourself, or you're building your own thin abstraction and don't want an ORM's opinions. For most teams, Drift gives you sqflite's reliability plus type safety and reactivity, so reach for sqflite mainly when you have a specific reason to avoid codegen.
---
Isar — fast, but don't start here
Isar is an extremely fast NoSQL database, written by Simon Leier (also the author of Hive). On paper it's gorgeous: composite indexes, full-text search, multi-isolate by default, ACID, static typing.
Maintenance: this is the problem. The original author went quiet — long gaps between commits, no responses on the project's channels — and the official v4 never reached a stable, trustworthy release. The project survives mainly through the community isar-community fork.
A community fork can be fine. But understand what you're signing up for: you're betting on volunteers' free time to track Dart SDK changes and platform breakages, and the moment that fork stalls, you own the exit. For a hobby project, acceptable. For something you'll maintain for years, the risk rarely pays for the speed.
Pick Isar when: you're prototyping, the speed genuinely matters for your specific workload, and you've consciously accepted the maintenance risk. Otherwise, don't start a new production app here.
---
Hive — same story
Hive is a lightweight, pure-Dart key-value store. Pure Dart meant it ran everywhere, including web, with almost no setup — which is exactly why it got so popular.
Maintenance: abandoned by the original author*, who publicly positioned Isar as its successor. Then Isar stalled too. A *Hive Community Edition (Hive CE) now carries it forward.
Where it still fits: genuinely simple needs — user settings, small cached responses, flags. It was never built for complex queries, relationships, or large datasets, so don't push it there.
Pick Hive CE when: you want dead-simple key-value persistence, you've accepted the community-maintenance posture, and your needs are modest. For anything beyond that, the value over SharedPreferences is thin and the value under Drift is large.
---
Realm — the third cautionary tale
Realm deserves its own section, because it's the clearest illustration of this whole guide's thesis. It was a capable mobile NoSQL database whose headline feature was Atlas Device Sync — automatic client-to-cloud syncing backed by MongoDB.
Maintenance: MongoDB pulled the plug. The deprecation of Atlas Device Sync and the Realm SDKs was announced in September 2024, with sync reaching end-of-life on September 30, 2025. The on-device database lives on as an open-source project — recent realm-dart releases even removed the sync functionality and patched compatibility for newer Flutter versions — but it does so without ongoing MongoDB support. The sync engine, the part most teams actually adopted Realm for, is gone and was never open-sourced.
This is the pattern a third time: teams that coupled tightly to Realm Device Sync are now migrating to a third-party or self-built sync layer under a hard deadline. If you have an existing Realm app, decouple your Realm calls and plan an exit. Don't start new projects on it.
---
The rest, briefly
---
You might not need a database
Before reaching for any of the above, check whether your data even justifies one:
SharedPreferences — small key-value data: settings, flags, last-opened tab. (Note the modern async API.)flutter_secure_storage — anything sensitive: tokens, credentials. Don't put a JWT in a plain key-value store.A database earns its complexity when you have structured data, relationships, queries, or an offline-first sync requirement. Below that bar, it's overhead.
---
At a glance
| Option | Model | Maintenance (2026) | Web | Sync built-in | Best for |
|---|---|---|---|---|---|
| Drift | SQL / ORM | Healthy | ✅ | ❌ | Most apps; relational + offline-first |
| ObjectBox | NoSQL objects | Healthy (commercial) | ❌ | ✅ | Synced NoSQL, on-device AI |
| sqflite | SQL (raw) | Healthy | ❌ | ❌ | Full SQL control, no ORM |
| Isar | NoSQL | ⚠️ community fork | ⚠️ | ❌ | Prototypes; risk accepted |
| Hive CE | Key-value | ⚠️ community edition | ✅ | ❌ | Simple key-value |
| Realm | NoSQL | ⚠️ no vendor support; sync EOL | ❌ | ❌ (removed) | Legacy; migrate off |
| SharedPreferences | Key-value | Healthy (first-party) | ✅ | ❌ | Settings, flags (not a DB) |
---
How to choose, in one pass
1. Is it just settings/flags/tokens? → SharedPreferences / flutter_secure_storage. Stop here.
2. Do you have relational data, migrations, or need reactive queries?* → *Drift.
3. Do you need cross-device sync and would rather not build the sync layer?* → *ObjectBox.
4. Do you want raw SQL with no ORM?* → *sqflite.
5. Prototype where speed dominates and you accept maintenance risk? → Isar (eyes open).
For the great majority of production apps, you'll land on Drift — and that's the right place to land.
---
A real-world example: a starter template built on this thesis
The trade-offs above aren't abstract. flutter-starter-template — an open-source, production-ready Flutter boilerplate by Luci Studio — is a concrete instance of the decisions in this guide.
It's built offline-first*, and that requirement drove its current database choice. Writes commit to a local *ObjectBox store first, the UI updates immediately, and the network is reconciled in the background through a reusable rev_sync engine — revision-based delta sync, tombstones, and optimistic-concurrency conflict detection — against a companion Go backend. That's exactly the "pick ObjectBox when you want fast object persistence" case from the ObjectBox section, made real: it leans on ObjectBox's speed for the local-first write path while owning its own sync layer.
What makes it a useful illustration of this guide's other* lesson — that your database is a sticky decision worth keeping swappable — is the roadmap. ObjectBox is the current default, chosen to optimize performance, but the template is moving toward offering Drift** and *SQLite (via sqflite) as alternative storage options. That maps cleanly onto the three picks here: ObjectBox for the fast object store, Drift as the type-safe relational default, and raw SQLite for teams that want full SQL control.
The architecture already makes this feasible. ObjectBox entities and bindings are centralized in a single database package behind a Store wrapper; features depend on that package rather than on objectbox directly, and every feature reaches its data through Clean Architecture repository interfaces. That's the encapsulation this guide keeps pushing — depend on your own abstraction, not the raw dependency — and it's what turns adding Drift/SQLite into an additive option rather than a rewrite.
It also confronts the migration risk above head-on. The template deliberately version-controls objectbox-model.json and lib/objectbox.g.dart — the two files holding the stable entity/property UIDs — instead of treating them as throwaway codegen, and a CI step fails the build if an @Entity change isn't accompanied by the regenerated binding. That's precisely the discipline ObjectBox's migration model requires, and it doubles as an argument for the swappable persistence boundary: when the painful part of a database is its on-device schema evolution, keeping it behind a repository interface is exactly what lets you offer Drift or SQLite later without betting users' data on a regeneration going right.
If you want the maintenance-first argument expressed as code rather than prose, it's a reasonable reference: real offline-first sync, an exit-friendly persistence boundary, and a deliberate plan to give developers the ObjectBox / Drift / SQLite choice this guide lays out.
---
The verdict
The Flutter database story of the last few years is a cautionary tale: the community twice fell for the fastest option, and twice the fastest option stopped being maintained. The lesson isn't "speed doesn't matter." It's that maintenance is a feature — arguably the most important one — and it never shows up in a benchmark chart.
In 2026, the boring answer is the correct one. Start on Drift. Reach for ObjectBox when you specifically need sync. Treat Isar and original Hive as legacy you migrate off*, not platforms you build *on.
---
Happy coding : )
Loading…