Room vs SQLDelight: cómo elegir la base de datos local para Android y Kotlin Multiplatform

Elegir una base de datos local no consiste solo en guardar datos: condiciona la forma de modelar el dominio, escribir consultas, gestionar migraciones y compartir código entre plataformas. Room y SQLDelight se apoyan en SQLite, ofrecen validación en compilación y reducen el código repetitivo, pero cada una prioriza una experiencia diferente.

Room destaca por su integración con el ecosistema Android y un modelo centrado en anotaciones y DAOs. SQLDelight, en cambio, coloca SQL en el centro y genera APIs Kotlin tipadas a partir de las consultas. La decisión depende más de la arquitectura y del alcance de tu aplicación que de cuál tenga “más características”.

Qué propone Room

Room es la capa de persistencia de Jetpack sobre SQLite. Define tablas mediante clases anotadas con @Entity, centraliza el acceso en interfaces @Dao y genera la implementación necesaria durante la compilación. También valida las consultas SQL declaradas en anotaciones. (Android Developers)

Un ejemplo típico en una app Android sería este:

@Entity(tableName = "tasks")
data class TaskEntity(
    @PrimaryKey val id: Long,
    val title: String,
    val completed: Boolean
)

@Dao
interface TaskDao {

    @Query("SELECT * FROM tasks ORDER BY id DESC")
    fun observeTasks(): Flow<List<TaskEntity>>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun save(task: TaskEntity)

    @Query("UPDATE tasks SET completed = :completed WHERE id = :id")
    suspend fun updateCompletion(id: Long, completed: Boolean)
}

El código transmite bien la intención para equipos acostumbrados a Jetpack: una entidad representa una tabla y el DAO declara operaciones. Room genera la implementación y se encarga del mapeo entre filas SQLite y objetos Kotlin.

Además, Room encaja de forma natural con componentes habituales de Android como Flow, Paging y la arquitectura basada en repositorios. Por ejemplo, puede actuar como fuente local de verdad en flujos de caché y paginación. (Android Developers)

Qué propone SQLDelight

SQLDelight adopta la dirección inversa: primero escribes el esquema y las consultas SQL; después, la herramienta genera APIs Kotlin tipadas para ejecutarlas. Verifica en compilación el esquema, las sentencias y las migraciones, y aprovecha el IDE para autocompletado y refactorización. (Cash App)

Una consulta en un archivo Task.sq podría verse así:

CREATE TABLE task (
  id INTEGER NOT NULL PRIMARY KEY,
  title TEXT NOT NULL,
  completed INTEGER AS Boolean NOT NULL
);

selectAll:
SELECT *
FROM task
ORDER BY id DESC;

insertTask:
INSERT OR REPLACE INTO task(id, title, completed)
VALUES (?, ?, ?);

updateCompletion:
UPDATE task
SET completed = ?
WHERE id = ?;

A partir de ese archivo, SQLDelight genera una interfaz de consultas. El código Kotlin consume métodos derivados de los nombres que has dado a cada sentencia:

class TaskLocalDataSource(
    private val queries: TaskQueries
) {
    fun observeTasks() =
        queries.selectAll()
            .asFlow()
            .mapToList(Dispatchers.Default)

    fun save(id: Long, title: String, completed: Boolean) {
        queries.insertTask(id, title, completed)
    }

    fun updateCompletion(id: Long, completed: Boolean) {
        queries.updateCompletion(completed, id)
    }
}

Aquí no hay una capa de anotaciones que oculte SQL. La consulta es el contrato principal, algo especialmente valioso cuando el equipo necesita optimizar índices, JOIN, vistas, agregaciones o consultas complejas sin escapar del modelo de la librería.

Diferencias importantes

Aspecto	Room	SQLDelight
Enfoque principal	Kotlin y anotaciones	SQL como fuente de verdad
Definición de consultas	Anotaciones como @Query	Archivos .sq
Curva inicial	Muy cómoda para Android	Requiere soltura con SQL
Integración Android	Excelente y directa	Buena, pero menos ligada a Jetpack
Kotlin Multiplatform	Compatible con proyectos KMP	Diseñado con enfoque multiplataforma
Consultas complejas	Posibles, pero pueden crecer dentro de strings	Muy expresivas y visibles en archivos SQL
Migraciones	Basadas en versiones y Migration	Versionadas junto al esquema SQL

Room sigue siendo una opción muy sólida para aplicaciones Android puras. Su integración con Jetpack reduce decisiones técnicas y permite que un equipo avance rápido con convenciones conocidas. Android también documenta su uso dentro de proyectos Kotlin Multiplatform, por lo que ya no debe descartarse automáticamente al compartir la capa de datos. (Android Developers)

SQLDelight suele resultar especialmente atractivo cuando SQL forma parte importante del diseño de la aplicación. Al separar esquema y consultas en archivos dedicados, facilita revisar cambios de base de datos en pull requests y evita ocultar consultas largas en anotaciones Kotlin.

Cuándo elegir Room

Room es una buena elección cuando:

• La aplicación tiene Android como plataforma principal.
• El equipo trabaja intensamente con Jetpack Compose, ViewModel, Paging y Flow.
• El modelo de datos es relativamente directo.
• Quieres minimizar la cantidad de SQL visible sin perder validación en compilación.
• Priorizas una experiencia consistente con las guías y herramientas oficiales de Android.

También es una alternativa cómoda cuando la base local funciona como caché, almacén de preferencias estructuradas o fuente de datos para listas paginadas.

Cuándo elegir SQLDelight

SQLDelight encaja mejor cuando:

• El proyecto comparte la capa de datos entre Android, iOS, escritorio u otros destinos.
• Las consultas SQL son complejas o constituyen una parte relevante de la lógica.
• El equipo quiere revisar el esquema y las migraciones como SQL explícito.
• Necesitas mantener un control cercano sobre cómo SQLite ejecuta cada operación.
• La portabilidad de la capa de persistencia es un requisito desde el inicio.

Conclusión

Room y SQLDelight no compiten exactamente en el mismo terreno. Room ofrece una experiencia Kotlin-first, muy alineada con Android y Jetpack. SQLDelight propone una experiencia SQL-first, con generación de código tipado y una estructura especialmente clara para proyectos multiplataforma.

Para una app Android convencional, Room suele ser la decisión pragmática. Para una capa de datos compartida o un dominio donde SQL tiene peso propio, SQLDelight aporta más control y transparencia. La mejor elección es la que deja a tu equipo entender, evolucionar y probar la base de datos con menos fricción.