Why Room complains about the main thread? Analyzing the error and 3 ways to fix it

Introduction: why a "simple SELECT" turns into a headache

You are writing your first Android app with Room and Kotlin. Everything goes smoothly until you need to read data from the database. You write something like:

val user = userDao.getUserById(42)\ntextView.text = user.name

You run it — and the app crashes with an exception:

java.lang.IllegalStateException: Cannot access database on the main thread\nsince it may potentially lock the UI for a long period of time.

Familiar? This question on Stack Overflow has gathered thousands of views and hundreds of comments. The error scares beginners, but in reality it's not a bug — it's foolproof protection. Room (like any competent ORM) prevents you from accidentally blocking the user interface.

In this article, we will analyze why this happens and how to properly execute SELECT queries in Android Room with Kotlin. You will learn three proven approaches: LiveData, Coroutines, and RxJava. Let's go!

The gist: why does Room block the main thread?

Android is a single-threaded system by default. All UI runs on the main thread. If you start reading the database on this thread, the interface will freeze until the query completes. With large amounts of data, this can take seconds — the user will see a "hanging" app.

Room plays it safe: it forbids any long operations (reading, writing) on the main thread. The exception is if you explicitly allow this via .allowMainThreadQueries() when building the database. But you shouldn't do this — it's an anti-pattern.

Here's what a typical problem looks like:

// DAO\n@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    suspend fun getUserById(userId: Int): User  // suspend — already a hint!\n}\n\n// Activity\nclass MainActivity : AppCompatActivity() {\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n        // ❌ Error!\n        val user = database.userDao().getUserById(42)\n    }\n}

Even if you made the function suspend, but call it without a coroutine — Room will still throw an exception. Let's fix it!

Approach 1: LiveData — simple and reactive

The simplest way is to return LiveData from the DAO. Room manages the thread itself: the query runs in the background, and the result arrives in the UI.

Step 1. Modify the DAO

@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    fun getUserById(userId: Int): LiveData<User>\n}

Step 2. Subscribe in Activity/Fragment

class MainActivity : AppCompatActivity() {\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n\n        database.userDao().getUserById(42).observe(this) { user ->\n            textView.text = user.name\n        }\n    }\n}

Pros: minimal code, automatic unsubscription when the Activity is destroyed, reactivity — data updates automatically when the table changes.

Cons: LiveData is tied to the lifecycle, it's not easy to combine with other data sources (network, SharedPreferences).

Approach 2: Coroutines — the modern Kotlin way

If you are using Kotlin Coroutines (and you should), this is the most elegant way. The function is marked as suspend, and the call is wrapped in a coroutine with the correct Dispatchers.IO.

Step 1. DAO with suspend

@Dao\ninterface UserDao {\n    @Query("SELECT * FROM users WHERE id = :userId")\n    suspend fun getUserById(userId: Int): User\n}

Step 2. Call from ViewModel (recommended)

class MainVi