Entre Supabase, Firebase o servidor propio, la elección depende sobre todo de tu modelo de datos. Si tus datos son relacionales (clientes, pedidos, facturas, inventario que se cruzan entre sí), Supabase o un PostgreSQL propio suelen encajar mejor. Si tu app vive de sincronización en tiempo real entre móviles y datos poco relacionados, Firebase te hace avanzar rápido. El servidor propio tiene sentido cuando ya tienes equipo para operarlo o requisitos que los servicios gestionados no cubren.
No escribimos esto desde la teoría. En FoodTook Labs operamos en producción nuestra propia plataforma de delivery, con PostgreSQL y Firebase conviviendo en distintas partes del sistema. Lo que sigue son los criterios que usamos para decidir, no un ranking.
Qué es cada opción, en una línea
- Firebase: plataforma de Google con base de datos de documentos (Firestore), autenticación, almacenamiento, funciones y notificaciones. Muy integrada con apps móviles.
- Supabase: plataforma construida sobre PostgreSQL, con autenticación, almacenamiento, funciones, tiempo real y una API generada a partir de tus tablas. Es código abierto y se puede alojar por cuenta propia.
- Servidor propio: tu propia base de datos (normalmente PostgreSQL) y tu propio backend en una nube como Google Cloud o AWS, o en servidores físicos. Control total, operación total.
Modelo de datos: el criterio que más pesa
Firestore guarda documentos. Es cómodo para datos que se leen juntos: el perfil de un usuario, un chat, el estado de un pedido que una app consulta en vivo. Se complica cuando necesitas cruzar información: «ventas por restaurante y por zona, del último mes, solo de clientes nuevos». En una base de documentos eso suele significar duplicar datos o leer muchos documentos y sumarlos en código.
PostgreSQL es relacional. Las relaciones, las restricciones y las transacciones vienen incluidas: un pedido no puede apuntar a un cliente que no existe, y un cobro con su factura se graban juntos o no se graba ninguno. Para un sistema de gestión, un ERP liviano o cualquier cosa con dinero de por medio, eso vale mucho. Supabase y un servidor propio comparten esta ventaja porque ambos son PostgreSQL.
Costos a escala
Los tres arrancan barato. Las diferencias aparecen al crecer, y cada uno cobra por cosas distintas.
- Firebase cobra principalmente por operaciones: lecturas, escrituras y borrados, además de almacenamiento y transferencia. Una pantalla mal diseñada que lee mil documentos cada vez que se abre puede disparar la factura. Hay que diseñar pensando en cuántas lecturas genera cada vista.
- Supabase cobra por plan y por recursos: tamaño de la base, capacidad de cómputo, transferencia. Es más predecible para cargas con muchas consultas pequeñas, pero cuando la base crece hay que subir de capacidad.
- Servidor propio cobra por la infraestructura que reservas, la uses o no, más el costo menos visible: las horas de alguien que la mantiene, actualiza, respalda y vigila.
Los precios de estas plataformas cambian con frecuencia, así que no te damos cifras. Lo útil es estimar con tu patrón de uso real: cuántos usuarios activos, cuántas lecturas por sesión, cuánto pesan los archivos. Esa estimación es parte de cualquier discusión seria sobre el costo de una app.
Lock-in: qué tan fácil es irse
Firebase es el que más ata. Firestore tiene su propio modelo de consultas y sus reglas de seguridad propias; salir implica reescribir la capa de datos y transformar los documentos. No es imposible, pero es un proyecto en sí mismo.
Supabase ata menos: debajo hay PostgreSQL estándar, y puedes exportar la base completa y llevarla a otro proveedor o a tu propio servidor. Lo que sí queda ligado son las piezas propias de la plataforma (su autenticación, sus funciones), que habría que reemplazar. El servidor propio no te ata a una plataforma, aunque sí al proveedor de nube si usas sus servicios exclusivos.
Seguridad por filas y control de acceso
Cuando una app móvil o web habla directamente con la base, la seguridad tiene que estar en la base. Firebase lo resuelve con reglas de seguridad que se escriben en su propio lenguaje. Supabase usa Row Level Security de PostgreSQL: políticas que dicen, por ejemplo, que un restaurante solo ve sus propios pedidos. Son potentes y quedan en la base, pero exigen disciplina: una tabla nueva sin políticas es una puerta abierta.
Con servidor propio, lo habitual es que las apps no toquen la base y pasen por una API que valida cada operación. Es más trabajo inicial y más fácil de auditar. Si manejas datos sensibles, revisa también la Ley de Protección de Datos Personales aplicada a tu software.
Operación: quién se levanta a las 3 de la mañana
| Tarea | Firebase | Supabase | Servidor propio |
|---|---|---|---|
| Respaldos | Configurables por el equipo | Incluidos según plan | Los montas tú |
| Actualizaciones de seguridad | Las hace Google | Las hace Supabase | Las haces tú |
| Escalar ante picos | Automático | Subir capacidad | Planificado por tu equipo |
| Monitoreo y alertas | Herramientas de Google Cloud | Panel de la plataforma | Lo configuras tú |
| Elegir región del servidor | Sí, al crear | Sí, al crear | Total libertad |
Sobre la región: elegirla por cercanía en el mapa no siempre da la menor latencia. Conviene medir desde donde están tus usuarios, como explicamos en por qué medimos la latencia antes de elegir dónde alojar tu app.
Supabase, Firebase o servidor propio: cuándo elegir cada uno
- Firebase si construyes una app móvil con mucho tiempo real, notificaciones y datos poco relacionados, y quieres salir rápido con un equipo pequeño.
- Supabase si tus datos son relacionales, quieres la comodidad de un servicio gestionado y te importa poder llevarte la base a otro lado.
- Servidor propio si tienes requisitos de control, cumplimiento o integración que un servicio gestionado no cubre, y un equipo que pueda operarlo de forma continua.
- Combinación si distintas partes del sistema tienen necesidades distintas: por ejemplo, PostgreSQL como fuente de verdad para pedidos y dinero, y Firebase para notificaciones y sincronización en vivo con las apps.
La combinación no es una salida fácil: exige definir qué sistema manda sobre cada dato y cómo se sincronizan, para que nunca haya dos versiones de la verdad. Bien hecha, permite tener datos en tiempo real en las apps y reportes confiables para decidir en la gerencia.