ElectricSQL: el pivote a solo lectura y las cuatro escrituras que te quedan

La historia de ElectricSQL es la más instructiva del sector porque es la de un proyecto que renunció en público a la mitad de su ambición y salió reforzado. La primera Electric quería ser el sistema completo: base de datos embebida en el cliente, CRDT para converger, sincronización bidireccional, todo resuelto. Aquello funcionaba en las demostraciones y se volvía inmanejable en producción, y en 2024 el equipo hizo lo que casi nadie hace: reescribir el producto para que hiciera una sola cosa. La Electric de hoy es un servicio que emite filas de Postgres a los clientes por HTTP y no sabe nada de escrituras. Esa amputación deliberada le dio dos cosas que el diseño anterior nunca habría tenido —una operación trivialmente cacheable en cualquier CDN y una superficie conceptual que cabe en una tarde— al precio de devolverte a ti un problema entero, el del camino de escritura, que ahora tienes que resolver eligiendo entre patrones que su propia documentación se molesta en enumerar y comparar.

Lo primero que conviene fijar es el vocabulario, porque Electric usa una palabra propia para su unidad de sincronización. Una forma es una vista filtrada sobre una tabla de Postgres que el servicio mantiene al día. No la defines por adelantado en un fichero de configuración: la pides, y el servicio la crea al vuelo consultando Postgres y convirtiendo el resultado en operaciones de inserción. La consecuencia práctica es que no existe una fase de despliegue de reglas de sincronización, y eso simplifica el ciclo de desarrollo de una manera que se nota desde el primer día.

El registro de forma: un log, no un estado

Lo que el cliente recibe cuando sincroniza una forma no es una tabla ni un documento, sino un registro de operaciones lógicas sobre esa forma. La documentación lo llama registro de forma y lo compara con el flujo de replicación lógica de Postgres, con la diferencia de que en lugar de recibir todas las operaciones de la base recibes solo las que afectan a tu forma. Materializar el valor actual a partir de ese registro es responsabilidad del cliente.

# Peticion inicial: dame el log entero de esta forma
curl -i 'http://localhost:3000/v1/shape?table=todos&offset=-1'

# Modo en vivo: la conexion queda abierta esperando novedades
curl -i 'http://localhost:3000/v1/shape?table=todos&live=true&handle=...&offset=0_0'

La primera petición lleva un desplazamiento con valor menos uno, que significa dame el log entero desde el principio. Si el log no cabe en una respuesta, el servidor devuelve un lote y una cabecera con el desplazamiento siguiente, y el cliente pagina hasta agotarlo. Al final aparece un mensaje de control que anuncia que el cliente está al día, y a partir de ahí puede pasar al modo en vivo. Existe un segundo mensaje de control, el que ordena volver a sincronizar desde cero, y su existencia es una declaración de intenciones: Electric prefiere pedir al cliente que tire su copia y empiece de nuevo antes que intentar reparaciones sutiles cuyo estado final nadie pueda demostrar.

flowchart TD
A[peticion inicial con desplazamiento menos uno] --> B[el servicio consulta postgres y crea el log]
B --> C{cabe en una respuesta}
C -->|no| D[lote mas cabecera de desplazamiento] --> A
C -->|si| E[mensaje de control al dia]
E --> F[modo en vivo]
F --> G[espera larga o eventos enviados por el servidor]
G --> H[nuevas operaciones] --> F
E -.-> I[mensaje de control volver a sincronizar]
I --> A
style E fill:#a6e3a1,color:#11111b
style I fill:#f38ba8,color:#11111b
style F fill:#89b4fa,color:#11111b

Un detalle que revela la mentalidad del diseño: los valores del registro viajan como cadenas formateadas según la configuración de presentación de Postgres, y la especificación abierta del servicio documenta exactamente cuál es esa configuración. No hay serialización propia ni tipos inventados. Quien quiera escribir un cliente en un lenguaje sin soporte oficial —el proyecto anima explícitamente a hacerlo— solo necesita saber leer JSON y aplicar el mismo conversor de tipos que aplicaría al leer de Postgres.

// Entrada del registro de forma
{ "headers": { "operation": "insert" }, "key": "1", "value": { "id": "1", "title": "Hola" } }

// Mensajes de control: al dia, y volver a sincronizar desde cero
{ "headers": { "control": "up-to-date" } }
{ "headers": { "control": "must-refetch" } }

El servicio ha ido incorporando modos que refinan esa mecánica sin cambiarla de raíz. Se puede pedir el registro sin instantánea inicial, de modo que el cliente solo reciba lo que ocurra a partir de ese momento, útil cuando el estado inicial llega por otra vía o simplemente no interesa. Se puede arrancar desde ahora para saltarse toda la historia. Y sobre ese modo sin instantánea se pueden pedir instantáneas parciales con filtro, orden y límite, que la documentación recomienda solicitar por POST porque las cláusulas de filtrado con muchos parámetros revientan la longitud máxima de una URL. Todo ello son extensiones del mismo mecanismo: pedir un trozo de log e indicar por dónde vas.

El modo en vivo admite dos transportes. El clásico es la espera larga: el cliente pide con el parámetro de vivo y el servidor retiene la conexión hasta que haya datos o venza un tiempo. El añadido posterior son los eventos enviados por el servidor, que evitan reconectar tras cada mensaje y bajan la latencia cuando los mensajes son pequeños y frecuentes. La documentación advierte de que esa segunda vía exige que ningún proxy intermedio almacene la respuesta antes de reenviarla, y describe el remedio para los servidores más comunes; el cliente oficial además detecta que la conexión se cierra de inmediato y, tras varios intentos, vuelve por sí solo a la espera larga.

Lo que te devuelven: cuatro patrones de escritura

Aquí está la mitad honesta del pivote. La documentación lo dice con todas las letras: Electric hace sincronización del camino de lectura, no del de escritura, y no proporciona ni prescribe una solución para devolver datos a Postgres. Su filosofía es componer con tu pila existente. Lo que sí ofrece es una guía que enumera cuatro patrones ordenados de menos a más potente, con su código y sus contrapartidas.

// Patron 3: el estado optimista vive fuera del componente y sobrevive a la recarga
const estadoOptimista = proxyMap(JSON.parse(localStorage.getItem(CLAVE) ?? "[]"));
subscribe(estadoOptimista, () => {
  localStorage.setItem(CLAVE, JSON.stringify([...estadoOptimista]));
});

// La escritura local se retira cuando vuelve por la forma, no cuando responde la API
async function emparejar(stream, escritura) {
  await matchStream(stream, [escritura.operacion], porIdentificador(escritura));
  estadoOptimista.delete(escritura.id);
}

Que el proyecto documente cuatro caminos en lugar de imponer uno no es indecisión: es la consecuencia lógica de haber decidido no ocuparse del asunto. Y conviene apreciar el valor pedagógico del gesto, porque esos cuatro patrones no son específicos de Electric. Son el espacio completo de soluciones al problema de la escritura optimista, y cualquier equipo que construya sobre cualquier motor acabará ocupando uno de esos cuatro puntos, lo sepa o no.

Fíjate además en un detalle del tercer patrón que es la clave de que funcione bien y que casi nadie implementa por su cuenta: el estado optimista no se retira cuando la API responde, sino cuando el cambio vuelve por el flujo de sincronización. Retirarlo al responder la API produce un parpadeo, porque durante unos milisegundos la escritura ya no está en lo local y todavía no ha llegado por la forma. Esperar a que vuelva cuesta un poco más de código y elimina el parpadeo por completo. Es la clase de detalle que separa una demostración de un producto.

Una recomendación de seguridad que la guía repite y que conviene no saltarse: aunque la API HTTP se documente como si el navegador hablara directamente con el servicio, en producción las peticiones deben pasar por tu backend, que es donde se autentica al usuario y se decide qué formas puede pedir. Exponer el servicio directamente equivale a publicar un lector universal de tus tablas.

Qué simplifica de verdad y qué no

Puesto en la balanza, el pivote de Electric simplifica cuatro cosas y ninguna de ellas es cosmética. Elimina el CRDT del cliente, y con él la clase entera de problemas que ocupa quince niveles de este track: metadatos que crecen, lápidas que no se pueden tirar, compactación, historia que pesa. Elimina el despliegue de reglas de sincronización, porque las formas se piden y se crean solas. Elimina la infraestructura de tiempo real, porque el transporte es HTTP y el escalado lo hace el CDN. Y elimina la base de datos embebida del camino obligatorio: puedes usar una si quieres, pero el cliente por defecto materializa la forma en memoria y el navegador se encarga de cachear.

Hay un dato empírico que la propia guía recoge y que conviene tener presente antes de sobredimensionar la maquinaria de fusión. Adam Wiggins, uno de los autores del ensayo fundacional sobre local-first, informó tras operar a escala una herramienta de lienzo colaborativo que los conflictos reales son extremadamente infrecuentes y que se mitigan bien con recursos de producto como mostrar quién está editando qué. La conclusión que la guía extrae es sensata y va contra el instinto del ingeniero: las estrategias romas —borrar lo local y volver a sincronizar— son mucho más fáciles de implementar y razonar, y resultan perfectamente adecuadas para la mayoría de las aplicaciones. Construir rebasado fino antes de haber medido la tasa de conflictos es optimizar un caso que quizá no existe.

Lo que no simplifica es todo lo que ocurre después de que el usuario pulse algo. Ahí sigues tú, con tu API, tu validación, tu política de conflictos y tu estrategia de reversión. La pregunta que hay que hacerse antes de adoptar Electric no es si su modelo de lectura es bueno —lo es, y es probablemente el más elegante del sector— sino si el patrón de escritura que tu aplicación necesita es uno de los dos primeros, en cuyo caso el trabajo es menor, o uno de los dos últimos, en cuyo caso estarás construyendo a mano lo que otros motores traen puesto.