Isar Alternative for Flutter: Community, Plus or Drift?

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

Where you are	Pick	What it costs you
Shipped app on isar 3.1.0+1, Android updates must keep shipping	isar_community 3.3.2	Package and import swap, a regenerate, and a newer code generator toolchain
Shipped app, planning a long life	isar_community now, drift later	A full data-layer rewrite, on your schedule instead of Google's
Shipped app that now needs web, encryption or string ids	isar_community now, then a copy migration to isar_plus	Model changes for the v4 API and a copy step you write and test yourself
New app, wants Isar's object API, needs web or encryption	isar_plus 1.3.9	One maintainer, docs that lag the code, no async APIs or watchers on web
New app with relational data or a long horizon	drift 2.35.2	SQL schema and migrations from day one, no Isar code reused

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:

Binary	arm64-v8a	x86_64
isar_flutter_libs 3.1.0+1, libisar.so	0x1000 (4 KB), not 16 KB aligned	0x1000, not 16 KB aligned
isar_community_flutter_libs 3.3.2, libisar.so	0x4000 (16 KB)	0x4000 (16 KB)
isar_plus 1.3.9 release, libisar_plus_android_arm64.so	0x4000 (16 KB)	not checked

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 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:

Isar v3	isar_plus
writeTxn(...)	writeAsync(...)
writeTxnSync(...)	write(...) (operations are sync by default)
txn(...)	readAsync(...)
Id? id = Isar.autoIncrement	non-nullable int id, set with collection.autoIncrement()
@enumerated	@enumValue
IsarLink, IsarLinks, @Backlink	removed: use embedded objects or your own id fields
replace: true on unique indexes	removed: the latest write always wins

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:

	Maintainers	Repository (GitHub, October 13, 2026)	Promise
isar_community	One main maintainer doing nearly all recent merges; an outside memory-leak fix landed in July 2026	193 stars, 51 open issues, last commit September 8, 2026	Bug fixes and small updates for v3
isar_plus	One person, with no other human contributor in the top list	73 stars, 5 open issues, last commit August 4, 2026	A v4-based engine with web, encryption and an SQLite option
drift	Long-running lead maintainer plus regular contributors	3,290 stars, 211 open issues, last commit October 11, 2026	Ongoing, with a major version in progress

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