Database migrations in Android Kotlin - Build, Publish & Deploy

Build & Publish - Database migrations

Performance Impact of Database Migrations

Database migrations can temporarily slow app startup or screen loading because the app updates the database schema. If migrations are large or complex, they may cause noticeable delays or UI freezes. Properly done, migrations run quickly and avoid blocking the main thread, keeping frame rates smooth at 60fps. Memory use may increase briefly during migration but returns to normal after completion. Battery impact is minimal if migrations run only once per update.

💻

How to Optimize Database Migrations for 60fps Rendering

• Run migrations on a background thread to avoid blocking the UI.
• Keep migration scripts small and incremental to reduce processing time.
• Use efficient SQL commands and avoid unnecessary data copying.
• Test migrations on real devices to measure impact and adjust accordingly.
• Show a loading indicator if migration takes noticeable time to keep users informed.

Impact on App Bundle Size and Startup Time

Migration code adds minimal size to the app bundle, usually just a few kilobytes for SQL scripts or Kotlin code. However, complex migrations can increase startup time because the app must update the database before normal use. To reduce startup delays, defer non-critical migrations or split them into smaller steps across app launches.

iOS vs Android Differences for Database Migrations

On Android, Room database migrations are common and use Kotlin or Java code with SQL statements. Android apps can run migrations on background threads easily. On iOS, Core Data migrations use different APIs and may require mapping models or lightweight migration options. iOS migrations are integrated with UIKit or SwiftUI lifecycle. Android apps must handle APK updates and migration triggers explicitly, while iOS manages migrations during app launch automatically.

Relevant Store Review Guidelines and Requirements

• Google Play: Ensure migrations do not cause app crashes or ANRs (Application Not Responding) errors during updates.
• Apple App Store: Migrations must not cause app freezes or data loss; apps should handle schema changes gracefully.
• Both stores require apps to maintain user data integrity and avoid data corruption during updates.
• Provide clear user feedback if migration causes delays.

Self-Check: Your App Takes 5 Seconds to Load This Screen. What's Likely Wrong?

The database migration is probably running on the main thread, blocking the UI and causing a freeze. Another possibility is that the migration script is too large or inefficient, causing long processing time. To fix this, run migrations asynchronously and optimize migration steps.

Key Result

Database migrations can slow app startup if run on the main thread. Optimize by running migrations in the background with small incremental steps to keep UI smooth and meet store guidelines.

Practice

1.

What is the main purpose of a database migration in Android apps?

easy

A. To update the database schema without losing existing data

B. To delete all data and recreate the database from scratch

C. To backup the database to external storage

D. To optimize database queries for faster performance

Solution

1. Step 1: Understand database migration purpose

   Database migrations are used to change the structure of the database safely.

2. Step 2: Identify data preservation goal

   Migrations update tables or columns without deleting existing user data.

3. Final Answer:

   To update the database schema without losing existing data -> Option A

4. Quick Check:

   Migration = Safe schema update [OK]

Hint: Migrations keep data safe while changing schema [OK]

Common Mistakes:

• Thinking migrations delete all data
• Confusing migrations with backups
• Believing migrations only optimize queries

2.

Which of the following is the correct way to define a migration from version 1 to 2 in Room database?

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        // ?
    }
}

easy

A. database.execSQL("ALTER TABLE users ADD COLUMN age INTEGER DEFAULT 0")

B. database.update("users", "age", 0)

C. database.insert("users", ContentValues())

D. database.delete("users")

Solution

1. Step 1: Understand Migration class usage

   Migration requires SQL commands inside migrate() to change schema.

2. Step 2: Identify correct SQL command

   ALTER TABLE adds a new column safely; execSQL runs raw SQL.

3. Final Answer:

   database.execSQL("ALTER TABLE users ADD COLUMN age INTEGER DEFAULT 0") -> Option A

4. Quick Check:

   Migration uses execSQL with ALTER TABLE [OK]

Hint: Use execSQL with ALTER TABLE to add columns [OK]

Common Mistakes:

• Using update() instead of execSQL
• Trying to insert or delete rows in migration
• Not providing default value for new column

3.

Given this migration code, what will be the result after migrating from version 1 to 2?

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("CREATE TABLE IF NOT EXISTS books (id INTEGER PRIMARY KEY, title TEXT)")
    }
}

Assuming version 1 had no books table.

medium

A. No changes happen because CREATE TABLE is ignored

B. Migration fails because table 'books' already exists

C. A new table 'books' is created with columns 'id' and 'title'

D. Existing tables are deleted and only 'books' remains

Solution

1. Step 1: Analyze migration SQL command

   CREATE TABLE IF NOT EXISTS creates the table only if it doesn't exist.

2. Step 2: Check initial database state

   Version 1 has no 'books' table, so it will be created.

3. Final Answer:

   A new table 'books' is created with columns 'id' and 'title' -> Option C

4. Quick Check:

   CREATE TABLE IF NOT EXISTS creates missing table [OK]

Hint: IF NOT EXISTS avoids errors if table exists [OK]

Common Mistakes:

• Assuming migration fails if table exists
• Thinking CREATE TABLE is ignored
• Believing existing tables get deleted

4.

What is wrong with this migration code from version 2 to 3?

val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN email TEXT")
        database.execSQL("ALTER TABLE users ADD COLUMN email TEXT")
    }
}

medium

A. The migration does not update the database version

B. The same column 'email' is added twice causing an error

C. The SQL syntax for ALTER TABLE is incorrect

D. The migration should delete the 'users' table first

Solution

1. Step 1: Review SQL commands in migration

   The code tries to add the 'email' column twice to the same table.

2. Step 2: Understand SQLite behavior

   Adding the same column twice causes a runtime error during migration.

3. Final Answer:

   The same column 'email' is added twice causing an error -> Option B

4. Quick Check:

   Duplicate column addition causes migration failure [OK]

Hint: Avoid adding same column twice in one migration [OK]

Common Mistakes:

• Ignoring duplicate column errors
• Thinking migration version is updated automatically
• Believing ALTER TABLE syntax is wrong here

5.

You want to rename a column username to user_name in your Room database from version 3 to 4. SQLite does not support renaming columns directly. Which migration strategy is correct?

hard

A. Add a new column and leave the old column as is

B. Use ALTER TABLE to rename the column directly

C. Delete the old table and create a new one with the new column name

D. Create a new table with the new column name, copy data, drop old table, rename new table

Solution

1. Step 1: Understand SQLite column rename limitation

   SQLite does not support direct column renaming with ALTER TABLE.

2. Step 2: Apply recommended migration pattern

   Create a new table with desired schema, copy data, drop old table, rename new table.

3. Final Answer:

   Create a new table with the new column name, copy data, drop old table, rename new table -> Option D

4. Quick Check:

   Rename column = new table + copy data [OK]

Hint: Rename columns by new table + copy data [OK]

Common Mistakes:

• Trying to rename column with ALTER TABLE
• Deleting old table without copying data
• Adding new column but not removing old one