# Isar Alternative for Flutter: Community, Plus or Drift?

*Originally published on [Stacklyn Labs](https://stacklynlabs.com/blog/isar-alternatives-flutter/).*

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](https://stacklynlabs.com/blog/building-zero-latency-mobile-apps-hive-vs-isar-vs-sqlite-choosing-a-flutter-local-database-in-2026/). 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](https://developer.android.com/guide/practices/page-sizes) 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

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

```dart
// 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`:

```text
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](https://stacklynlabs.com/product/rent-folio/), 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](https://stacklynlabs.com/blog/migrate-hive-to-hive-ce/) 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:

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

The [isar_plus migration guide](https://github.com/ahmtydn/isar_plus/blob/main/docs/isar-plus-docs/content/docs/recipes/migrate_from_isar3.mdx) 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:

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

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

```dart
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](https://stacklynlabs.com/products/?cat=mobile-applications) 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](https://stacklynlabs.com/hire-us/?service=mobile_app) 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](https://stacklynlabs.com/blog/securing-local-first-applications-a-flutter-architecture-study/) before you decide how much protection your stored data needs.

## References

- [isar](https://pub.dev/packages/isar), [isar_community](https://pub.dev/packages/isar_community), [isar_plus](https://pub.dev/packages/isar_plus) and [drift](https://pub.dev/packages/drift) on pub.dev
- [isar_community repository](https://github.com/isar-community/isar-community) and its [changelog](https://pub.dev/packages/isar_community/changelog)
- [isar_plus repository](https://github.com/ahmtydn/isar_plus), [changelog](https://pub.dev/packages/isar_plus/changelog) and [migration guide from Isar 3](https://github.com/ahmtydn/isar_plus/blob/main/docs/isar-plus-docs/content/docs/recipes/migrate_from_isar3.mdx)
- [drift repository](https://github.com/simolus3/drift)
- [Original Isar repository](https://github.com/isar/isar)
- [Android developers: support 16 KB page sizes](https://developer.android.com/guide/practices/page-sizes)

---

*Further reading: [Migrate Hive to hive_ce: what breaks after the pubspec swap](https://stacklynlabs.com/blog/migrate-hive-to-hive-ce/)*