BaaS vs. backend custom: cuándo tiene sentido cada uno
Publicado el
Elegir entre un BaaS y construir backend propio es una de esas decisiones que se toman deprisa al inicio de un proyecto y se pagan lento con el tiempo. El argumento habitual es sencillo: un BaaS te da autenticación, base de datos, almacenamiento y funciones serverless en horas; un backend custom te da control total pero te cuesta semanas. Lo que rara vez se explica bien es en qué momento uno compensa sobre el otro, y cuáles son las señales concretas de que deberías cambiar de carril.
Este post no es un comparativo de características. Es un análisis de trade-offs para ayudarte a tomar la decisión con criterio, no con marketing de proveedores.
1. Qué ofrece un BaaS (y qué no)
Un BaaS —Backend as a Service— agrupa los primitivos estándar de cualquier backend: autenticación, base de datos, almacenamiento de ficheros, funciones serverless y, habitualmente, sincronización en tiempo real. Los consumes vía SDK o HTTP en lugar de tener que aprovisionar, escalar y actualizar esa infraestructura tú mismo.
El trade-off es explícito: cedes algo de control sobre el runtime, el esquema de datos y la semántica de las consultas a cambio de velocidad de salida al mercado, interfaces de integración estandarizadas y escalado gestionado. El problema aparece cuando los requisitos del proyecto superan las abstracciones de la plataforma.
Los tres BaaS que concentran la mayoría de decisiones hoy:
- Firebase (Google): propietario, NoSQL (Firestore), muy maduro, fuerte ecosistema móvil, precios por operación (lecturas/escrituras de documentos), sin opción de self-host.
- Supabase: open source, PostgreSQL, precios por recursos, self-hostable, opción de migración más limpia.
- AWS Amplify: capa sobre servicios AWS (Cognito, DynamoDB/RDS, AppSync, Lambda), máxima integración con el ecosistema Amazon, curva de aprendizaje significativa.
2. El coste real: predecible vs. por operación
El modelo de precios es donde los BaaS se diferencian más en la práctica y donde más sorpresas aparecen.
Firebase cobra por operación: cada lectura, escritura y borrado de documento en Firestore tiene un coste. En proyectos pequeños esto es casi invisible; a medida que crece el tráfico, la factura puede dispararse de forma no lineal. Una query ineficiente que recorra miles de documentos puede traducirse en una factura inesperada de cientos de euros en un día de tráfico alto. Supabase, en cambio, cobra por recursos aprovisionados: su plan Pro parte de 25 $/mes con una base fija de recursos incluidos (base de datos, almacenamiento y usuarios activos mensuales), lo que hace la previsión presupuestaria mucho más sencilla que con un modelo puramente por operación.
Amplify hereda la complejidad de precios de AWS: Cognito, DynamoDB, Lambda y AppSync tienen tarifas independientes que se suman. Para proyectos con mucho tráfico ya en AWS puede resultar competitivo; para un MVP inicial, el overhead de configuración y la fragmentación de costes rara vez merece la pena.
El resumen práctico: si la predictibilidad de costes es una restricción (side project, presupuesto ajustado, startup early-stage), Supabase o cualquier BaaS con tarifa plana base es más manejable que un modelo pay-per-operation a escala. Si en algún momento valoras profundizar en el análisis de costes en la nube, el post FinOps para pymes: controla tu factura cloud sin un equipo dedicado desarrolla ese enfoque con más detalle.
3. Vendor lock-in: cuánto te cuesta salir
El lock-in de un BaaS no se mide al entrar; se mide cuando necesitas salir. Y la diferencia entre plataformas es enorme.
Migrar desde Firebase es un proyecto no trivial. El modelo de datos de Firestore es NoSQL documental propietario: los datos exportados requieren transformación completa a otro esquema para ser utilizables en otro sistema. La autenticación, las reglas de seguridad, el almacenamiento y las funciones Cloud están todos acoplados al ecosistema de Google Cloud. No existe opción de self-host. Si Google depreca un servicio o modifica los precios, no tienes palanca.
Supabase presenta una posición distinta. Al estar construido sobre PostgreSQL estándar, la portabilidad de datos es alta: un pg_dump estándar es suficiente para mover la base de datos a cualquier otro proveedor PostgreSQL o instancia propia. El proyecto es open source (licencias MIT y Apache 2.0), lo que significa que el camino de salida —auto-hospedaje o migración a otro Postgres— está bien documentado y es practicable. El coste de salida existe (hay que gestionar auth, storage y funciones por separado), pero es sustancialmente menor que con Firebase.
Amplify bloquea en el ecosistema AWS: Cognito para auth, DynamoDB o RDS para datos, AppSync para GraphQL, Lambda para lógica. Abandonar Amplify significa en gran medida reestructurar la arquitectura, no solo mover datos.
La pregunta que vale la pena hacerse al inicio es: ¿qué pasa si este proveedor cambia los precios, depreca un servicio o simplemente deja de existir? Si la respuesta da vértigo, la elección de plataforma debería ponderarlo.
4. Cuándo un BaaS es la decisión correcta
No hay nada malo en usar un BaaS. Hay contextos donde es la decisión más sensata:
MVP y validación temprana. Si el objetivo es comprobar si una idea tiene tracción antes de invertir semanas en infraestructura, un BaaS permite llegar al mercado con funcionalidad real en días. Reescribir el backend más adelante no es un fracaso; es el camino normal de los proyectos que validan antes de escalar.
Side projects y herramientas internas. Proyectos donde el volumen de usuarios es predecible y bajo, los requisitos de datos son estándar y el tiempo de desarrollo es la restricción principal. En estos casos, la complejidad operativa de un backend custom no está justificada.
Equipos sin experiencia en backend. Un equipo de frontend que necesita añadir autenticación y persistencia sin contratar o aprender DevOps. El BaaS reduce la barrera de entrada de forma legítima.
Aplicaciones con patrones de datos estándar. Si el modelo de datos es sencillo, sin necesidad de queries complejas, joins o lógica de negocio elaborada en el servidor, la abstracción del BaaS no te limita y sí te ahorra trabajo.
5. Cuándo la deuda técnica de un BaaS empieza a costar
Hay señales concretas de que el BaaS está frenando el proyecto más que acelerándolo:
La lógica de negocio vive en funciones cloud. Cualquier cosa que no encaja en el modelo de datos del BaaS acaba en una función serverless. Cuando hay muchas de estas funciones, en la práctica tienes un backend paralelo con peor experiencia de desarrollo local, menor type safety y observabilidad fragmentada.
Las queries no escalan. En Firestore, los JOINs y las queries relacionales complejas no existen de forma nativa: hay que denormalizar datos, hacer múltiples requests o gestionar consistencia en el cliente. En proyectos con datos relacionales complejos —historial de pedidos, permisos granulares, análisis— esto se convierte en un problema de mantenimiento serio.
El coste por operación supera el coste de un backend propio. En proyectos con volumen de lectura/escritura alto, el modelo por operación de Firebase puede resultar más caro que provisionar una instancia de Node + PostgreSQL gestionada. El punto de inflexión depende del patrón de uso concreto, pero para aplicaciones con decenas de miles de usuarios activos diarios, la diferencia puede ser sustancial.
Requisitos de compliance o soberanía de datos. Ciertos sectores (salud, finanzas, administración pública) o ciertas jurisdicciones requieren control explícito sobre dónde residen los datos y quién puede acceder a ellos. Un BaaS propietario sin opción de self-host no puede cumplir estos requisitos sin pasar a planes enterprise con condiciones específicas.
El equipo ya tiene capacidad backend. Si el equipo puede operar un backend propio, los beneficios de velocidad del BaaS se reducen y los costes de lock-in y pérdida de control se mantienen. En ese punto, un backend custom suele ser más eficiente a largo plazo.
6. Matriz de decisión por tipo de proyecto
| Tipo de proyecto | BaaS recomendado | Backend custom | Notas |
|---|---|---|---|
| MVP de validación | ✅ Primera opción | Solo si ya tienes uno reutilizable | Velocidad sobre control |
| Side project / herramienta interna | ✅ Supabase o similar | Raramente justificado | Costes planos, bajo mantenimiento |
| SaaS B2B con datos relacionales complejos | ⚠️ Supabase con cautela | Valorar desde el principio | Evalúa si PostgreSQL puro + API propia no es más sencillo |
| App móvil consumer con tiempo real | ✅ Firebase para móvil | Solo si el lock-in es inaceptable | Ecosistema móvil de Firebase muy maduro |
| Producto maduro con equipo de ingeniería | ❌ Poco recomendado | ✅ Primera opción | Control, rendimiento y costes a escala |
| Proyecto con compliance estricto (HIPAA, etc.) | ⚠️ Solo con plan Enterprise | ✅ Preferible | Verificar requisitos de residencia de datos |
7. Señales de alerta para migraciones forzadas
Una migración forzada —salir de un BaaS cuando no estabas planeando hacerlo— es costosa. Estas son las señales tempranas que la predicen:
- La factura mensual crece más rápido que los usuarios. Indica que el patrón de uso está fuera del modelo de precios óptimo del proveedor.
- Cada nueva feature requiere una función cloud nueva. El modelo de datos del BaaS ya no representa bien el dominio del producto.
- El tiempo de debug se concentra en entender el comportamiento del proveedor, no en la lógica del producto.
- Los contratos con clientes exigen condiciones que el BaaS no puede garantizar (uptime custom, residencia de datos, auditoría de accesos).
- El equipo pasa más tiempo en workarounds que en features. Señal de que las abstracciones del BaaS están frenando más que ayudando.
La migración cuando llega es raramente un proyecto limpio. El enfoque más pragmático es el llamado strangler-fig: montar el nuevo backend en paralelo, dirigir las nuevas funcionalidades a él y migrar gradualmente las existentes, hasta que el BaaS queda inactivo. La parte más difícil suele ser el modelo de datos, no el código de aplicación.
8. La pregunta que realmente importa
Antes de elegir, vale la pena formularse esta pregunta: ¿en qué fase está el proyecto y qué restricción es más crítica ahora mismo?
Si la restricción es tiempo de salida al mercado y el modelo de datos es estándar, un BaaS es la decisión correcta. Si la restricción es control técnico, costes predecibles a escala o soberanía de datos, un backend propio justifica su coste desde el principio.
No hay respuesta universal. Sí hay una trampa frecuente: elegir el BaaS porque es lo que todos usan en tutoriales, sin analizar si encaja con el modelo de datos, el volumen esperado y los requisitos no funcionales del proyecto concreto.
Si estás evaluando esta decisión para un proyecto y quieres un análisis específico de tu caso, cuéntame en qué punto estás.