Cómo elegir: cuatro cortes, un árbol y el coste de salida

Las cuatro lecciones anteriores describieron cinco motores con sus documentaciones delante, y a estas alturas la tentación es montar una tabla comparativa con veinte filas y dejar que gane el que más casillas verdes tenga. Esa tabla sería inútil por un motivo estructural: casi todas sus filas miden funcionalidades intercambiables, mientras que la decisión real la determinan cuatro preguntas que no se negocian y cuyas respuestas ya conoces antes de mirar ningún motor. Dónde vive hoy tu fuente de verdad, cuánto tiempo tienen que aguantar tus usuarios sin red, qué forma tiene tu control de acceso y cuánto te dolería tener que cambiar de motor dentro de tres años. Ordenadas así, esas preguntas eliminan candidatos en cascada y dejan casi siempre uno o dos en pie, sin necesidad de comparar rendimientos que nadie ha medido en tu caso. Esta lección construye ese árbol, señala los sitios donde miente y termina con el único número que no envejece: lo que cuesta salir.

El orden de las preguntas importa tanto como las preguntas. Se empieza por la base de datos existente porque es la restricción más dura y la que menos depende de ti; se sigue por el comportamiento sin red porque parte en dos el espacio restante; se continúa por los permisos porque es donde se paga el coste de ingeniería que nadie presupuesta; y se termina por la dependencia porque es la única que puede revertir todo lo anterior cuando la respuesta es extrema.

Conviene además ver la relación entre este árbol y los ejes del nivel anterior, porque no son dos herramientas rivales sino dos usos del mismo mapa. Allí se levantaron tres ejes —autoridad, unidad de sincronización y alcance— para describir el espacio de motores posibles; aquí se ordenan cuatro preguntas para recorrerlo con un proyecto concreto en la mano. Los ejes explican por qué dos motores se parecen o no; el árbol te dice cuál te toca. Si el árbol te lleva a un sitio que te sorprende, la forma productiva de dudar no es rehacer el árbol sino volver a los ejes y comprobar qué respuesta sobre la autoridad estabas dando sin saberlo.

Los cuatro cortes, en orden

Primer corte: tu fuente de verdad. Si ya tienes una base de datos que manda y que va a seguir mandando —porque hay informes, procesos por lotes, otro equipo, o simplemente veinte años de datos—, el motor tiene que sincronizar desde ella y no reemplazarla. Aquí no hay margen interpretativo: la documentación de LiveStore lo declara por escrito, si tienes una base de datos que es la fuente de verdad usa Zero o ElectricSQL, y a esos dos hay que sumar PowerSync, que es el que más orígenes admite. Si no la tienes, porque la aplicación es nueva y el dato nace en el cliente, se abre la puerta de Jazz y LiveStore, que traen su propio almacenamiento y no saben conectarse al tuyo.

Segundo corte: qué significa para ti trabajar sin conexión. Aquí conviene ser brutalmente concreto porque casi todo el mundo exagera esta necesidad y algunos la subestiman. Hay tres respuestas distintas y solo tres.

• Nunca desconectado: el usuario trabaja en una oficina y un corte de red es una incidencia. Cualquiera vale, y Zero es el que menos te va a costar montar.
• Interrupciones breves, del orden de segundos o algún minuto, ascensores y túneles. Zero y Electric las absorben, aunque conviene recordar que en Zero las mutaciones pendientes se quedan pendientes y la corrección puede llegar tarde.
• Horas o días sin cobertura: la inspección en obra, la ruta de reparto, el avión. Zero queda descartado por declaración propia y Electric solo sirve si vas a construir a mano su tercer o cuarto patrón de escritura, con lo que en la práctica quedan PowerSync, Jazz y LiveStore.

La distinción entre la segunda y la tercera respuesta es la que más decisiones tuerce, y se resuelve midiendo en vez de opinando. No preguntes al equipo si los usuarios trabajan sin conexión; mira la telemetría, cuenta los minutos y quédate con el peor caso real del mes pasado.

Tercer corte: la forma de tu control de acceso. Este es el corte que más equipos se saltan y el que más caro sale, porque el modelo de permisos no es un detalle de configuración sino la parte de la aplicación que más se parece a las reglas del negocio. Hay tres formas típicas. La primera es la de reglas expresables como filtro sobre filas, donde encajan los flujos de PowerSync anclados en reclamaciones firmadas y las políticas por fila de Jazz. La segunda es la de reglas que necesitan código —consultar un servicio, mirar una tabla que no se sincroniza, aplicar una regla que cambia por contrato—, y ahí el mutador de servidor de Zero o tu endpoint de subida en PowerSync son la respuesta natural, porque son código corriente en tu servidor. La tercera es la de permisos que dependen de la historia y no del estado, del tipo quien creó el elemento puede archivarlo aunque ya no sea miembro, y ahí el registro de eventos de LiveStore tiene una ventaja estructural que ninguna regla declarativa iguala.

Ese tercer corte se aclara con un ejemplo que aparece en casi cualquier aplicación de gestión. Supón la regla un miembro puede editar los documentos de su equipo, salvo los que estén cerrados, salvo que sea administrador, y los administradores externos solo hasta que caduque su contrato. Escríbela como filtro sobre filas y verás enseguida cuántas subconsultas necesitas y cuántas tablas auxiliares tienes que sincronizar al cliente solo para poder evaluarla; escríbela como código de servidor y cabe en quince líneas legibles. La prueba de fuego no es si el sistema declarativo puede expresar tu regla, sino qué datos te obliga a bajar al dispositivo para expresarla, porque cada tabla auxiliar que sincronizas por motivos de permisos es una tabla que además tienes que proteger.

Cuarto corte: cuánta dependencia toleras. No es una pregunta ideológica sino de riesgo, y se responde con un supuesto concreto: qué harías si el proyecto se detuviera mañana. Los años recientes dan material para calibrarlo sin especular.

• ElectricSQL reescribió su producto en 2024 y dejó fuera la mitad de su ambición original, incluido el CRDT en el cliente sobre el que muchos habían construido.
• Jazz ha rehecho su modelo de datos entero y hoy mantiene dos manuales en paralelo, el clásico y el actual, con superficies de API distintas.
• Triplit, que estaba en todas las comparativas, dejó de tener desarrollo comercial en 2025 tras incorporarse su equipo a Supabase, y pasó a mantenimiento por la comunidad.

Ninguno de esos tres hechos es una catástrofe para quien había medido su coste de salida por adelantado, y los tres lo son para quien no lo hizo. Nótese además que ninguno fue un fracaso técnico: fueron un cambio de estrategia, una evolución de producto y una adquisición, es decir, exactamente los tres sucesos normales en la vida de una herramienta joven. Planificar contra ellos no es pesimismo, es aritmética.

Cuatro respuestas caben en una ficha, y escribirla antes de abrir ninguna documentación es la mitad del trabajo. La ficha sirve además para lo que casi nunca se hace, que es revisar la decisión más adelante con los mismos criterios en lugar de con la moda del momento.

# Ficha de decision: se rellena antes de mirar ningun motor
fuente_de_verdad:
  donde: postgres de la aplicacion desde 2019
  otros_escritores: procesos por lotes nocturnos, panel de administracion
sin_conexion:
  peor_caso_medido: 6 horas en visitas a obra
  frecuencia: dos o tres veces por semana, un tercio de la plantilla
permisos:
  filtro_sobre_filas: 3 reglas
  requieren_codigo: 2 reglas
  dependen_de_la_historia: 1 regla
dependencia:
  peor_escenario_aceptable: el proyecto se detiene y lo alojamos nosotros
  exportacion_necesaria: estado actual, sin historia

El árbol

flowchart TD
A[tienes ya una base de datos que manda] -->|si| B[cuanto tiempo sin red]
A -->|no| C[el dato nace en el cliente]
B -->|segundos o nada| D[permisos que necesitan codigo]
B -->|horas o dias| E[powersync]
D -->|si| F[zero]
D -->|no, filtro sobre filas| G[electricsql mas tu camino de escritura]
C --> H[el valor esta en la intencion o en el estado]
H -->|intencion, auditoria, deshacer| I[livestore]
H -->|estado, con permisos y cuentas| J[jazz]
E --> K[tolerancia a depender de un proveedor]
F --> K
G --> K
I --> K
J --> K
K -->|baja| L[comprueba autoalojamiento y formato de salida]
K -->|alta| M[adelante]
style E fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b
style G fill:#89b4fa,color:#11111b
style I fill:#f9e2af,color:#11111b
style J fill:#f9e2af,color:#11111b
style L fill:#f38ba8,color:#11111b

Conviene leer el árbol sabiendo qué hace y qué no. Lo que hace es descartar rápido: en tres preguntas pasa de cinco candidatos a uno o dos, y eso vale más que cualquier matriz porque convierte una discusión de opiniones en una secuencia de hechos comprobables sobre tu propio proyecto. Lo que no hace es sustituir la prueba: la rama que te toca hay que recorrerla con una maqueta real, y el ejercicio que mejor funciona en las tres ramas es siempre el mismo, modelar tu caso más difícil —el permiso más raro, la escritura más larga sin red— antes que el más común.

Hay una rama que merece comentario aparte porque es la que más gente recorre mal. Si respondiste que tienes base de datos existente y que necesitas horas sin cobertura, el árbol te lleva a PowerSync sin pasar por la pregunta de permisos, y eso es deliberado: la combinación de fuente de verdad ajena y desconexión larga es tan restrictiva que apenas deja opciones, y las que quedan te obligarían a construir a mano la cola persistente que PowerSync ya trae. Esa es la única rama del árbol donde la respuesta está prácticamente forzada.

Lo que el árbol no ve

Esa tabla resume, pero deja fuera cuatro situaciones en las que el árbol se equivoca y hay que salirse de él. La primera es la de las aplicaciones que necesitan edición colaborativa de texto en tiempo real: ningún motor de este nivel la resuelve por sí solo, y la respuesta correcta es la que documenta PowerSync, meter una estructura convergente como valor dentro del motor que hayas elegido en lugar de escoger el motor por esa funcionalidad. La segunda es la de los datos muy entrelazados entre usuarios, redes sociales y mercados, donde la propia documentación de LiveStore reconoce que el enfoque no encaja y donde en general la sincronización parcial se vuelve un problema de diseño mayor que el que resuelve.

Merece la pena detenerse en una restricción que no es un eje pero se comporta como tal: el lenguaje de tus clientes. Zero declara admitir solo clientes TypeScript, así que si tu producto tiene una aplicación nativa en Swift o en Kotlin, el árbol termina antes de empezar por mucho que las demás respuestas apuntaran hacia allí. Electric está en el otro extremo por construcción, porque su protocolo es HTTP documentado y su equipo anima explícitamente a escribir clientes en lenguajes sin soporte oficial. Y PowerSync es el que más superficie declara, con la advertencia de leer con cuidado las etiquetas de madurez que su propia documentación pone al lado de cada SDK, porque no todas están en el mismo punto.

La tercera situación es la del equipo que no necesita un motor de sincronización sino una capa de datos en el cliente. Esa distinción se perdió por el camino en el ruido del mercado y conviene recuperarla: TanStack DB resuelve colecciones, consultas y estado optimista en el navegador, y se alimenta de orígenes distintos, entre ellos ElectricSQL; no compite con los cinco motores, se coloca encima de ellos. La cuarta es la del equipo que en realidad quiere una plataforma completa —base de datos alojada, autenticación, funciones, almacenamiento— con reactividad incluida, y para eso están productos como InstantDB o Convex, que responden a una pregunta distinta de la que ordena este nivel.

El coste de salida, que es el único número que no envejece

Todo lo anterior compara motores por lo que hacen. El último criterio los compara por lo que pasa cuando dejas de usarlos, y es el único que sigue siendo válido cuando cambien las versiones, los precios y los equipos. Se mide con cuatro comprobaciones concretas que puedes hacer en una tarde, sin escribir código.

Esas cuatro comprobaciones tienen la virtud de ser verificables por cualquiera y de no depender de promesas. La primera se responde mirando dónde está el esquema; la segunda, buscando el repositorio del servidor y su guía de despliegue; la tercera, comprobando si existe una especificación del protocolo separada del SDK; la cuarta, haciendo una búsqueda de importaciones en tu propio código, que es un dato que tienes tú y no el proveedor. Escribe las cuatro respuestas en el mismo documento donde justifiques la decisión, con fecha, porque dentro de dos años lo que vas a querer recordar no es qué motor elegiste sino con qué información lo elegiste.

La última tarjeta es la que más información da y la que menos gente calcula, y conecta directamente con el argumento que cerraba la lección de ElectricSQL: la superficie de acoplamiento no es una consecuencia accidental de la implementación, es la elección que hiciste al adoptar el motor. Un motor que solo emite filas se sustituye tocando un módulo; un motor que además es tu base de datos, tu autenticación y tu modelo de permisos se sustituye reescribiendo la aplicación. Ninguna de las dos opciones es incorrecta —la segunda te ahorró meses de trabajo el primer año— pero la asimetría hay que verla antes de firmarla, no después.

Y conviene cerrar el nivel con la conclusión que el recorrido entero sostiene. No existe el mejor motor de sincronización, existe la respuesta correcta a la pregunta por la autoridad para tu aplicación, y esa pregunta —quién tiene razón cuando dos versiones discrepan— se responde una sola vez y arrastra consigo el comportamiento sin red, el modelo de permisos, el coste de operación y hasta la clase de producto que puedes vender. Los cinco motores de este nivel son cinco respuestas coherentes a esa pregunta, no cinco calidades distintas de la misma respuesta. Elegir bien consiste, casi por completo, en saber cuál es tu pregunta antes de mirar sus respuestas.