El coste oculto de los BaaS: Por qué dejé Firebase y construí mi propio backend
Los Backend-as-a-Service como Firebase o Supabase prometen velocidad, pero esconden costes que pueden frenar tu producto. Te cuento cuándo y por qué decidí tomar el control y construir mi propio backend desde cero.
La promesa mágica del Backend-as-a-Service
Recuerdo la primera vez que usé Firebase. Fue como descubrir un superpoder. En una tarde, tenía autenticación, una base de datos en tiempo real y hosting para mi prototipo. ¡Sin escribir una sola línea de código de backend! Era mágico.
Como emprendedor y desarrollador, mi recurso más valioso es el tiempo. Herramientas como Firebase, Supabase o Amplify (los llamados BaaS) te venden esa promesa: olvídate del backend, enfócate en lo que el usuario ve y lanza tu producto en días, no en meses. Y al principio, cumplen con creces. Para un MVP, un proyecto personal o un hackathon, son imbatibles.
Pero la magia tiene un precio. Y la mayoría de las veces, es un coste oculto que no ves venir hasta que es demasiado tarde.
Las grietas en el paraíso: Los 3 costes ocultos
Mi idilio con los BaaS duró varios proyectos. Pero a medida que mis aplicaciones crecían en usuarios y complejidad, empecé a chocar contra muros invisibles. Estos no son fallos de las plataformas, sino consecuencias directas de su diseño: abstracción y facilidad a cambio de control.
1. El Coste Financiero: La factura que no esperas
El modelo de precios de los BaaS es un arma de doble filo. Sus generosas capas gratuitas son un cebo perfecto. Pero cuando empiezas a escalar, la factura puede dispararse de formas que no anticipas. No pagas por un servidor con un coste fijo, pagas por métricas abstractas:
* Lecturas y escrituras de documentos: Una simple consulta para mostrar una lista de posts puede generar cientos de lecturas si no está perfectamente optimizada para su sistema. Un pequeño cambio en la UI puede multiplicar tu factura por 10. * Invocaciones de funciones: Cada pequeña lógica que delegas a una 'cloud function' tiene un coste por ejecución. * Ancho de banda: El tráfico de salida siempre, siempre, cuesta dinero.
El problema es la imprevisibilidad. Un pico de tráfico viral puede ser una alegría para tu negocio pero una catástrofe para tu cuenta bancaria. No tienes control granular para optimizar costes como lo harías con tu propia infraestructura.
2. El Coste de Flexibilidad: El "Vendor Lock-in"
Este es el más peligroso. Cuando construyes sobre un BaaS, no estás usando estándares como SQL o APIs REST genéricas. Estás usando el dialecto, las APIs y la arquitectura de datos de ese proveedor.
¿Quieres migrar tu base de datos de Firestore a PostgreSQL? Buena suerte. No es un simple `pg_dump`. Tienes que reescribir cada consulta, reestructurar tus datos y, a menudo, replantear la lógica de tu aplicación. Estás atrapado.
Esta rigidez te impide:
* Optimizar consultas complejas: Los lenguajes de consulta de los BaaS son deliberadamente simples. Cuando necesitas joins avanzados, búsquedas geoespaciales específicas o análisis de texto completo, te encuentras haciendo malabares y escribiendo código ineficiente para simular algo que en SQL sería una sola línea. * Cambiar de proveedor de nube: Si Amazon sube los precios de AWS, teóricamente podrías mover tu backend a Google Cloud o Azure. Con un BaaS, estás atado a su infraestructura subyacente. Cero portabilidad.
3. El Coste de Rendimiento y Complejidad
La simplicidad inicial se convierte en complejidad a medida que tu app crece. Las abstracciones que te ayudaron al principio ahora son una caja negra que no puedes optimizar.
El punto de inflexión para mí fue cuando necesité implementar un sistema de búsqueda y filtrado avanzado para un marketplace. Con un backend propio y una base de datos como PostgreSQL o Elasticsearch, habría sido cuestión de horas. En el BaaS, pasé una semana intentando forzar su sistema de consultas, creando índices duplicados y escribiendo funciones complejas que actuaban como parches. Gasté más tiempo luchando contra la herramienta que construyendo la funcionalidad.
Ese fue el momento en que me di cuenta: el tiempo que ahorraba al principio lo estaba pagando con intereses más adelante.
Tomando el control: Construir mi "propio" BaaS
Decir "construí mi propio backend" suena intimidante. No significa que me puse a escribir un servidor web desde cero en C++. Significa que elegí mis propias piezas del puzzle, priorizando el control y la flexibilidad.
Mi stack actual suele ser:
* Lenguaje/Framework: TypeScript con Node.js y Fastify/Express, o a veces Go para servicios de alto rendimiento. * Base de datos: PostgreSQL casi siempre. Es un tanque suizo: fiable, potente y con un ecosistema increíble. Le añado Redis para caché cuando es necesario. * ORM: Prisma. Hace que interactuar con la base de datos sea casi tan fácil como en un BaaS, pero con todo el poder de SQL por debajo. * Autenticación: Implemento mi propio sistema con JWT (JSON Web Tokens). Hay librerías excelentes que lo hacen trivial. * Hosting: Un VPS en DigitalOcean o una instancia en AWS/GCP, gestionado con Docker para que todo sea replicable y escalable.
Sí, la configuración inicial lleva un par de días, no una tarde. Pero esos días son una inversión. A partir de ahí, tengo control absoluto. Si una consulta es lenta, la optimizo. Si los costes suben, sé exactamente por qué y dónde recortar. Si necesito una funcionalidad exótica, elijo la mejor herramienta para el trabajo, no la que el BaaS me permite usar.
Conclusión: ¿Cuándo usar un BaaS?
No estoy diciendo que los BaaS sean inútiles. Son una herramienta más en nuestro arsenal, y hay que saber cuándo usarla.
Usa un BaaS si:
* Estás construyendo un MVP y la velocidad es tu única prioridad. * Es para un proyecto interno o una app con pocos usuarios y lógica simple. * El backend no es el núcleo de tu producto.
Considera construir tu propio backend si:
* La lógica de negocio de tu backend es compleja y es una ventaja competitiva. * Anticipas la necesidad de consultas y optimizaciones de rendimiento específicas. * Quieres un coste predecible y escalable a largo plazo. * No quieres casarte con un único proveedor y valoras la flexibilidad.
Al final, se trata de un trade-off. Los BaaS te venden velocidad a corto plazo a cambio de control a largo plazo. Como constructor, tu trabajo es saber cuándo ese trato tiene sentido para ti y cuándo es el momento de arremangarse y tomar las riendas de tu tecnología.