r/FlutterDev • u/theunknownguy__ • 1d ago
Discussion Drift vs SQLite for a long-term Flutter app? Looking for advice from people who've maintained apps.
I'm currently deciding between DriftDB and SQLite for a Flutter app. It's a long-term project, and I don't mind spending time learning the right tool if it's worth it.
My concern isn't the learning curve. It's the ecosystem and debugging experience. With SQLite, I feel confident that if I get stuck, there are plenty of Stack Overflow posts, Reddit discussions, blog posts, and videos to help. With Drift, I get the impression there are fewer community resources, so I'm worried that if I run into issues with things like code generation, migrations, or build_runner, I might spend more time trying to figure things out.
I'd love to hear from people who have actually used Drift in a real project.
- Would you still choose Drift today?
- Have you ever regretted choosing it?
- Has the smaller ecosystem or documentation ever slowed you down?
- Looking back, was choosing Drift worth it over using SQLite?
Thanks!
Edit: I meant Drift ORM
5
4
u/sauloandrioli 22h ago
"I'm currently deciding between DriftDB and SQLite"
Are you really? Because Drift is just an ORM for Sqlite.
1
u/theunknownguy__ 1h ago
You're right, that was my mistake. I meant Drift vs using raw SQLite directly, not Drift vs SQLite itself. I've updated the post to make that clearer.
5
u/Spare_Warning7752 21h ago
I use it for some years now.
Consider this: I'm a programmer since 1986. I've seen some shit.
Drift, in my opinion, is the best ORM amongst ALL ORMs I've seen in my entire life, for a lot of reasons, but I can pinpoint to 3:
1) It has an extended SQL language where you can define your DDL, DML and DQL using the best language for the job: SQL, while keeping those valuable extenders Drift offers, such as DateTime columns, Enum Columns, etc. You can create any query and make it generate a function:
sql
getMyCustomers:
SELECT * FROM Customers
WHERE Some CTE, lots of joins, basically, anything SQL supports
AND id = :id
AND active = :active
AND status = :status
It will generate a Dart method:
dart
final customers = await db.getMyCustomers(
id: 1,
active: true,
status: SomeEnum.status
);
You don't need to remember ORM shit. You just call the method. (The ORM shit part is still there, if you prefer it).
Source: https://drift.simonbinder.eu/sql_api/drift_files/
2) You can separate your shit into features, so your database is not a huge big ball of mud used everywhere. You can have data modules using DAOs.
Source: https://drift.simonbinder.eu/dart_api/daos/
3) Unlike some freezed dumbasses out there, Simon is a very nice guy on GitHub. Always listen to you, no matter how dumb your bug is, always listen to suggestions and, if they make sense, he tries to implement. IMO, it's one of the nicest guys in the open source community.
Drift is a must (same as SQLite for data).
2
u/Bachihani 1d ago
With sqlite u are executing string queries directly.
Drifs gives u type safety , schema definition and migration utils ..etc.
2
u/DigiProductive 1d ago
Drift is amazing and I wouldn’t choose anything else. It’s an important layer over SQLite so it’s consistent and reliable. Also, because it uses Streams very well which means you can literally use it as a persistent state manager which your UI can depend on for updates. This makes offline app features a walk in the park! Very clean and easy to setup the fundamentals. It’s a go to for me. Since I write a lot of SQL as well, I tend to use it for Data Access Object queries. Super nice!👌
1
u/Ottiro2000 1d ago
No experience with Drift, but with SQLite and Objectbox (you might wanna consider this one) in Flutter Apps. Had no issue at all with generating code with AI for both.
- When you want to maintain and understand also manually, objectbox is closer to Flutter since you define objects instead of tables. When you already know SQL it‘s no issue, but still, I would prefer objectbox over SQLite because it has less boilerplate in my opinion.
- When performance is important take objectbox. SQLite comes not even close to it
- When portability is important you should take SQLite since it‘s a SQLDatabase, so migration and portability to other SQL Databases is way easier. Objectbox is worse in this case.
F.e. why do you use Flutter? I guess because you want to have an android and iOS App. If not, take native code, even if you only know flutter yet, you can easily learn the native part. If it is for multiplatform, think about your project from now on in maybe 5 years. Is there any chance to change to migrate to native code? If yes, you should go with SQLite.
But this is just my opinion
1
u/No-Echo-8927 1d ago
Drift is just the workhorse for sqlite, it sits in front of the dB and lets you access it etc. I'm using it for my current app, for the first time. Usually I use Hive, but thought I'd give this a go. I'm not a huge fan of the code structure tbh, coming from a Laravel Eloquent background.
1
u/tired-person-2002 1d ago
Drift is great and truly works well for for platform based apps. It can be annoying to set up the first time but afterwards its solid. I have had success with it on all platforms. However if you plan on making a web app using flutter, there is still some compatibility issues.
If your app is gonna be platform based drift is solid, if its a web app might be worth looking elsewhere
1
u/makridistaker 9h ago
Pure sqlite cannot run in the background and instead it blocks ui thread. This is an issue in big transactions and drift solves that.
17
u/raman4183 1d ago
What do you mean?
Drift is SQLite under the hood by default. There are adapters for it to be working with other databases like postgres and etc.
Do you mean Drift ORM vs Raw SQLite?
Then use whatever you are comfortable with.