Back to services

Android Room

Room is the persistence library in Android Jetpack. It provides an abstraction layer on top of SQLite, letting developers access a local database more smoothly while keeping the full power of SQLite. It validates SQL queries at compile time and offers annotations that reduce boilerplate code.

View alternatives to Android Room
Contributor:
einverne
Suggest edit
Recent reviews

Alternatives

Website preview

Tech stack

No tech stack added yet. Sign in to suggest some

Room is part of Android Jetpack and is used to persist structured data in a local database within an app. The official documentation notes that the most common use is caching key data so that users can still browse that content when the device has no network connection. The official recommendation is to use Room rather than calling the SQLite APIs directly.

Three core components

  • Database class (Database): An abstract class annotated with @Database that extends RoomDatabase. It holds the database and is the main entry point for accessing the underlying persisted data connection. All associated entities must be listed in the annotation.
  • Data entity (Entity): Each entity class corresponds to a table in the database, and each instance corresponds to a row in that table. Entities are defined with annotations such as @Entity, @PrimaryKey and @ColumnInfo.
  • Data access object (DAO): An interface annotated with @Dao that performs queries, inserts, updates and deletes through functions annotated with @Query, @Insert, @Delete and so on.

The database class provides one abstract, zero-argument function for each DAO. The app reads entity objects through the DAOs, and can also use entities to create new rows or update existing ones.

Key benefits

  • SQL queries are validated at compile time, so errors surface during the build.
  • Convenient annotations reduce repetitive, error-prone boilerplate code.
  • Database migrations are simplified.
  • The official documentation provides guides on topics such as object relationships (one-to-one, one-to-many, many-to-many and nested relationships), asynchronous DAO queries, database views, prepopulated databases, migrations, and testing and debugging.
  • The official documentation provides a guide for migrating from SQLite to Room, as well as a guide for migrating from Room 2.x to Room 3.0.
  • Kotlin Multiplatform is supported, so the database layer can be shared with other platforms.

Installation and usage

Add the dependencies to the module's build.gradle.kts. The current official documentation shows Room 3.0 (example version 3.0.3), which requires KSP for annotation processing:

dependencies {
    val room_version = "3.0.3"

    implementation("androidx.room3:room3-runtime:$room_version")
    ksp("androidx.room3:room3-compiler:$room_version")
}

Next, define the entities, DAOs and database class, then create a database instance with Room.databaseBuilder. In the official example, the DAO functions are Kotlin suspend functions, and the driver is specified with setDriver(AndroidSQLiteDriver()).

Things to note

  • Single-process apps should create the database instance as a singleton, because each RoomDatabase instance is expensive and you typically don't need more than one.
  • Multi-process apps can call enableMultiInstanceInvalidation() when building the database so that invalidation notifications in one process are automatically propagated to instances in other processes.
  • Room is intended for on-device data persistence. If you need cross-device sync, real-time collaboration or a cloud backend with offline support, the official recommendation is to pair Room with WorkManager and your own backend, or to use managed cloud services such as Cloud Firestore or Firebase SQL Connect.

Who it's for

It suits Android developers who need to store and query structured data locally, as well as teams that want to share a database layer using Kotlin Multiplatform.