Alternativas a Firebase
Firebase es una plataforma alojada construida alrededor de Firestore, una base de datos de documentos, con autenticación, almacenamiento, funciones y unos SDKs de cliente cuyo soporte offline sigue siendo el mejor del sector. La mayoría de los equipos que se van no dejan la plataforma — dejan el modelo de documentos.
Publicado por Rebase, que es una de las herramientas de esta página. Cada una de las demás entradas se describe por aquello en lo que es buena, varias de las recomendaciones de abajo no somos nosotros, y no hay precios en ninguna parte: los precios de la competencia cambian cada trimestre y una cifra caducada es peor que ninguna.
Empieza por por qué te vas
Casi nadie quiere «la mejor alternativa». Quiere la que arregla lo concreto que se rompió. Busca tu fila.
“Necesitamos SQL — joins, transacciones, consultas ad-hoc”
Supabase or RebaseLos dos son Postgres. Supabase es la plataforma más madura y con mayor ecosistema; Rebase añade un panel de administración generado desde el mismo esquema, lo cual importa si gente de fuera de ingeniería tiene que trabajar con los datos.
“La factura escala de una forma que no podemos predecir”
Cualquier cosa autoalojableEl precio por lectura es lo que hace que una factura de Firestore se mueva sin que el producto cambie. Un Postgres autoalojado y una aplicación al lado cuestan lo que cuesta la máquina.
“Queremos mantener un modelo de documentos, pero autoalojado”
AppwriteLo más parecido a la forma y la experiencia de desarrollo de Firebase que puedes ejecutar en tu propia infraestructura.
“Queremos consultas reactivas sin renunciar a un backend de verdad”
ConvexLas consultas son funciones TypeScript y el cliente se vuelve a renderizar cuando cambian sus resultados — la parte de Firestore que más se echa de menos, hecha a propósito.
“Nuestro equipo de operaciones necesita ver y editar los datos”
RebaseLa consola de Firebase es una herramienta para desarrolladores. Un panel de administración generado con roles, formularios y medios es otra cosa, y es lo que suele acabar construyéndose a mano cuando un proyecto de Firebase crece.
“Es una aplicación pequeña y queremos operar una sola cosa”
PocketBaseUn binario con auth, almacenamiento, realtime y una interfaz de administración. Es la respuesta completa más pequeña de aquí.
9 alternativas a Firebase
Ordenado a grandes rasgos por la frecuencia con la que cada una acaba siendo la respuesta, no por ninguna puntuación. Donde existe una comparativa directa, está enlazada.
- 1
Supabase
Código abierto· AmbosMejor para: El mayor ecosistema, y el arranque más rápido
Postgres con auth, almacenamiento, realtime y edge functions, y con diferencia el producto mejor documentado de esta categoría. El panel es un editor de tablas y no un panel de administración, y la RLS se escribe como SQL en ese panel — que son las dos cosas que la gente más suele salir a reemplazar.
- 2
Appwrite
Código abierto· AmbosMejor para: Una API con la forma de Firebase que puedes autoalojar
Un backend con todo incluido: auth, bases de datos, almacenamiento, funciones y mensajería, con SDKs de cliente para casi cualquier plataforma. Más cerca de la forma de Firebase que de un backend SQL — la base de datos es orientada a documentos, lo cual es la decisión correcta si eso era lo que querías y la equivocada si venías por los joins.
- 3
Rebase
That's usCódigo abierto· AmbosMejor para: Pasarte a Postgres y necesitar un back office desde el primer día
Un backend de Postgres — API REST, SDK tipado, auth, realtime, almacenamiento, funciones, cron — más un panel de administración generado desde las mismas definiciones de colección en TypeScript. La seguridad a nivel de fila se escribe en código y se compila a políticas reales de Postgres, así que la autorización la aplica la base de datos y no la capa que hay delante. Se conecta a una base de datos Postgres que ya existe.
- 4
PocketBase
Código abierto· AutoalojadoMejor para: Un binario, un fichero, sin infraestructura
Un único ejecutable de Go con una base de datos SQLite embebida, auth, almacenamiento de ficheros, realtime y una interfaz de administración. Genuinamente encantador para una app pequeña o un prototipo. La restricción es la misma que el atractivo: SQLite y un solo proceso, así que la escala horizontal y las funciones específicas de Postgres no están sobre la mesa.
- 5
Convex
Código disponible (FSL)· AmbosMejor para: Aplicaciones reactivas donde las consultas son código, no SQL
Un backend donde las consultas y las mutaciones son funciones TypeScript y el cliente se vuelve a renderizar cuando cambian sus resultados. Un modelo genuinamente distinto, y agradable. No es Postgres, así que las razones para querer Postgres no aplican. El código está bajo la Functional Source License, que pasa a Apache-2.0 dos años después de cada versión.
- 6
Nhost
Código abierto· AmbosMejor para: Postgres y GraphQL con la auth ya cableada
Empaqueta Postgres, Hasura, auth, almacenamiento y funciones en una sola plataforma, así que tienes el modelo GraphQL sin montarlo. Encaja bien si lo que querías era Hasura más las piezas de alrededor.
- 7
Neon
Código abierto (núcleo)· AlojadoMejor para: Postgres serverless con branching, y nada más
Postgres gestionado con ramas de base de datos y escalado a cero, parte de Databricks desde mayo de 2025. Deliberadamente no es un backend — sin auth, sin API, sin panel de administración — lo que lo convierte en una buena base sobre la que poner cualquiera de las otras herramientas de aquí, Rebase incluido.
- 8
Hasura
Código abierto (Apache-2.0)· AmbosMejor para: GraphQL, sobre todo federado entre varias fuentes
Genera una API GraphQL sobre Postgres y otras fuentes, con un sistema de permisos definido en metadatos. La opción más fuerte de esta lista si GraphQL es una decisión de producto y no una preferencia. Te da una API y una consola, no un back office para gente no técnica.
- 9
Directus
Código disponible (MSCL)· AmbosMejor para: Una interfaz editorial madura sobre una base de datos existente
Envuelve una base de datos SQL en una API REST y GraphQL y una aplicación de administración bien hecha, y funciona con un esquema que ya tengas. Los permisos se aplican en la capa de Directus y no en la base de datos, y la aplicación es dueña de un conjunto de tablas propias.
Rebase y Firebase, respondido
¿Cuál es la mejor alternativa de código abierto a Firebase?
Supabase y Appwrite son las dos respuestas habituales, y responden a preguntas distintas. Supabase si quieres pasarte a Postgres y a SQL; Appwrite si te gustaba la forma de Firebase y quieres autoalojar algo parecido. Si parte de por qué te vas es que la consola de Firebase no la pueden usar tus colegas que no son ingenieros, Rebase añade un panel de administración generado al lado Postgres de esa elección.
¿Cómo de difícil es migrar de Firestore a Postgres?
El trabajo es el modelado, no la copia. Las colecciones de documentos anidados tienen que convertirse en tablas y claves foráneas, y decisiones que Firestore te dejaba aplazar — qué es una relación, qué es obligatorio, qué es único — hay que tomarlas todas. Espera que tarde lo que de complicado sea el modelo de datos, y espera recuperar joins, transacciones y restricciones a cambio.
¿Hay una alternativa a Firebase con soporte offline?
No una equivalente, y merece la pena decirlo sin rodeos. La persistencia offline de Firebase es excepcional y nada de esta lista la iguala. Si tu aplicación tiene que funcionar con mala conexión, esa es una razón genuina para quedarte, o para mantener Firebase en el cliente y mover solo las partes que necesitan SQL.
¿Qué es más barato que Firebase?
Casi cualquier cosa autoalojada, pasada una escala pequeña — no porque el software sea más barato sino porque el modelo de precio es distinto. Firestore cobra por lectura, así que el coste sigue al uso de una forma difícil de prever; una instancia de Postgres cobra por la instancia. Por debajo de cierto tamaño, el plan gratuito de Firebase es muy difícil de batir.
¿Puedo moverme poco a poco en vez de todo de golpe?
Normalmente sí, y normalmente es el mejor plan. Firebase Auth puede quedarse mientras se mueven los datos, o los datos de una función pueden moverse primero mientras el resto se queda. Un cambio completo de golpe sobre un producto en producción es un riesgo mucho mayor del que la migración justifica.
No te fíes de nuestra palabra.
La comparación que importa es la que ejecutas tú. Apunta Rebase a una base de datos Postgres que ya tengas y mira cómo aguanta al lado de Firebase.