Flutter + SQLite

sqflite is a thin wrapper over the platform's SQLite: you write SQL strings by hand and manage schema versions yourself, which is fine for a few small tables that will barely change. drift (formerly Moor) instead generates a type-safe Dart query API from a schema definition, catches SQL errors at compile time, streams query results into widgets so the UI updates when data changes, and runs schema migrations through explicit step-by-step code. The trade-off is setup: drift needs a build-runner code generation step and its own API to learn, while sqflite is immediately familiar if you already know SQL. Pick drift when the schema will keep evolving and you want the compiler enforcing it; pick sqflite for simple, stable data.

SQLite runs inside the app, so the moment it needs multi-device sync, shared data between users, or a web dashboard, something backend-side has to be added. The common destinations are the catalog's Flutter + Firebase and Supabase + Flutter stacks: Firestore gives real-time sync out of the box, while Supabase's PostgreSQL is a closer match for an existing drift schema, which is already relational. The local-first work is not wasted either way; the schema design carries over, and sync engines like PowerSync or ElectricSQL exist specifically to keep the on-device SQLite database and a backend in step rather than replacing one with the other.

Both are Flutter apps; the difference is where the data lives. Here SQLite runs inside the app itself: zero backend cost, zero network latency on queries, and full function with no internet, but the data is trapped on one device. Firebase moves the data to Firestore in the cloud: automatic sync and multi-user support, but every read is a network round trip that costs money once traffic grows, and the app degrades without connectivity. For one person's notes or a field-data tool used on a single device, this stack is simpler and free to run. The moment two people must see the same data, a backend stack like Flutter + Firebase is the honest answer.

The database lives on the user's device, so every schema change shipped in an app update has to migrate the database that user already has, in place, without losing data. sqflite leaves this entirely to you: an onUpgrade callback compares version numbers and runs the ALTER TABLE and CREATE statements in order, and a missed step means corrupted or empty data on real devices. drift makes the path explicit: each schema version gets its own migration step, and its tooling can verify migrations in CI against a snapshot of the previous schema. Either way, test every migration path, including from older shipped versions to the current one, not just from the immediately previous version.

No. The stack works fully without any account system, which is one of its real advantages: no sign-up friction for users and no auth bill to pay. Add authentication only when the app needs to identify one specific person, for example to sync data between a phone and a tablet or to gate a paid feature. The Clerk addition covers exactly that case: its clerk_flutter SDK (currently in beta) adds sign-in screens to what is otherwise a purely local app, and Clerk's free plan covers up to 50,000 monthly retained users. If the data never leaves one device, there is nothing to authenticate against, so skip the addition.