Compare sqflite and Drift: trade-offs and when to choose Drift

WHAT THIS TESTS: Your architectural judgment on where abstraction adds value in Flutter data layers. The interviewer wants to see that you understand Drift is not just a wrapper but a codegen-augmented layer that changes how you write queries, handle migrations, and ship across platforms.

A GOOD ANSWER COVERS: Four areas in order. First, type safety: sqflite returns dynamic List<Map<String, Object?>> that you parse by hand, so refactoring columns is error-prone and runtime crashes are common, whereas Drift generates typed data classes and validates SQL at compile time. Second, boilerplate and query complexity: sqflite forces raw string SQL for everything including joins and migrations, while Drift offers a Dart query builder that can express complex statements and auto-updating streams without manual stream wiring. Third, performance and platform reach: Drift is not inherently slower because it delegates to the same sqflite or sqlite3 engines underneath; in fact it adds efficient cross-platform implementations with builtin isolate and web worker support, which raw sqflite does not give you out of the box. Fourth, when to advocate Drift: you should push for it when the project has non-trivial schema evolution, needs reactive UI updates, targets mobile plus desktop or web, or shares database logic with a backend via multi-dialect support.

COMMON WRONG ANSWERS: Claiming raw sqflite is universally faster because Drift has overhead. In reality Drift sits on top of the same native libraries and can even improve throughput via background isolate execution. Another red flag is saying Drift is only syntactic sugar; this misses the compile-time SQL lints, assisted migrations, and reliable migration unit tests that lower-level packages do not provide. A third mistake is ignoring the build_runner cost: a senior candidate should acknowledge code generation adds build complexity but argue the trade-off is worth it for non-trivial apps.

LIKELY FOLLOW-UPS: How would you migrate an existing sqflite database to Drift without losing user data? How do you test database migrations in Drift? When would you still drop down to raw SQL inside a Drift project? How does Drift handle web workers compared to standard sqflite?

ONE CONCRETE EXAMPLE: Suppose a fitness app tracks workouts, exercises, and sets with foreign-key relationships and needs offline-first reactive lists. With sqflite you would manually write JOIN strings, parse maps into models, and wrap everything in StreamControllers. With Drift you define tables in Dart or drift files, run build_runner to generate the database class, then write typed queries like select(workouts).join([innerJoin(exercises, exercises.workoutId.equalsExp(workouts.id))]) and watch the result as an auto-updating stream. If the app later adds a desktop target, Drift's builtin isolate and web worker support keeps the same query code working without rewriting platform channels.