El catálogo: las cuatro familias de bases locales

Cuando alguien pregunta qué base de datos usar en el cliente, la respuesta que circula es una lista de nombres ordenada por popularidad, y esa lista es inservible porque pone en la misma columna objetos que no son comparables. Un envoltorio de doscientas líneas sobre la API del navegador y un motor relacional completo compilado a WebAssembly no compiten por el mismo puesto: resuelven problemas distintos, cobran precios distintos y fallan de maneras distintas. Antes de comparar nombres hay que reconocer familias, porque la familia a la que pertenece una herramienta predice su techo, su peso y su modo de romperse mucho mejor que cualquier tabla comparativa de funcionalidades. Este nivel construye ese catálogo, y empieza por la única pregunta que de verdad las separa: dónde vive el motor que ejecuta tus consultas.

El criterio que agrupa

La pregunta que ordena el territorio no es cuánto pesa una librería ni qué sintaxis expone, sino esta: cuando pides datos filtrados y ordenados, quién ejecuta esa operación y sobre qué representación. Hay exactamente cuatro respuestas posibles en un navegador, y de cada una se deduce en línea recta un conjunto de consecuencias que ninguna decisión de diseño posterior puede revertir.

Conviene además situar el catálogo en su historia, porque explica por qué tiene esta forma y no otra. Durante mucho tiempo el cliente solo tuvo almacenamiento síncrono de cadenas y un motor de base de datos orientado a objetos con una API anterior a las promesas; todo lo que se construía encima era, necesariamente, un envoltorio. La aparición de un sistema de ficheros de origen privado con acceso de baja latencia cambió el suelo: por primera vez fue posible que un motor de bases de datos compilado a WebAssembly leyera y escribiera páginas con un coste comparable al que tiene fuera del navegador. Las familias segunda y cuarta son hijas de ese cambio, y por eso son las que más se están moviendo hoy. Las familias primera y tercera son anteriores, están estabilizadas y siguen siendo la respuesta correcta para más casos de los que la conversación pública sugiere.

flowchart TB
R[Bases locales en el cliente] --> F1[Envoltorios sobre IndexedDB]
R --> F2[Motores SQL compilados a WebAssembly]
R --> F3[Almacenes reactivos en memoria con persistencia]
R --> F4[Almacenes dentro de un motor de sincronizacion]
F1 --> M1[el motor es el del navegador y tu solo lo diriges]
F2 --> M2[el motor viaja contigo dentro del paquete]
F3 --> M3[el motor es la memoria y el disco es un respaldo]
F4 --> M4[el motor lo elige quien disena la replicacion]
style R fill:#cba6f7,color:#11111b
style M2 fill:#89b4fa,color:#11111b
style M4 fill:#a6e3a1,color:#11111b

Hay una manera práctica de aplicar el criterio sin leerse la arquitectura de nadie: mirar qué forma tiene la primera llamada que te obliga a hacer. Si te pide un nombre de almacén y un rango, el motor es del navegador. Si te pide una cadena de texto con una consulta, el motor viaja contigo. Si te devuelve un valor sin esperar, el estado ya estaba en memoria. Y si lo primero que te pide es una dirección de servidor o una definición de esquema compartido, lo que has adoptado es un motor de replicación con almacén incluido. Esa prueba de treinta segundos clasifica correctamente casi cualquier candidata y no requiere leer una sola línea de documentación.

Obsérvese que el diagrama no habla de rendimiento ni de ergonomía. Habla de propiedad del código: de quién es el código que decide cómo se recorre un índice. Esa titularidad determina el tamaño de lo que descargas, el modelo de datos que estás obligado a aceptar, la clase de consulta que puedes formular sin pagar un recorrido en memoria y, muy en particular, qué ocurre cuando el volumen crece un orden de magnitud por encima de lo que probaste.

Las cuatro familias

Hay además un rasgo que se aprecia leyendo las cuatro descripciones juntas y que conviene nombrar: la cantidad de decisiones que cada familia toma por ti crece de la primera a la cuarta, y con ella crece también lo que aportas cuando aciertas y lo que pierdes cuando te equivocas. Un envoltorio decide casi nada y por eso casi nunca estorba; un motor de sincronización decide casi todo y por eso, cuando encaja, ahorra meses, y cuando no encaja, no hay forma elegante de salir. Elegir en este nivel es en buena medida elegir cuánta autonomía estás dispuesto a ceder a cambio de cuánto trabajo te ahorras.

Las fronteras entre estas cuatro casillas no son impermeables, y los casos que las cruzan son instructivos precisamente por eso. Hay almacenes reactivos que ofrecen persistir sobre un motor SQL en WebAssembly, con lo que pertenecen a la tercera familia por su modelo de programación y toman prestado el sustrato de la segunda. Hay motores en WebAssembly que persisten dentro de IndexedDB, es decir, que usan a la primera familia como si fuera un disco de bloques. Y hay motores de sincronización cuyo almacén cliente es, por dentro, uno de los de las otras tres. Nada de esto invalida la clasificación: lo que hace es recordar que la pregunta correcta se formula por capas, y que un producto concreto puede responder distinto en cada una. Cuando evalúes una herramienta, pregunta separadamente qué modelo de programación te impone, qué motor ejecuta las consultas y sobre qué sustrato persiste, porque son tres decisiones distintas que a menudo vienen empaquetadas juntas.

Dónde vive el estado de verdad

Dentro de cada familia hay una variación que conviene no perder de vista, y es dónde reside la copia que se considera autorizada en tiempo de ejecución. En un envoltorio, el estado vive en disco y cada lectura lo va a buscar; la memoria solo contiene el resultado de la última consulta. En un motor en WebAssembly, el estado vive en el montón lineal del módulo mientras la base está abierta y baja a disco al confirmar, lo cual explica que su rendimiento dependa tanto del sistema de ficheros virtual que tenga debajo. En un almacén reactivo, el estado vive en memoria y el disco solo lo espeja. Y en un motor de sincronización, el estado vive en dos sitios a la vez por definición, que es justamente el problema que ese motor existe para resolver.

La pregunta de dónde vive la verdad tiene además una segunda parte que casi nunca se formula y que decide el comportamiento en el peor momento: qué pasa cuando la pestaña se cierra de golpe. Si el estado vive en disco y cada escritura confirmó una transacción, no pasa nada. Si vive en memoria con persistencia periódica, se pierde lo que hubiera entre el último volcado y el cierre, y el tamaño de esa ventana es una decisión de diseño tuya aunque nadie te la haya presentado como tal. Si vive en el montón de un módulo con un fichero abierto debajo, lo que ocurre depende de si el motor había confirmado sus páginas y de qué garantías ofrecía el sistema de ficheros virtual. Preguntar por esa ventana de pérdida, y responderla con un número, es una de las pocas cosas de este nivel que se puede hacer en cinco minutos y que evita un incidente entero.

Esta distinción no es teórica: se manifiesta en la primera línea de código que escribes con cada una.

// Familia 1: el motor es del navegador, tu expresas rangos sobre indices.
const recientes = await db.docs
  .where("actualizado")
  .above(desde)
  .limit(50)
  .toArray();

// Familia 2: el motor es tuyo, expresas intencion y el planifica.
const { rows } = await pg.query(`
  SELECT d.id, d.titulo, count(c.id) AS comentarios
  FROM docs d LEFT JOIN comentarios c ON c.doc_id = d.id
  WHERE d.actualizado > $1
  GROUP BY d.id, d.titulo
  ORDER BY comentarios DESC
  LIMIT 50
`, [desde]);

// Familia 3: el estado ya esta en memoria, leer es mirar.
const fila = store.getRow("docs", "d17");

// Familia 4: escribes local y alguien mas se ocupa de propagarlo.
const docs = z.query.docs.where("autorId", usuarioActual).limit(50);

Nótese que esta variable es ortogonal a la familia y no queda determinada por ella: dos herramientas de la misma casilla pueden colocar la verdad en sitios distintos, y ese detalle cambia por completo su comportamiento bajo presión de memoria, bajo cierre abrupto y bajo concurrencia. Por eso la clasificación en cuatro familias es un primer tamiz y no una respuesta: reduce el espacio de candidatas a un puñado, y a partir de ahí las preguntas se vuelven específicas.

De ahí se sigue una consecuencia que conviene tener presente al depurar. Cuando el estado vive en disco, un fallo de escritura es inmediato y localizable: la transacción aborta y tú te enteras. Cuando vive en memoria con un respaldo, la escritura en memoria puede triunfar y la persistencia fallar después, con lo que el usuario ve su cambio aplicado y la próxima sesión no lo encuentra; ese modo de fallo es silencioso y muchísimo más difícil de reproducir. Y cuando vive dentro del montón de un módulo compilado, un fallo puede manifestarse como corrupción del fichero subyacente en lugar de como una excepción, porque el motor asumía un contrato con el sistema de ficheros que el navegador no cumplió. No es que unas familias sean más fiables que otras: es que fallan en sitios distintos, y saber dónde mirar ahorra días.

La segunda familia tiene además una historia interna que ayuda a leer su presente. El primer uso conocido de SQLite dentro de un navegador se remonta a sql.js, de 2012, según la propia documentación del subproyecto WebAssembly de SQLite; absurd-sql demostró después que se podía guardar una base de SQLite dentro de IndexedDB, y wa-sqlite fue el primer sitio donde se implementó el almacenamiento sobre OPFS. Esa cronología explica por qué hoy conviven varias construcciones con la misma etiqueta de SQLite en el navegador: no son la misma cosa, y lo que las diferencia es precisamente el sistema de ficheros virtual que llevan debajo, que es el nivel donde de verdad se decide su rendimiento.

Esa cronología deja también una lección de método que va más allá de SQLite. Cuando un ecosistema resuelve un problema difícil, lo habitual no es que aparezca la solución definitiva de golpe, sino que se sucedan varias construcciones que exploran caminos distintos sobre el mismo sustrato, y que durante años convivan compartiendo nombre y divergiendo en lo esencial. Reconocer en qué punto de esa sucesión está lo que estás evaluando —si es la exploración inicial, la consolidación o el mantenimiento— informa la decisión tanto como cualquier medición, porque predice cuánto va a cambiar bajo tus pies.

Lo que ninguna familia te regala

Hay tres cosas que no aparecen en ningún catálogo y que vas a tener que resolver decidas lo que decidas. Un catálogo honesto de bases locales tiene que incluir estas tres columnas vacías, porque son exactamente donde se van las semanas de trabajo que nadie presupuestó.

La primera columna merece una advertencia adicional, porque su dificultad no es proporcional a lo que parece. Migrar de la versión uno a la dos es trivial; el problema aparece cuando llevas once versiones y alguien reaparece con la tres, porque entonces lo que se ejecuta es una cadena de ocho transformaciones que nadie ha probado nunca en ese orden concreto y sobre datos reales de aquella época. Ninguna de las cuatro familias resuelve eso por ti, y las estrategias que funcionan son las mismas en todas: conservar migraciones de prueba con datos de cada versión antigua, no borrar nunca una migración por muy vieja que parezca, y diseñar los cambios de esquema de forma aditiva siempre que sea posible, porque añadir un campo opcional no rompe a nadie y renombrarlo rompe a todo el mundo.

Merece la pena insistir en la tercera, porque es la que más varía entre familias y la que peor se documenta. Un envoltorio hereda el modelo transaccional del navegador, que ya resuelve la concurrencia entre contextos a nivel de transacción. Un motor en WebAssembly sobre un fichero puede necesitar acceso exclusivo, lo que obliga a que la base viva en un único contexto y a que los demás hablen con él por mensajes. Un almacén reactivo tiene por definición una copia en memoria por contexto y necesita un canal explícito para mantenerlas de acuerdo. Y un motor de sincronización trata este caso como un subconjunto trivial de su problema general, porque coordinar réplicas es exactamente para lo que existe. Son cuatro respuestas radicalmente distintas a la misma situación, y descubrir cuál te ha tocado el día que un usuario abre dos pestañas es el peor momento posible.