Drift

Overview

Drift brings relational database work into Dart and Flutter projects with typed access to stored data. It is a strong fit for developers who want reactive queries without giving up SQL; teams should be ready to manage schema changes themselves.

Rows map to developer-chosen objects, and queries can be watched as streams that update when underlying data changes. That makes Drift useful when application logic or a UI needs to react to database updates rather than fetch results only on demand.

Its SQL parser and analyzer can validate queries at compile time and generate Dart row code. That is a meaningful safeguard for SQL-heavy projects, though the compile-time tooling comes with a code-generation setup using drift_dev and build_runner.

Key features

Relational data with reactive access

Type-safe queries and mapped rows give Dart code a structured way to work with relational data. Watched queries emit updated results when the database changes, a practical advantage for apps that need stored state and active views to stay in sync.

SQL and database choices

Drift supports SQLite and has packages for PostgreSQL and libSQL connections. Its documentation also covers remote libSQL and Turso, including local-copy synchronization with libSQL. Most queries work with PostgreSQL without modification, but some APIs, including date-time modification APIs, are SQLite-only. Projects that rely on those APIs should account for that backend difference.

Migrations and encryption

Migration utilities help with schema evolution, but developers must write migrations when changing a schema used by existing apps. That gives teams a path for managing upgrades, not an automatic way around migration work. For encrypted databases, Drift can use SQLite3MultipleCiphers with a NativeDatabase executor; the app must set an encryption key.

Offline and synchronization

Drift supports offline mode and bidirectional data synchronization. Those capabilities suit applications that must work with local data and synchronize in both directions, while the particular backend still matters: local-copy synchronization is documented for libSQL.

Pricing

Drift is free, with a free plan. No paid tier is part of its stated pricing model, so there is no plan-based seat allowance, usage quota, trial period, or renewal term to weigh. The trade-off is not a tier limitation but the engineering work of setting up code generation and writing migrations for existing schemas.

Platforms

Drift's documented implementations support Android, iOS, Windows, Linux, macOS, and web. On the web, some browsers need COOP/COEP security headers for full support. Chrome on Android can have cross-tab persistence issues without those headers, so web deployments need to account for their hosting configuration and browser behavior.

The project also has a Drift DevTools extension page. For questions or feedback, the setup guide points developers to GitHub discussions.

Who it's for

Drift is aimed at developers building Dart and Flutter applications that need relational persistence. It is especially well suited to projects that benefit from typed data access, compile-time SQL checks, and query streams, and that can own their schema migration process.

It is a less natural fit when a project depends on PostgreSQL-only feature parity or needs web persistence to work without browser and hosting considerations. Those constraints do not rule Drift out, but they make backend and deployment choices part of the decision.

Pros and cons

• Pro: Type-safe queries, row mapping, and generated Dart row code give relational data a structured place in Dart applications.
• Pro: Watched queries update as underlying data changes, supporting reactive application logic.
• Pro: SQLite, PostgreSQL, and libSQL integrations offer multiple relational backend paths, with offline use and bidirectional synchronization supported.
• Con: Existing database schemas require developer-written migrations, adding ongoing upgrade work.
• Con: Some APIs are SQLite-only, and web deployments can require COOP/COEP headers to avoid support and cross-tab persistence issues.
• Con: Compile-time generation requires setting up drift_dev and build_runner.

Alternatives

For a broader comparison, see Mobile Databases.

Espresso is a free Android UI-testing option for projects targeting Android 4.0.1/API 14 or later; choose it when testing an Android app interface is the need rather than relational persistence.

Hive offers a free forever plan with 1,000 AI credits per month, 200MB storage, up to 10 workspace members, and unlimited tasks. Pick it when those workspace-oriented allowances fit better than Drift's Dart and Flutter relational approach.

RxDB has a free plan with replication and realtime sync, default storages, and up to 13 open collections. It may suit a project prioritizing that replication-and-storage combination over Drift's relational, SQL-oriented model.

Ditto offers a free plan with 10 cloud device connections, 2GB storage, 5GB data transfer, no SLA, and limited support; consider it when those cloud connection limits match the project.

ObjectBox has a no-cost core database plan; consider it as an alternative if a no-cost core database is the priority.

Firebase Cloud Messaging is a no-cost messaging service, not a direct substitute for relational persistence.

Firestore has stated free-tier allowances of 50,000 document reads and 20,000 document writes per day. Choose it when those document-database quotas are a better fit than Drift's relational approach.

TBase is another free database option to consider.

Verdict

Choose Drift for a Dart or Flutter app that needs typed relational access, reactive query results, and offline or bidirectional synchronization without a software fee. Its strongest reason to choose it is the combination of SQL analysis and streams within a Dart-oriented persistence library. Look elsewhere if PostgreSQL API coverage or web persistence without extra deployment considerations is essential, or if the team cannot take on schema migrations.