Room 3.0 Migration Guide: From KAPT to KSP, Coroutines-First APIs, and KMP Web Support

TL;DR

Room 3.0 is the biggest version bump since Room shipped. It drops KAPT entirely for KSP-only annotation processing, generates Kotlin instead of Java, defaults to a coroutines-first API surface that deprecates the old synchronous and RxJava paths, and adds a web target for Kotlin Multiplatform. If you’re still on KAPT, the build time savings alone justify migrating. This post covers what you need to change and why.

Why Room 3.0 is a breaking change worth making

I’ve been building production systems with Room since its 1.0 alpha days, and every major version has demanded careful migration. 3.0 is different, though. It’s not adding features on top of the old foundation. It’s replacing the foundation. Google has made the direction clear: AndroidX persistence is going Kotlin-native, coroutine-driven, and multiplatform.

KSP processes annotations 2-3x faster than KAPT on incremental builds, and Room 3.0 leans fully into that by dropping KAPT support entirely.

What changed: the full comparison

Feature	Room 2.6.x	Room 3.0
Annotation Processor	KAPT + KSP	KSP only
Generated Code	Java	Kotlin
Primary API Surface	Sync + RxJava + Coroutines	Coroutines-first (Flow, suspend)
RxJava Support	Built-in	Separate compatibility artifact
KMP Targets	Android, iOS, JVM, Native	+ Web (Wasm/JS)
Minimum Kotlin Version	1.8+	2.0+
Minimum KSP Version	1.x	2.x (aligned with Kotlin 2.0 compiler)

Step 1: drop KAPT, switch to KSP

If you haven’t migrated to KSP yet, this is no longer optional. Remove the KAPT plugin and replace it with KSP in your module-level build.gradle.kts:

plugins {
    // Remove: id("org.jetbrains.kotlin.kapt")
    id("com.google.devtools.ksp") version "2.0.21-1.0.28"
}

dependencies {
    // Remove: kapt("androidx.room:room-compiler:2.6.1")
    ksp("androidx.room:room-compiler:3.0.0")
}

Then delete any kapt { } configuration blocks. In projects I’ve migrated, this single change shaved 15-30 seconds off incremental builds on a mid-size project (~200 entities). On a large-scale project with 500+ entities, we measured a 40% reduction in annotation processing time.

Watch out: if other libraries still use KAPT (Dagger/Hilt, for example), you can run both plugins simultaneously. But aim to eliminate KAPT entirely. Mixed mode negates much of the KSP speed gain because KAPT still triggers a full kaptGenerateStubs task.

Step 2: adopt coroutines-first APIs

Room 3.0 makes suspend functions and Flow returns the default contract. The old synchronous DAO methods and LiveData returns still compile, but the generated code now wraps them through coroutine internals rather than the other way around.

Most teams get this wrong: they assume their existing LiveData-returning DAOs are fine because they still compile. They are. But they now carry overhead from an unnecessary coroutine-to-LiveData bridge.

Before (Room 2.x pattern):

@Dao
interface UserDao {
    @Query("SELECT * FROM users WHERE id = :id")
    fun getUserById(id: Long): LiveData<User?>

    @Insert
    fun insertUser(user: User): Long
}

After (Room 3.0 idiomatic):

@Dao
interface UserDao {
    @Query("SELECT * FROM users WHERE id = :id")
    fun getUserById(id: Long): Flow<User?>

    @Insert
    suspend fun insertUser(user: User): Long
}

If your UI layer still needs LiveData, convert at the ViewModel boundary with flow.asLiveData() rather than baking it into your data layer. This keeps your DAOs multiplatform-compatible.

Step 3: unlock KMP web support

Room 3.0 adds a web target using SQLite compiled to WebAssembly. The setup requires the driver-based architecture introduced in Room 2.7:

// In commonMain
dependencies {
    implementation("androidx.room:room-runtime:3.0.0")
    implementation("androidx.sqlite:sqlite-bundled:3.0.0")
}

// In wasmJsMain
dependencies {
    implementation("androidx.sqlite:sqlite-driver-wasm:3.0.0")
}

The architecture works like this: Room’s KMP strategy uses the RoomDatabase.Builder pattern with platform-specific SQLiteDriver implementations. On Android, you get the framework SQLite. On iOS and desktop, you get the bundled native SQLite. On web, you get a Wasm-compiled SQLite backed by Origin Private File System (OPFS) for persistence.

One real limitation: the web driver runs SQLite in a Web Worker. All database operations are inherently asynchronous, which is exactly why the coroutines-first API matters. Synchronous DAO methods cannot work on the web target at all.

Migration checklist

Task	Risk Level	Effort
Replace KAPT with KSP plugin	Low	30 min
Update Room dependency to 3.0.0	Low	15 min
Bump Kotlin to 2.0+ and KSP to 2.x	Medium	1-3 hours (compiler plugin compat)
Convert sync DAO methods to suspend	Medium	Varies by project size
Convert LiveData returns to Flow	Medium	Requires ViewModel-layer changes
Remove RxJava room artifact or swap to compat lib	Low	30 min
Add web target (if using KMP)	High	1-2 days (driver setup + testing)

Actionable takeaways

Migrate to KSP immediately, even before Room 3.0. You get the build speed win today, and it removes the hardest blocker for the 3.0 upgrade. If Hilt is holding you back, Hilt has supported KSP since 2.5.0. No more excuses.
Refactor DAOs to suspend + Flow before bumping the Room version. This is backward-compatible with Room 2.6.x and lets you decouple the API migration from the dependency migration. Ship them as separate PRs with separate rollback paths.
Treat the web target as experimental for production use. The OPFS-backed SQLite driver works, but storage quotas, browser compatibility edge cases, and cold-start performance need real-world validation. Start with a shared KMP module and add the web target behind a feature flag.