What we build with it
SQLite is the database that travels with the app. On mobile it is where a product keeps the data it must be able to read with the network off: cached API responses, drafts the user has not submitted yet, message history, and the queue of writes waiting to sync.
It is a real relational database rather than a key-value store, which matters more than it sounds. Once local data has relationships and needs filtering or sorting, doing that in SQL beats loading everything into memory and doing it in Dart — especially on the lists that have to stay smooth while scrolling.
Where it fits
Every offline-capable app has this layer whether it is designed or not. Our work here is usually making it deliberate: a schema with migrations, a clear rule for what is cached versus authoritative, and a sync strategy that survives the app being killed mid-write.
When we recommend it
For on-device persistence beyond a handful of values, and for any product whose users are on trains, in basements, or on mobile data they would rather not spend.
For a few flags and preferences, SQLite is more than the job needs — simple key-value storage is fine, and adding migrations to store a boolean is a cost with no return. And it is a local database, not a backend: the server side of the same product belongs in PostgreSQL.