Por qué existe: el problema de IndexedDB

IndexedDB no es una mala API: es una API que resuelve un problema distinto del que creemos tener. Lleva quince años siendo el único almacén serio del navegador y en ese tiempo la comunidad la ha usado para todo, incluido aquello para lo que no sirve —sostener por debajo otro motor de datos—, con resultados que van de lo mediocre a lo grotesco. OPFS aparece precisamente para deshacer ese apilamiento, y entender por qué exige mirar de cerca lo que un almacén de objetos no puede hacer por mucho que se le pida bien.

Lo que un almacén de objetos no puede darte

IndexedDB guarda valores completos bajo claves. Ese contrato tiene tres consecuencias que ninguna cantidad de ingenio en la capa de arriba puede esquivar.

La primera es que no existe la escritura parcial. No hay ninguna operación que diga escribe estos cuatro kilobytes en el offset 20.480.000 del valor asociado a esta clave. Solo puedes reemplazar el valor entero, y tampoco puedes leer un fragmento: recuperar un valor lo trae completo, aunque solo quieras mirar su cabecera. Si tu base de datos vive en un único valor de dos gigabytes, cambiar un registro reescribe dos gigabytes y consultarlo los materializa todos.

La salida obvia es trocear: una clave por página, y así el valor que reescribes es pequeño. Funciona, y es exactamente lo que se hizo durante años, pero acabas de convertir un fichero en un índice de decenas de miles de entradas donde antes había un offset aritmético, y cada acceso pasa a costar una búsqueda en un árbol ajeno en lugar de una suma.

La segunda es que cada valor cruza el algoritmo de clonado estructurado al entrar y al salir. Para un ArrayBuffer el coste tiende a ser una copia de memoria, pero sigue siendo una copia, y sobre estructuras ricas es serialización de verdad. Los bytes nunca son solo bytes, y en un motor que ya tiene su propio formato en disco esa traducción es puro trabajo perdido.

La tercera es que todo es asíncrono y transaccional, con un modelo de vida de la transacción tan sutil como hostil: la transacción se confirma sola cuando la cola de microtareas se vacía sin operaciones pendientes de ella, así que ceder el turno a cualquier promesa ajena la mata bajo tus pies. No hay forma de escribir una función que reciba una transacción y haga trabajo arbitrario dentro, que es justamente lo que un motor necesita para componer sus capas.

const tx = db.transaction('paginas', 'readwrite');
tx.objectStore('paginas').put(bloqueA, 5000);

await fetch('/telemetria');            // cede el turno al bucle de eventos

tx.objectStore('paginas').put(bloqueB, 5001);   // TransactionInactiveError

El desajuste de impedancias

Antes de OPFS, ejecutar SQLite en el navegador obligaba a un apilamiento absurdo. SQLite quiere leer y escribir páginas de cuatro kilobytes en offsets de un fichero, así que había que emular ese fichero troceándolo en registros de IndexedDB, una clave por página. El resultado es un árbol B —el de SQLite— sentado sobre otro árbol B —el del motor que implementa IndexedDB por dentro— que a su vez descansa sobre el sistema de ficheros real que se quería usar desde el principio.

flowchart TD
subgraph Emulando
  A1[Motor SQLite] --> A2[Capa que finge ser un fichero]
  A2 --> A3[IndexedDB con una clave por pagina]
  A3 --> A4[Motor interno del navegador]
  A4 --> A5[Sistema de ficheros real]
end
subgraph Directo
  B1[Motor SQLite] --> B2[OPFS con offsets reales]
  B2 --> B3[Sistema de ficheros real]
end

Cada nivel de esa torre paga su peaje: transacción, búsqueda en el índice, clonado, y una barrera que merece párrafo propio. Un motor escrito en C llama a leer una página y espera el resultado en la misma línea: su árbol B, su caché de páginas y su recuperación están escritos alrededor de esa suposición. IndexedDB solo sabe responder más tarde. Salvar esa distancia obliga a reescribir el binario para que pueda suspenderse y reanudarse en cada llamada, y eso multiplica su tamaño y hunde el rendimiento, o bien a apoyarse en la integración de promesas de WebAssembly, que es más limpia pero sigue siendo un puente sobre un abismo que no debería existir. La comparación desnuda es esta:

// Emulando un fichero sobre IndexedDB: leer la página 5000.
const tx = db.transaction('paginas', 'readonly');
const pagina = await comoPromesa(tx.objectStore('paginas').get(5000));
// coste: transacción + índice + clonado, para 4 KiB

// OPFS: los mismos 4 KiB, sin capas intermedias.
const archivo = await manejador.getFile();
const pagina = await archivo.slice(5000 * 4096, 5001 * 4096).arrayBuffer();

Y hay una segunda razón, menos obvia, para que el apilamiento sea malo incluso cuando el rendimiento aguanta: la atomicidad se duplica y no se compone. El motor de arriba tiene su propio protocolo para sobrevivir a un corte —escribir la intención en un registro, aplicar después, marcar el punto de consistencia— y ese protocolo depende del orden real en que las escrituras llegaron al disco. Al meterlo dentro de transacciones de IndexedDB, el orden que observa el motor deja de ser el orden que ocurre, porque hay una capa entre medias reordenando y agrupando según criterios propios. Puedes acabar con dos sistemas de recuperación que funcionan perfectamente por separado y que, juntos, no garantizan nada.

Lo que se construyó encima

Con un fichero real y un camino de acceso sin barrera asíncrona, la portabilidad de un motor de datos al navegador deja de ser un proyecto de investigación y pasa a ser un ejercicio de fontanería: se escribe una capa de ficheros virtual que traduce las operaciones del motor a las de OPFS, y el resto del código se compila sin tocar una línea. La forma de esa capa es sorprendentemente pequeña, y es la misma en Postgres, en SQLite y en cualquier árbol de fusión que quieras portar:

// La superficie mínima que un motor de almacenamiento espera del mundo.
const capaDeFicheros = {
  abrir(nombre)                 { /* devuelve un descriptor */ },
  leer(fd, destino, offset)     { /* llena destino desde offset */ },
  escribir(fd, origen, offset)  { /* escribe origen en offset */ },
  truncar(fd, tamano)           { /* fija el tamano */ },
  tamano(fd)                    { /* consulta el tamano */ },
  vaciar(fd)                    { /* fuerza la bajada a disco */ },
  cerrar(fd)                    { /* libera */ },
};

Siete funciones, y ninguna de ellas es expresable con fidelidad sobre un almacén de objetos: las tres primeras porque hablan de offsets que allí no existen, vaciar porque la durabilidad no está bajo tu control, y todas a la vez porque el motor las llama esperando una respuesta inmediata. Sobre OPFS, en cambio, se corresponden casi uno a uno con lo que la API ofrece —del todo cuando entras por el camino síncrono del nivel 10—.

El efecto de segundo orden es tal vez más importante que el rendimiento: al desaparecer la traducción, el mismo código de almacenamiento corre en el servidor y en el cliente. Un motor que habla con una capa de ficheros de siete funciones puede tener una implementación sobre el sistema de ficheros nativo y otra sobre OPFS, y el resto —el formato en disco, el protocolo de recuperación, las consultas— es idéntico y se prueba una sola vez. Esa unificación es la que hace realista mover la autoridad al cliente sin escribir dos productos.

Cuándo IndexedDB sigue siendo la respuesta

Nada de lo anterior condena a IndexedDB: lo devuelve a su sitio. Sigue siendo la elección correcta —y muchas veces la única sensata— cuando lo que necesitas es de verdad un almacén de objetos y no tienes ninguna intención de escribir un motor.

Encaja bien con metadatos y preferencias, con colas de trabajo pendientes de envío, con cachés de entidades que llegan de una API y se consultan por identificador, con manejadores de ficheros persistidos entre sesiones, y con cualquier caso donde quieras consultar por un campo que no es la clave, porque los índices secundarios te los da hechos y en OPFS tendrías que construirlos tú desde cero.

La regla de decisión cabe en una línea: si tu unidad natural de trabajo es un valor entero, quédate donde estás; si es un rango de bytes dentro de algo grande, has llegado a OPFS. Y la combinación de ambos es un patrón perfectamente respetable: el motor en OPFS para el volumen, e IndexedDB al lado para el puñado de registros de control que quieres poder consultar sin abrir nada.