Supabase o Firebase: el coste depende de consultas, no solo de usuarios

Supabase suele encajar mejor cuando el producto necesita relacionar muchos datos; Cloud Firestore puede mantener bajo el coste de una aplicación con pocas operaciones, aunque ambas opciones permiten empezar sin pagar. Los precios de Supabase incluyen una instancia propia de PostgreSQL por proyecto, solicitudes API ilimitadas en Free y Pro, una base de hasta 500 MB en Free y un plan Pro desde 25 dólares mensuales; el cómputo, el disco, la transferencia y los usuarios activos tienen límites o cuotas distintos.

En Firebase, contar usuarios por sí solo tampoco permite estimar Firestore: importan los documentos que recupera cada consulta y las veces que se ejecuta. Para Firestore Standard en Iowa, la tarifa de Google Cloud concede 50.000 lecturas y 20.000 escrituras de documentos al día sin coste y, después, cobra 0,03 y 0,09 dólares respectivamente por cada 100.000 operaciones. Los importes de los escenarios siguientes usan esa región, un mes hipotético de 30 días y solo la partida que se indica.

Una consulta no equivale a una lectura

En Supabase, las consultas consumen recursos de PostgreSQL, pero el plan no asigna un precio a cada solicitud API. Una carga intensa puede requerir una instancia con más cómputo, además de más disco o transferencia. Por eso el precio de entrada de Pro tampoco es una estimación suficiente para una aplicación con tráfico elevado.

En Firestore Standard, una consulta que devuelve varios documentos puede generar varias lecturas facturables; ciertas consultas también generan lecturas de entradas de índice. La cuota gratuita se aplica por día y se reinicia alrededor de la medianoche del horario del Pacífico. Para reproducir los ejemplos de lecturas, se resta la cuota diaria de las lecturas de cada día, se multiplica el excedente por los días del supuesto y se aplica la tarifa por bloque de operaciones. Una media mensual puede ocultar días que superan la cuota y otros que no la consumen.

Prototipo: el coste inicial puede ser cero en ambos

Supongamos un prototipo con 1.000 usuarios activos al mes, 10.000 lecturas y 2.000 escrituras de documentos al día, una base de 300 MB y poca transferencia. Sus operaciones caben en las cuotas gratuitas citadas de Firestore Standard. También podría caber en Supabase Free si el uso de almacenamiento y salida se mantiene dentro de sus límites: el número de usuarios del supuesto, por sí mismo, no obliga a pasar a Pro.

La diferencia aparece en la continuidad y en la forma inicial de los datos. Un proyecto gratuito de Supabase puede quedar en pausa por inactividad, algo que afecta a una demostración abierta esporádicamente. La tabla de precios de Firebase distingue Spark, sin coste, de Blaze, de pago por uso: superar la cuota gratuita de Firestore exige habilitar la facturación para continuar usando ese servicio. En una aplicación pequeña, la estructura de tablas o documentos y las funciones necesarias pueden pesar más en la elección que una factura de base de datos todavía nula.

Muchas lecturas: la misma audiencia, otro gasto

Mantengamos una audiencia hipotética de 10.000 usuarios activos y variemos solo el ritmo de lecturas de Firestore. Con 200.000 lecturas diarias, quedan 150.000 facturables cada día tras la cuota: 4,5 millones en el mes supuesto, equivalentes a 1,35 dólares por lecturas. Con cinco millones de lecturas al día, el excedente mensual llega a 148,5 millones y esa partida sube a 44,55 dólares. La diferencia procede de las operaciones, aunque la audiencia no cambie.

Esas cifras no incluyen escrituras, lecturas de índices cuando correspondan, almacenamiento, transferencia ni otros productos de Firebase. Tampoco prueban que Supabase sea más caro en el primer caso o más barato en el segundo: una instancia PostgreSQL pequeña puede atender una carga o necesitar más capacidad según el tamaño de las consultas, los índices y la concurrencia. Una vista que solicita menos documentos o aprovecha datos ya cargados reduce las lecturas de Firestore; una vista que se actualiza repetidamente puede incrementarlas. La unidad que conviene estimar es el trabajo que provoca cada uso de la aplicación.

Producto relacional: el precio de lectura es solo una parte

Imaginemos un catálogo cuya vista recupera producto, disponibilidad, vendedor y condiciones de venta. Si hay 100.000 vistas diarias y una implementación en Firestore lee cuatro documentos por vista, el supuesto produce 400.000 lecturas al día. Tras aplicar la misma cuota y tarifa, la partida de lecturas sería de 3,15 dólares en el mes hipotético. Es una elección de diseño, no una cantidad inevitable: reunir esos datos en menos documentos reduciría lecturas, pero exigiría mantener actualizada la información compartida.

PostgreSQL permite guardar esas entidades en tablas relacionadas y recuperarlas mediante uniones. Eso resulta útil cuando el producto necesita cruzar catálogo, pedidos y existencias de distintas maneras; el rendimiento sigue dependiendo de índices, consultas y capacidad contratada. Firestore puede servir el mismo catálogo con documentos e índices diseñados para sus vistas habituales. Si cambian con frecuencia las relaciones o las preguntas que el producto hace a los datos, ese diseño y sus actualizaciones pasan a ser parte del coste operativo, aunque cada lectura adicional parezca barata.

Autenticación y control del gasto

La factura de autenticación debe separarse de la de la base de datos. Supabase cuenta usuarios activos mensuales dentro de las cuotas de sus planes; en Firebase, los métodos habituales de Authentication tienen condiciones diferentes de la verificación telefónica, facturada por SMS, y de Identity Platform. Un registro de cuentas no equivale necesariamente a usuarios activos, y añadir el coste de SMS al de lecturas produciría una comparación engañosa entre bases de datos.

El control del gasto también tiene consecuencias para la disponibilidad. En Supabase Pro hay un límite de gasto activado por defecto para determinadas cuotas: mantenerlo puede restringir el servicio al agotarlas, mientras que desactivarlo permite cobrar el exceso. La documentación de presupuestos de Firebase distingue las alertas, que no pausan servicios, de los topes de gasto en vista previa para servicios seleccionados; Cloud Firestore no figura entre ellos y la aplicación de esos topes puede retrasarse. Un aviso presupuestario, por tanto, no convierte a Blaze en una factura con techo automático para Firestore.

Migrar cambia más que el formato de los datos

PostgreSQL facilita trasladar tablas y consultas SQL a otro entorno compatible, pero salir de Supabase todavía exige revisar autenticación, almacenamiento, permisos y funciones usadas por la aplicación. Al pasar de Firestore a PostgreSQL se añade una decisión previa: cómo convertir colecciones y documentos en relaciones. La guía de migración de Supabase convierte inicialmente cada colección en una tabla y permite separar datos anidados en tablas relacionadas cuando la estructura lo requiere.

Esa conversión afecta a la lógica que consulta y actualiza los datos, no solo a su exportación. En el catálogo del supuesto, pasar de documentos preparados para cada vista a tablas relacionadas implica revisar las consultas que construyen la ficha y las operaciones que modifican disponibilidad o vendedor. Cuando el producto prevé muchas relaciones cambiantes, ese trabajo futuro favorece diseñarlas temprano en PostgreSQL; cuando las vistas consumen documentos estables, Firestore permite conservar un modelo ajustado a ellas sin asumir de entrada esa estructura relacional.

Lee también:

• Sentry o New Relic: el coste cambia entre errores, datos y usuarios
• Amazon Quick sigue trabajando al cerrar el portátil: qué controla el usuario
• Holded u Odoo: el coste cambia entre límites por empresa y pago por usuario