How it works
You describe tables as Kotlin data classes marked @Entity, and queries in a DAO (data access object) interface as functions with SQL in an @Query annotation. At build time Room's code generator, running under KSP, checks every query against the schema, so a misspelt column breaks the build instead of the app, and writes the code that maps rows to objects.
Queries can return a Flow, so a list on screen refreshes by itself when rows change. Schema changes are handled with migrations, many of which Room can generate automatically. Room gained Kotlin Multiplatform support, running on Android, iOS and desktop, and Room 3, released in 2026, is Kotlin-first, requires KSP and coroutines, and adds JavaScript and WebAssembly targets.
Room pros and cons
Pros
- SQL mistakes are caught at compile time
- Observable queries (Flow) keep the interface in sync with the data
- Handles migrations, transactions and threading for you
- Works in Kotlin Multiplatform, not only on Android
Cons
- Still needs SQL knowledge for anything beyond simple queries
- Code generation adds build time
- Each schema change needs a migration, or the update crashes or wipes local data
When to use Room
Pick it when
- Structured data kept on the device: offline lists, caches, drafts, history
- Apps that search, sort or relate records stored locally
Skip it when
- A few settings or flags, where DataStore is simpler
- Data that only lives on the server and is fetched fresh every time
Room pricing
Related terms
More in Mobile apps
Android building blocks