Supabase o Firebase: trabajar sin conexión puede decidir la elección

Si una aplicación debe guardar ediciones durante un corte de red y enviarlas al recuperar la conexión, Firebase con Cloud Firestore ofrece una solución integrada: su persistencia sin conexión conserva datos utilizados por la app y sincroniza los cambios locales después. Supabase resulta más atractivo cuando el requisito principal es trabajar sobre PostgreSQL o alojar el backend en infraestructura propia.

La elección tampoco se reduce a SQL frente a NoSQL. Firebase ofrece PostgreSQL mediante SQL Connect: la configuración de SQL Connect vincula una base en Cloud SQL y permite almacenar en caché resultados de consultas en SDK generados. Esa caché puede servir respuestas guardadas, pero no equivale a la sincronización de escrituras sin conexión de Firestore. La diferencia importa más que la etiqueta de la base de datos para una app móvil que debe aceptar cambios sin cobertura.

Qué sucede cuando se pierde la conexión

Con la persistencia activada, Firestore permite leer, consultar y modificar datos presentes en la caché local. En Android y las plataformas Apple viene activada por defecto; en la web debe habilitarse. La caché reúne documentos que la aplicación ha utilizado: una consulta ejecutada sin red puede ofrecer un resultado incompleto si aún faltan documentos locales. El cliente puede distinguir mediante sus metadatos si una respuesta procede de la caché.

Las escrituras pendientes se sincronizan al volver la conexión. Si hay varios cambios sobre un mismo documento, Firestore aplica la última escritura. Esa regla simplifica el caso básico, pero una aplicación en la que varias personas editan simultáneamente una ficha necesita decidir si perder una aportación anterior es aceptable. También hay una cuestión de privacidad en la web: la caché persistente puede conservar datos entre sesiones en un dispositivo compartido.

En SQL Connect, guardar el resultado de una consulta sirve para mostrar información ya obtenida. No establece por sí mismo una cola de mutaciones que acepte ediciones sin red y las reenvíe al servidor. En Supabase, recibir actualizaciones mientras hay conexión tampoco resuelve automáticamente qué conservar en el dispositivo ni cómo reconciliar cambios posteriores. Para un flujo de captura móvil, la distinción decisiva es entre mostrar datos antiguos y aceptar nuevas escrituras durante el corte.

PostgreSQL ya no pertenece a una sola opción

Supabase organiza el backend alrededor de una base PostgreSQL por proyecto. Para un SaaS con organizaciones, miembros, permisos y facturas relacionados, esto permite diseñar el modelo y sus consultas en el motor relacional que usa el servicio. El equipo conserva un esquema PostgreSQL reconocible y puede apoyarse en los servicios administrados de autenticación, almacenamiento y actualizaciones en vivo de la plataforma.

SQL Connect mantiene a Firebase entre las opciones relacionales: usa PostgreSQL en Cloud SQL y conecta las operaciones de la aplicación con SDK generados. La comparación útil pasa por la forma de trabajar con esos datos. En Supabase pesa el acceso al esquema PostgreSQL como centro de la arquitectura; en SQL Connect, el cliente consume las consultas y mutaciones definidas para sus conectores. Elegir PostgreSQL en Firebase tampoco convierte a Firestore y SQL Connect en un único sistema con idéntico comportamiento sin conexión.

Portabilidad y alojamiento propio

Supabase tiene una vía documentada para ejecutar su plataforma fuera del servicio administrado. Su guía de alojamiento propio contempla servidores e infraestructura en la nube elegidos por el equipo. La misma decisión traslada al operador el mantenimiento, la seguridad, las copias de respaldo, la disponibilidad y el escalado. Además, algunas funciones del servicio administrado, como los respaldos gestionados y las ramas de base de datos, no están disponibles en esa modalidad.

La portabilidad tiene distintos niveles. Conservar tablas y datos PostgreSQL facilita cambiar de entorno, pero trasladar una aplicación completa también exige revisar autenticación, almacenamiento, políticas de acceso y código cliente. Para un proyecto obligado a controlar dónde corre el backend, la posibilidad de alojar Supabase puede ser determinante. Para un equipo que busca reducir tareas operativas, conviene incluir el trabajo de administrar esa infraestructura en la comparación.

Árbol de decisión según el producto

El requisito que más limita el producto debe ir primero; después pueden compararse el modelo de datos y el coste. Estos casos son escenarios de decisión, no resultados de pruebas realizadas sobre ambas plataformas:

• Aplicación móvil con cortes frecuentes: Firestore parte con ventaja si los usuarios deben editar sin red y sincronizar después. La regla de última escritura debe servir para los datos que puedan modificar varias personas.
• SaaS con muchas relaciones entre entidades: Supabase encaja si el equipo quiere que PostgreSQL sea el centro del backend. SQL Connect conserva a Firebase como alternativa relacional cuando sus otros servicios resultan útiles; la experiencia sin conexión se evalúa por separado.
• Producto colaborativo normalmente conectado: las actualizaciones en vivo pueden cubrir la visualización de cambios, mientras que la edición simultánea exige una política de conflictos. Si además se prevén cortes, el tratamiento de escrituras locales adquiere más peso.
• Proyecto que exige alojamiento propio: Supabase ofrece esa ruta, siempre que el presupuesto incluya operación, seguridad y respaldo. El precio de un plan administrado no representa ese coste de infraestructura.

El mismo consumo no produce la misma factura

Las tarifas de Supabase incluyen en Free 500 MB de base de datos, 5 GB de salida y 50.000 usuarios activos mensuales; los proyectos gratuitos se pausan tras una semana de inactividad. Pro empieza en 25 dólares al mes e incluye créditos de cómputo suficientes para una instancia Micro, además de cuotas mayores. Otros proyectos, más capacidad de cómputo o consumos superiores a las cuotas pueden aumentar el importe.

Las tarifas de Firebase distinguen Spark, sin coste, de Blaze, de pago por uso. Para Cloud Firestore Standard figuran cuotas gratuitas de 1 GiB almacenado, 10 GiB de salida al mes, 50.000 lecturas y 20.000 escrituras de documentos al día. SQL Connect tiene métricas propias de operaciones y transferencia, además de la instancia de Cloud SQL. Por ello, una estimación hecha para Firestore no calcula el coste de usar PostgreSQL dentro de Firebase.

Como escenario hipotético, pensemos en 10.000 usuarios activos mensuales, 400 MB de datos, 4 GB de salida y, si se usa Firestore, 30.000 lecturas y 10.000 escrituras diarias. Esas cantidades quedan por debajo de las cuotas citadas para Free y Firestore Standard, siempre que el almacenamiento facturable y los demás servicios respeten sus propios límites. Los usuarios activos, las lecturas de documentos y las solicitudes a PostgreSQL son unidades diferentes: no existe una conversión directa entre ellas.

Si el mismo proyecto pasa hipotéticamente a 800 MB de datos y 8 GB de salida, rebasa los límites Free indicados para Supabase. En Firestore todavía podría caber dentro de las cuotas gratuitas de almacenamiento y transferencia si su tamaño facturable no supera 1 GiB y sus operaciones siguen bajo los topes diarios. Un producto con pocos datos pero muchas lecturas puede recorrer el camino inverso: superar la cuota de operaciones de Firestore sin haber agotado el espacio de base de datos de Supabase. El patrón de consultas y el servicio de Firebase elegido cambian tanto la estimación como la arquitectura conveniente.

Lee también:

• VS Code 1.134 ordena los chats de agentes y deja comparar su trabajo
• Slack o Microsoft Teams: la suite que ya pagas puede decidir la compra
• El eclipse llega con el Sol al ras: el horizonte decidirá quién verá la totalidad