Your Flutter app keeps its data in isar 3.1.0+1. It builds, it ships, and your users' data opens every morning. But the last stable Isar release on pub.dev is from April 25, 2023, the 4.0 line has sat at a dev prerelease since August 2023, and Google Play has set a date after which app updates must support 16 KB memory pages. So you look for an Isar alternative for Flutter and find three names: isar_community, isar_plus and drift.

The pages that rank for this explain how to use Isar or list alternatives in a sentence each. None opens a real Isar 3 file with each successor or checks the Android binaries. We did both. The short version: the original Android libraries are not 16 KB aligned, isar_community is the cheap fix, isar_plus is a different database with a familiar API, and drift means leaving the Isar family on purpose.

If you are picking a database from scratch rather than replacing one, start with picking a Flutter local database for an offline-first app. This post is only about getting off original Isar.

A note on the evidence: our tests ran in a scratch pure-Dart project on Dart 3.12.0, on Windows, not in a Flutter app on a device. The data was written by isar 3.1.0+1: two collections, a unique index with replace: true, an @enumerated enum, a DateTime, a double, an embedded list, an IsarLink and a @Backlink. The 16 KB result comes from reading the published Android binaries, not from running on a 16 KB device. Versions are from pub.dev on October 13, 2026. Anything not marked as tested comes from docs and changelogs.

Which Isar alternative for Flutter fits your project

Why staying on isar 3.1.0+1 now has a deadline

Original Isar has stalled. It is not marked discontinued on pub.dev. The last stable release, 3.1.0+1, came out on April 25, 2023, and the newest prerelease, 4.0.0-dev.14, on August 21, 2023. The last repository commit, on June 14, 2025, added a privacy manifest.

Stalled is not broken. isar 3.1.0+1 declares an SDK constraint below Dart 3.0, yet it still resolves and runs on Dart 3.12 (tested). The cost is your toolchain: isar_generator 3.1.0+1 pinned our project to analyzer 5.13.0, source_gen 1.5.0 and build_runner 2.4.13. Every other generator in the app, such as freezed, json_serializable or riverpod_generator, has to fit under that ceiling.

That was a preference problem until Android's page size change turned it into a deadline. We read the ELF PT_LOAD alignment (p_align) of the published Android libraries:

Google's page size guidance says apps targeting Android 15 (API level 35) and higher must support 16 KB memory pages on 64-bit devices on Google Play. It also says that starting February 1, 2027, app updates that do not support 16 KB pages cannot be released.

If your app targets API 35 and still bundles the original libisar.so, the clock is real, and upstream has not published a new build of that binary since 2023. To check your own build, readelf -l on each .so prints an Align value on every LOAD line. Our check shows how the library is built, not how the app behaves on a 16 KB device, so test on one before release.

isar_community: the same database, rebuilt for 2026

isar_community is the Isar v3 code under a new name. Its README describes a fork "focusing primarily on bug fixes and small updates for version 3." The changelog since the rename is maintenance: libmdbx 0.13.8, 16 KB page support (from 3.2.0-dev.1), an Android namespace, a Linux GLIBC 2.36 fix, dependency bumps. It runs on Android, iOS, Linux, macOS and Windows, with no web support and no built-in encryption, because v3 never had either.

The swap

dependencies:
  isar_community: ^3.3.2                # was isar
  isar_community_flutter_libs: ^3.3.2   # was isar_flutter_libs

dev_dependencies:
  isar_community_generator: ^3.3.2      # was isar_generator
  build_runner: any                     # resolved 2.15.1 for us

The package name changes, the library name does not:

// before
import 'package:isar/isar.dart';

// after
import 'package:isar_community/isar.dart';

You must regenerate before it compiles (tested)

We tried the lazy route first: swap the packages, keep the old .g.dart files. They fail to compile with a const assertion on Isar.version:

Outdated generated code. Please re-run code generation using the latest generator.

After dart run build_runner build, the new .g.dart differed from the old one in one place: the embedded version string changed from '3.1.0+1' to '3.3.2'. Every record in our v3 file read back identical, including the link, the backlink count, the embedded list and the enum. New writes worked. No data migration step was needed.

The real change is the toolchain: ours moved to analyzer 10.2.0, source_gen 4.2.4 and build_runner 2.15.1. That lifts the analyzer 5 ceiling off your other generators, and also means they all upgrade at once. The runtime package still says Dart 2.17, but isar_community_generator 3.3.2 needs Dart 3.9, so that is your real floor.

Rollback worked, once

We reopened the file that isar_community had written to (four records by then) with the original isar 3.1.0+1. All four came back. That is one test on one schema, not a guarantee, so keep backups of real user files anyway.

We made this same swap in a shipping app. Rent Folio, our offline landlord app template, was built on isar 3.1.0, with the 4 KB aligned Android binaries from the table above. It now runs on isar_community, using the steps in this section: swap the three packages, change the imports, regenerate the .g.dart files, then check that existing data reads back.

We did not test whether isar_flutter_libs and isar_community_flutter_libs can sit in one Flutter app, which happens if another dependency still pulls in isar. Run flutter pub deps and look for a stray isar before you find out on a device. If the same app keeps settings or a cache in Hive, that store has its own version of this problem, and the Hive CE migration path covers what breaks there.

isar_plus: Isar v4 with one maintainer

isar_plus is not a newer v3. Its 1.0.0 changelog says it is based on the Isar v4 architecture, the line Isar's own README still marks as not ready for production. On top of v4 it adds web support (SQLite compiled to WASM, with an IndexedDB fallback), encryption through SQLCipher (SQLite engine only), string ids, an optional SQLite engine and dynamic or Map properties. The code generator ships inside the package. It needs Dart 3.7, Flutter 3.24 and Android minSdk 23.

The API is different enough that you will touch every data access:

On web, its limitations page says async APIs and watchers are not supported, everything runs on the main thread, and most environments fall back to IndexedDB.

The docs already lag the code. The README tells you to call Isar.initializeIsarCore(download: true) in unit tests. That method does not exist in 1.3.9; we had to use Isar.initialize([library]), which does not download anything. The limitations page still mentions lazy-loaded links, which v4 removed.

It cannot open your v3 file, and the attempt changes it (tested)

Opening our v3 file with isar_plus 1.3.9 failed with:

DatabaseError: IsarError: Schema error: Could not deserialize existing schema.

The isar_plus migration guide quotes a VersionError instead, so do not search your logs for that one.

The failed open was not harmless. shop.isar grew from 1 MB to 20 MB and its bytes no longer matched the backup. Our data survived: both isar 3.1.0+1 and isar_community 3.3.2 still read all three records. Do not count on that. Back up first, and never point isar_plus at the v3 directory and name.

The documented side-by-side setup does not resolve (tested)

The guide's plan is sound: keep the old packages next to isar_plus, copy every record across, delete the old ones. But its pubspec, with isar, isar_flutter_libs and isar_generator 3.1.0+1 beside isar_plus, fails dart pub get. isar_generator wants source_gen ^1.2.2, isar_plus wants ^4.2.3. Swapping in isar_community_generator 3.3.2 fails too, on analyzer >=8 <11 against >=12.1 <14.

The runtimes alone do resolve together. What worked for us:

1. Generate the legacy .g.dart with the old generator first.
2. Commit it.
3. Remove the legacy generator, keeping only the legacy runtime.

The guide's build command deletes the file you kept (tested)

The guide then tells you to run:

dart run build_runner build --delete-conflicting-outputs

That flag deleted our hand-kept legacy_model.g.dart, and the build failed. Excluding the legacy model in build.yaml fixed it:

targets:
  $default:
    builders:
      isar_plus:isar_generator:
        generate_for:
          exclude: [lib/legacy_model.dart]
      source_gen:combining_builder:
        generate_for:
          exclude: [lib/legacy_model.dart]

The copy itself worked (tested)

With both packages imported under aliases, the legacy runtime and isar_plus loaded in one Dart process, each with its own native library:

import 'package:isar_community/isar.dart' as legacy;
import 'package:isar_plus/isar_plus.dart' as plus;

We copied all three records into a new shop_plus instance in the same directory. The IsarLink became an int? categoryId and the enum was mapped by name. Afterwards, collection.autoIncrement() returned 4, so new ids continue past the copied ones. The legacy file was untouched at 1 MB.

So the isar_plus route is a v4 model rewrite, a pubspec the guide gets wrong, a build that deletes your legacy file, and a copy step you must test against real user data. Leaving for drift needs the same copy step plus a rewrite of every query. On an app of any real size, either one is weeks of work before a user sees anything new, and we cannot tell you how many for yours. If what you need is a working offline app rather than a storage project, our offline-first Flutter app source code has that layer already built and running without a server.

drift: leaving the Isar family on purpose

Drift is a different kind of database. It is a typed layer over SQLite with its own query builder, stream-based watched queries and schema migrations, and it runs on all six Flutter platforms, web included. Nothing from your Isar code carries over: collections become tables, links become foreign keys, watchers become watched queries, and your users' data needs a one-time copy on first launch. We did not test a drift migration, because it is a rewrite by design.

What you get for that is the healthiest maintenance picture of the three. Drift 2.35.2 was published on October 7, 2026, and the repository had commits on October 11. Its lead maintainer has 3,739 commits, and several other people contribute regularly. One thing to know before you start: there is no drift 3.x on pub.dev yet, but the repository already has commits migrating parts of the project to drift3. A major version is in progress, so plan for one more upgrade on drift's side at some point.

Choose drift when you are rewriting anyway or starting fresh. As a way to beat the February 2027 deadline on a shipped app, it is the slowest of the three.

A fork is a liability you inherit

Isar itself is the lesson. It was a well-liked database built largely by one author, with 885 commits in the repository and none in its recent history. When those releases stopped, every app built on it inherited the problem. Choosing a fork does not remove that risk. It moves it to someone else, usually one person, and makes you depend on them staying interested.

Look at who is behind each option today:

A fourth fork, isar_db, also shows up in search: two releases, the latest 1.0.1+1 from October 2025. We did not test it.

None of this says either fork is bad. isar_community did exactly what it promised and shipped 16 KB binaries the original never got. But when you adopt a fork, plan as if you may one day be its maintainer:

• Pin exact versions rather than carets, so an upgrade is always a decision.
• Keep a tested export of every collection to plain JSON or SQL. If the fork stalls, leaving becomes a data copy instead of an archaeology project.
• Watch the repository's commits and issues as well as its pub.dev page.
• Write down which native binary ships in your app, and check its alignment again whenever Android's requirements move.

Pre-migration checklist

1. Copy real .isar files off a test device and keep them out of the app directory.
2. Check p_align on every .so in your release APK, not only Isar's.
3. Run flutter pub deps and look for any package that still pulls in isar.
4. Confirm Dart 3.9 or later for isar_community_generator, or Dart 3.7, Flutter 3.24 and minSdk 23 for isar_plus.
5. List your other code generators and check they accept the new analyzer range.
6. Regenerate every .g.dart; never edit the version string by hand.
7. Open the copied files with the new build and compare every collection.
8. For isar_plus, give the new database its own name, and exclude legacy models in build.yaml before running build_runner.
9. Keep one release where you could still roll back before deleting the old data.

Where to go from here

If you would rather not spend your next sprint on this, we can plan and run your Flutter app's database migration for you. And since neither isar_community nor the original v3 encrypts data at rest, read where to keep encryption keys in a local-first Flutter app before you decide how much protection your stored data needs.

References

• isar, isar_community, isar_plus and drift on pub.dev
• isar_community repository and its changelog
• isar_plus repository, changelog and migration guide from Isar 3
• drift repository
• Original Isar repository
• Android developers: support 16 KB page sizes

Further reading: Migrate Hive to hive_ce: what breaks after the pubspec swap

Your Flutter app runs on hive 2.2.3. It still opens its boxes and still ships. But flutter pub upgrade keeps stalling on hive_generator, and the last stable hive release on pub.dev is from June 2022. Meanwhile hive_ce, the community continuation of Hive v2, has overtaken the original: 1,317,184 downloads in the last 30 days against 1,131,007 for hive when we checked on October 12, 2026.

So you look up how to migrate Hive to hive_ce. The official page covers swapping the packages and the imports, and calls hive_ce a drop-in replacement for Hive v2. That is true as far as it goes. It does not say whether your users' existing box files still open, what happens when another package in your tree still depends on hive, or that one hive_ce feature removes your ability to roll back.

We ran the migration against real Hive 2 data to find out. This hive_ce migration guide covers the swap in one short section and spends the rest on what the docs leave out. If you are still deciding whether hive_ce is the right home at all, start with how hive_ce compares with Isar, drift and SQLite in 2026.

A note on the evidence: our tests ran in a scratch pure-Dart project on Dart 3.12.0, on Windows, not in a Flutter app on a device. Anything below about initFlutter comes from the hive_ce source, changelogs and issue tracker.

The swap the docs already cover

Three package names change in pubspec.yaml. These are the current versions on pub.dev as of October 12, 2026:

dependencies:
  hive_ce: ^2.20.2          # was hive
  hive_ce_flutter: ^2.4.0   # was hive_flutter

dev_dependencies:
  hive_ce_generator: ^1.11.3  # was hive_generator
  # keep your existing build_runner entry

Then every import changes:

// before
import 'package:hive/hive.dart';
import 'package:hive_flutter/hive_flutter.dart';

// after
import 'package:hive_ce/hive_ce.dart';
import 'package:hive_ce_flutter/hive_ce_flutter.dart';

The import change is not optional. With hive removed and the old imports left in place, the analyzer stops at uri_does_not_exist on package:hive/hive.dart.

Three small traps sit inside those few lines:

• The generator is on 1.x, not 2.x. Issue #62 is a user who copied hive_ce's version number into hive_ce_generator: ^2.8.0+3 and got a version-solving failure.
• The SDK floor is Dart 3.4. The README's getting-started snippet shows sdk: ^3.0.0, but all three packages declare ^3.4.0 on pub.dev.
• hive_ce_flutter 2.4.0 needs Flutter 3.44.0 or later. On an older Flutter, ^2.4.0 will not resolve. Use hive_ce_flutter: ^2.3.4 instead: the 2.3.x line needs Flutter 3.27.0 or later, and the same constraint still picks up 2.4.0 once you upgrade Flutter.

Your existing box files open unchanged

The migration page says Hive v4 data is not compatible. It never says outright that Hive 2 files are.

We tested it. With hive 2.2.3 and hive_generator 2.0.1 we wrote four boxes: a typed box of Product extends HiveObject (with String, double, enum, DateTime and List<String> fields, under both an auto-increment key and a string key), an untyped box holding a mixed map, a LazyBox, and an AES-encrypted box.

We saved what Hive 2 read back as a baseline, then opened the same files under hive_ce 2.20.2 in three states: after only the pubspec and import swap, after regenerating adapters with hive_ce_generator, and after a full move to GenerateAdapters. In all three, every value, every key and every HiveObject.key matched the baseline, including the lazy and encrypted boxes. No data migration step was needed.

The limits: one model, one platform, not your schema on an Android phone. Before you ship, copy a real production box off a test device and open it with the new build.

Check typeIds 200 and 201 before you upgrade a Flutter app

This is the biggest gap in the official guide, and it only affects Flutter apps.

Since hive_ce_flutter 2.0.0, a release its changelog marks as breaking, Hive.initFlutter() registers a ColorAdapter at typeId 200 and a TimeOfDayAdapter at typeId 201 for you. If one of your models already uses 200 or 201, your own registration throws There is already a TypeAdapter for typeId 200. That is issue #105, filed by a developer migrating from the original packages. In issue #291, closed February 2026, the complaint was that the reserved IDs were undocumented.

Run this before you touch the pubspec:

grep -rnE "typeId *[:=] *20[01]\b" lib/

It catches both @HiveType(typeId: 200) annotations and hand-written adapters with final int typeId = 201;.

If you get a hit, do not renumber your model. Changing a typeId orphans every record already stored under it. Move the Flutter adapters instead: since hive_ce_flutter 2.3.0 their IDs are configurable. In the current source, initFlutter takes them as optional positional parameters:

Future<void> initFlutter([
  String? dir,
  HiveStorageBackendPreference backendPreference =
      HiveStorageBackendPreference.native,
  int? colorAdapterTypeId,      // default 200
  int? timeOfDayAdapterTypeId,  // default 201
  bool useMaterialUi = false,
])

Pick two IDs no model of yours uses. If you stored Color values through the old ecosystem's adapter, read issue #182 first: that format is not compatible, and a bug reading legacy colour data was only fixed in hive_ce_flutter 2.3.2.

Find any package that still pulls in hive

Your pubspec can be clean while your dependency tree is not. Two common sources of the original package:

• hydrated_bloc 9.1.5 and older depend on hive ^2.0.0. It moved to hive_ce in 10.0.0, released January 2025.
• hive_flutter 1.1.0 depends on hive, so a forgotten hive_flutter line brings it back.

Find them with this (use dart pub deps for a pure Dart package):

flutter pub deps | grep -E "\bhive(_flutter|_generator)? [0-9]"

Anything it prints is the original package, not the CE one.

What two copies of Hive do

We reproduced this with both packages installed. They run as two separate engines: identical(ce.Hive, old.Hive) returns false, and each has its own adapter registry and open boxes.

Opening the same box from both failed. On Windows the error was:

PathAccessException: lock failed, path = 'data_both\shared.lock'

That wording is Windows only; other platforms word it differently. Either way it looks like a package that cannot open its box, not like two copies of Hive.

The override shim

The best fix is upgrading the offending package. If you cannot, the hive_ce repository ships a stand-in hive package under overrides/hive for exactly this case. This is the dependency_overrides entry from the Hive CE docs on transitive Hive dependencies, which we used as is:

dependency_overrides:
  hive:
    git:
      url: https://github.com/IO-Design-Team/hive_ce
      ref: 18f92b53295e9eb77ebd4830d905a72cd404a126
      path: overrides/hive

Pub resolved hive 0.0.0 from git ... (overridden). After that, identical() returned true, and a write through one import was visible through the other: one engine, one box.

The costs: every machine that resolves dependencies, CI included, needs git and access to GitHub. You are pinned to one commit, so check the docs for a newer ref when you upgrade. And you still list hive_ce as a direct dependency. Treat the shim as a bridge until the other package moves.

The one-way door: typeIds above 223

Rolling back works up to a point: data hive_ce wrote with the same model and plain types read back correctly in hive 2.2.3.

The point is typeId 224. Original Hive caps custom typeIds at 223, and hive_ce 2.10.0 raised the limit to 65439. Once you register an adapter above 223 and write with it, the original package can no longer read that box. We tested typeId 300 in hive 2.2.3 and got two different failures:

• registering the adapter: HiveError: TypeId 300 not allowed.
• opening the box without it: HiveError: Cannot read, unknown typeId: 21. Did you forget to register an adapter?

The 21 is not your ID. It appears to be the marker hive_ce writes for an extended typeId; that is what we observed, not something the docs state.

So keep a rollback window. Ship the plain migration first, let it run in production for a release or two, and only then allow typeIds above 223.

What changes in your adapters and toolchain

Your old generated .g.dart files compile against hive_ce as they are, so regeneration can wait if you want a smaller first diff. When you do run dart run build_runner build, three things change:

The bigger change is what the old generator was holding back. In a fresh Dart 3.12 project, adding hive_generator 2.0.1 resolved analyzer 6.4.1, source_gen 1.5.0 and build_runner 2.4.13, and downgraded test and other packages. After switching to hive_ce_generator, the same project resolved analyzer 14.5.0, source_gen 4.3.0 and build_runner 2.16.2. If your app also uses freezed, json_serializable or any other generator, hive_generator was probably the anchor keeping them all old. We infer that from the version constraints; we have not seen an issue that states it. It is still the best reason to migrate that is not about maintenance.

If you're on Isar instead, the original isar_generator holds your toolchain back in the same way, and its Android binaries add a deadline of their own. We tested the Isar alternatives for Flutter against a real Isar 3 file.

Add it up and the three-line migration is really a typeId audit, a dependency tree review, a decision about a git override, a regeneration, and a read-back test against real user data. On an app you wrote yourself, plan for a careful day. On a codebase you inherited, budget longer, because first you have to learn where every box is opened. If what you need is a working offline app rather than a storage migration project, StockPilot, an offline Flutter POS whose data lives in local Hive boxes, is the kind of codebase this guide was written for. Its latest release made this move: StockPilot now runs on hive_ce, with the same data format as before.

Moving to GenerateAdapters (optional)

hive_ce would rather you stop annotating models with @HiveType and @HiveField and list them in one @GenerateAdapters annotation. You do not need this to migrate. If you do it, the documented route worked for us:

1. Move any @HiveField default values into constructor parameter defaults. Our test model had none, so we did not exercise this step.
2. Enable the migrator builder in build.yaml and run build_runner:

targets:
  $default:
    builders:
      hive_ce_generator|hive_schema_migrator:
        enabled: true

3. It writes lib/hive/hive_adapters.dart containing @GenerateAdapters([AdapterSpec<Product>(), AdapterSpec<Category>()]), a lib/hive/hive_adapters.g.yaml with your existing typeIds and field indexes preserved, and a registrar.
4. Revert build.yaml, remove the annotations and part directives from your models, and build again.

Our Hive 2 data still read back identically. Two things caught us that the docs do not mention.

The registrar file moves. During the migrator run it is written to lib/hive_registrar.g.dart. After the final build it lives at lib/hive/hive_registrar.g.dart, so the old import breaks with Error when reading 'lib/hive_registrar.g.dart'. Update the import in main.dart.

The .g.yaml becomes the source of truth for field indexes. Its header says to check it into version control. Do that. Renaming a field now means editing the yaml by hand, as the docs say. We did not test losing the file, but regenerating without it risks reassigned indexes, which is the kind of mistake that corrupts reads quietly.

Deprecations the analyzer will not flag

hive_ce's deprecation policy is that APIs are never marked deprecated in code, because the project aims never to introduce breaking changes. So your build stays quiet while the docs list these as replaced:

• @HiveType and @HiveField, in favour of GenerateAdapters
• HiveObject
• HiveList
• ValueListenable and box.listenable(), in favour of box.watch()

None of this has to change during the migration. It matters later, because HiveObject and HiveList are what block IsolatedHive, the multi-isolate API added in 2.11.0. Do not adopt it in the migration branch. The isolates docs say that if you use it, you must use it everywhere in place of Hive; it does not support HiveObject or HiveList, and most calls become async. That is a refactor of every data access in the app.

The same 2.11.0 release tightened some type rules: boxes of type Map must be Map<dynamic, dynamic>, boxes of type Iterable must be Iterable<dynamic>, and custom objects in a BoxCollection must be JSON-serializable. If you open something like Box<Map<String, dynamic>> today, find it before you upgrade.

Pre-migration checklist

1. Copy real box files off a test device or staging install.
2. In a Flutter app, grep for typeId 200 and 201.
3. Run flutter pub deps and look for hive, hive_flutter or hive_generator.
4. Upgrade or override any package still on hive, starting with hydrated_bloc 9.x.
5. Search for boxes typed as a Map or Iterable with non-dynamic type arguments.
6. Confirm Dart 3.4 or later and, for hive_ce_flutter 2.4.0, Flutter 3.44.0 or later.
7. Swap the three packages and every import.
8. Open the copied boxes with the new build and compare every record type.
9. Clear CI caches so no stale .g.dart or resolved hive survives.

What not to do

• Do not renumber a model's typeId to dodge the 200/201 collision. Move the Flutter adapters instead.
• Do not use a typeId above 223 until the migrated release has proven itself. It ends your rollback option.
• Do not set hive_ce_generator: ^2.x. The generator is on 1.x.
• Do not adopt IsolatedHive in the migration branch.
• Do not leave the .g.yaml out of git if you move to GenerateAdapters.

Where to go from here

If you would rather start from apps whose local storage layer is already built and running without a server, browse our offline-first Flutter app templates. And since an encrypted box is only as safe as the place you keep its key, securing local-first applications in Flutter covers where that key should live.

References

• hive_ce on pub.dev, hive_ce_flutter and hive_ce_generator
• Hive CE docs: migrating from Hive v2
• hive_ce_flutter changelog, for the 200/201 registration (2.0.0) and configurable IDs (2.3.0)
• hive_ce changelog, for the 65439 typeId limit (2.10.0) and the 2.11.0 type rules
• GitHub issues #62, #105, #182 and #291
• Hive CE docs: transitive Hive dependencies and the override package in the hive_ce repository
• Hive CE docs: HiveTypes to GenerateAdapters

Further reading: Choosing a Flutter local database in 2026