Firebase vs Supabase: cuál elegir para tu primera app

Si estás comparando Firebase vs Supabase para tu primera app, probablemente ya leíste varias tablas comparativas con veredictos opuestos. Yo uso Firebase en mis productos y voy a contarte por qué, qué me ha dolido de esa decisión y en qué casos te recomendaría mirar Supabase. De Supabase hablo por lo que dice su documentación y su diseño, no por años de operarlo en producción, y te aviso cuando algo es de esa categoría.

¿Qué es cada uno, en una frase?

Firebase es el conjunto de servicios de Google para construir apps: autenticación, base de datos (Firestore), almacenamiento de archivos, funciones y notificaciones. Su base de datos principal es NoSQL: guardas documentos dentro de colecciones, sin esquema rígido.

Supabase se presenta como una alternativa de código abierto construida sobre PostgreSQL. Eso significa tablas, relaciones, SQL de toda la vida y la posibilidad de alojarlo tú mismo si algún día lo necesitas.

La diferencia que de verdad importa es esa: documentos contra tablas. Todo lo demás se desprende de ahí.

¿Cuándo conviene Firebase?

En mis proyectos Firebase aparece una y otra vez: el Content Studio de Méndez Labs corre sobre Firestore, y Nido, la app de seguimiento de bebés, usa el SDK nativo de Firebase para que funcione sin conexión y sincronice cuando regresa la señal. Ese caso es el ejemplo perfecto de cuándo Firebase brilla.

Firebase suele ser buena elección cuando:

• Tu app es móvil y necesita funcionar con mala conexión o sin ella.
• Quieres autenticación, base de datos, archivos y notificaciones bajo un mismo techo y una sola consola.
• Tus datos son más bien "una cosa con sus cosas adentro" (un bebé con sus registros, un usuario con sus sesiones) que una red de relaciones cruzadas.
• Estás construyendo con IA como asistente: hay muchísima documentación y ejemplos de Firebase, y los modelos generan código de Firebase con buena soltura.

¿Cuándo conviene Supabase?

Por diseño, Supabase tiene sentido cuando tus datos son relacionales de verdad: pedidos que tienen productos que tienen proveedores, o reportes que cruzan tres tablas. En una base SQL eso es una consulta. En Firestore es una decisión de diseño que tomas desde el principio, y si la tomas mal, se paga después.

También conviene mirarlo si:

• Quieres poder irte con tus datos sin reescribir todo. Al ser PostgreSQL, tu información vive en un formato que cualquier otra herramienta entiende.
• Ya sabes SQL o quieres aprenderlo, que es una habilidad que te sirve toda la vida.
• Te preocupa la dependencia de un solo proveedor.

¿Qué me ha dolido de Firebase?

Honestidad de builder: Firestore no hace consultas complejas con facilidad. Tienes que pensar de antemano qué preguntas vas a hacerle a tus datos, y a veces duplicar información para poder consultarla rápido. Los índices compuestos son otro tema; cuando una consulta nueva exige uno, la app te lo avisa con un error y toca crearlo.

Además, el modelo de cobro de Firebase se basa en operaciones: lecturas, escrituras, borrados. Una pantalla mal diseñada que lee mil documentos cada vez que se abre puede salirte más cara de lo que esperabas. Revisa siempre la página oficial de precios de cada servicio antes de decidir, porque cambia con el tiempo y aquí no voy a citar montos.

Por último, las reglas de seguridad de Firestore son un lenguaje propio. Se aprenden, pero un error ahí es una puerta abierta. Yo les dedico tiempo en cada proyecto y mantengo las reglas e índices dentro del repositorio.

¿Cómo decido yo, en concreto?

Me hago tres preguntas antes de arrancar un producto:

1. 1¿Mis datos son un árbol o una red? Si son un árbol (usuario, sus registros, sus ajustes), Firestore. Si son una red con muchos cruces, miro Postgres.
2. 2¿Necesito modo sin conexión? Si sí, Firebase tiene una ventaja clara en móvil.
3. 3¿Quién va a mantener esto? Si soy yo solo, de noche, con un trabajo de cirujano de día, prefiero menos piezas sueltas. Un solo proveedor para auth, datos y archivos me ahorra decisiones.

Con esas tres respuestas la elección casi nunca queda en empate. Y si queda, elige el que ya conoces: terminar la primera versión pesa más que la perfección de la base de datos.

¿Se puede cambiar después?

Se puede, pero cuesta. Migrar de documentos a tablas implica rediseñar el modelo de datos, no solo mover filas. Por eso vale la pena dedicar una tarde a dibujar tus datos en papel antes de escribir una sola línea: qué entidades hay, quién pertenece a quién, qué pantallas las leen.

Si estás aprendiendo, no pierdas semanas en esta decisión. Cualquiera de las dos te permite lanzar. Lo que sale caro es pasar meses comparando sin lanzar nada.

Preguntas frecuentes

¿Firebase o Supabase es mejor para principiantes? Para empezar rápido en una app móvil, Firebase suele ser más directo porque trae todo integrado y tiene mucha documentación. Si ya conoces SQL o tus datos son muy relacionales, Supabase puede resultarte más natural.

¿Supabase es de código abierto y Firebase no? Así es: Supabase se publica como código abierto y puedes alojarlo por tu cuenta. Firebase es un servicio de Google que usas desde su nube.

¿Puedo usar los dos en el mismo proyecto? Técnicamente sí, pero para una primera app complica más de lo que ayuda. Elige uno, termina la primera versión y decide con datos reales si necesitas el otro.

Si quieres practicar esta decisión con un proyecto propio, la prueba de la Academy no pide cuenta: https://cesarmendez.dev/academy/prueba

Y si quieres ver qué construí con Firebase, el portafolio de proyectos tiene el estado real de cada uno, y en mi historia cuento cómo llegué a construirlos.