¿Debería tu backend creado con IA dejar Firebase?

Una aplicación debería dejar Firebase cuando su modelo de datos, sus reglas de autorización o sus flujos del servidor sean más difíciles de entender que el propio producto. No debería irse solo porque el equipo haya oído que Postgres es más serio. Una reescritura apresurada puede sustituir unas limitaciones por una caída, cuentas perdidas y meses de comportamientos divididos entre dos sistemas.

Para la mayoría de los equipos que han superado Firestore, Supabase es la vía intermedia práctica: datos relacionales, SQL, autenticación administrada, almacenamiento, funciones y una API generada en un solo servicio. Un servicio de Postgres administrado ofrece a los equipos con experiencia más control y menos convenciones de plataforma, pero también los obliga a montar autenticación, API, almacenamiento de archivos, trabajos en segundo plano, observabilidad y despliegue. Quedarse en Firebase aún puede ser lo correcto cuando el modelo documental encaja y el equipo puede reparar sus reglas y funciones sin luchar contra la plataforma.

El destino depende del coste que ya no puedes seguir pagando

Elige el destino al nombrar la limitación que ya consume tiempo de ingeniería. Si nadie puede expresarla en una frase, el equipo no está listo para migrar. Una queja vaga como «Firebase no escala» no es un diagnóstico. Firestore puede manejar cargas grandes; la pregunta útil es si sus patrones de acceso y su modelo de consistencia todavía encajan con esta aplicación.

Firebase sigue siendo adecuado cuando los clientes leen y escriben sobre todo documentos independientes, importa el uso sin conexión, los escuchadores en tiempo real son centrales y Security Rules puede expresar el acceso sin duplicar el estado del negocio. El caso a favor de migrar crece cuando una acción debe actualizar varios registros relacionados, los informes necesitan unir colecciones, la integridad referencial debe vivir en la base de datos o Cloud Functions es el único lugar donde alguien entiende las reglas reales.

Supabase encaja con equipos que quieren la semántica de Postgres sin construir cada servicio que la rodea. Reduce la cantidad de decisiones durante el traslado, algo relevante cuando una herramienta de IA ensambló el código actual y nadie tiene un mapa fiable. Sus convenciones también fijan límites: Supabase Auth tiene su propio ciclo de vida, la API de datos generada depende de la seguridad por fila y las funciones de la plataforma no son idénticas a un servidor de aplicaciones general.

Postgres administrado encaja cuando el equipo ya sabe qué framework web, proveedor de identidad, sistema de trabajos, servicio de almacenamiento y conjunto de monitorización quiere. La base de datos es portable, pero el equipo debe diseñar y operar el backend. Esa libertad solo existe si alguien se hace cargo de las decisiones.

Usa una tabla sencilla antes de hablar de proveedores. Da un punto al destino favorecido por cada afirmación:

La puntuación no toma la decisión. Hace visible el argumento. Toda fila que nadie pueda puntuar con pruebas se convierte en una tarea de investigación previa a la migración.

El esfuerzo de migración se esconde en el comportamiento, no en el número de registros

Un millón de documentos sencillos puede ser más fácil de mover que diez mil cuyo significado dependa de disparadores, marcas de tiempo del cliente, contadores desnormalizados y Security Rules. La cantidad de registros afecta al tiempo de transferencia. El acoplamiento del comportamiento determina el proyecto.

Empieza por trazar todas las rutas que pueden cambiar el estado persistente. En un código generado por IA, no supongas que el cliente de base de datos evidente es el único escritor. El código del navegador puede escribir directamente en Firestore, las rutas del servidor pueden usar Admin SDK, las funciones programadas pueden reparar contadores, los webhooks pueden actualizar pagos y los scripts de despliegue pueden sembrar documentos. Busca inicializaciones de SDK, nombres de colecciones, funciones invocables, llamadas a depósitos de archivos y variables de entorno. Compara después ese mapa con los registros de producción y la configuración de la nube. Buscar solo en el código no encuentra funciones desplegadas que ya no figuran en el repositorio.

Clasifica cada escritura según la garantía que necesita. Editar un perfil suele tolerar una actualización directa. Confirmar un pedido puede exigir una transacción, idempotencia, un evento inmutable y una política de reintentos. Un contador mantenido por un disparador de Firestore puede convertirse en un agregado SQL, un disparador de base de datos o una proyección asíncrona. Los tres diseños fallan de manera distinta. Copiar el disparador línea por línea a una función nueva conserva una solución antigua después de que la base de datos haya eliminado la limitación original.

Estima el trabajo en cuatro grupos: transformación de datos, cambio de identidad, sustitución de flujos e integración del cliente. La transformación incluye aplanar documentos anidados, convertir valores repetidos en tablas, elegir tipos y resolver referencias huérfanas. El cambio de identidad incluye hashes de contraseñas, proveedores vinculados, sesiones, plantillas de correo, URL de redirección y recuperación de cuentas. La sustitución de flujos cubre funciones, colas, tareas programadas, webhooks y eventos de almacenamiento. La integración del cliente cubre cambios de consultas, estados de carga, supuestos sobre el trabajo sin conexión, gestión de errores y comprobaciones de autorización.

Un archivo de inventario vuelve revisable la estimación. Puede ser un JSON sencillo guardado junto al código de migración:

{
  "source": "firestore",
  "collections": {
    "orders": {
      "writers": ["web-checkout", "payment-webhook"],
      "readers": ["account-page", "support-console"],
      "rules": ["owner-read", "support-read"],
      "side_effects": ["send-receipt", "increment-customer-total"]
    }
  }
}

El artefacto evita un fallo conocido: el equipo migra las pantallas visibles, declara terminada la base de datos y descubre después que un webhook antiguo sigue escribiendo solo en Firestore. Añade cada escritor antes de asignar fechas. Si una colección tiene un escritor desconocido o un campo sin explicar, la investigación no ha terminado.

Una exportación de Firestore es un volcado de origen, no un esquema de Postgres

La exportación administrada de Cloud Firestore produce archivos de registro LevelDB y metadatos en Cloud Storage. La documentación de Firebase la describe como una exportación que puede importarse en otra base Firestore o cargarse en BigQuery bajo ciertas condiciones. No es un volcado relacional que pg_restore pueda consumir, y tampoco es una instantánea exacta tomada al iniciar la operación. Trátala como material de origen para una transformación controlada.

La migración necesita una relación explícita entre rutas de documentos y tablas. Un documento como customers/{customerId}/orders/{orderId} contiene una relación en su ruta. En Postgres, esa relación normalmente pertenece a una clave foránea orders.customer_id. Las matrices de etiquetas primitivas pueden seguir siendo matrices. Las matrices de objetos que cambian de forma independiente suelen convertirse en filas hijas. Los campos de mapa pueden convertirse en columnas tipadas cuando el producto los consulta, o en jsonb cuando su forma es realmente abierta. Elegir jsonb para cada documento facilita la primera importación y conserva las debilidades del modelo anterior.

Firestore permite campos ausentes y variaciones de tipo entre documentos. Postgres pide un tipo y permite que el esquema lo haga cumplir. Perfila el origen antes de cerrar las tablas: cuenta los campos ausentes, enumera los tipos observados, busca identificadores naturales duplicados e identifica referencias a documentos eliminados. Decide cómo tratar cada anomalía. Una conversión silenciosa, como convertir una fecha inválida en null, deja pasar la importación mientras traslada un error latente a producción.

Para Supabase, las herramientas comunitarias de migración desde Firebase pueden convertir colecciones de Firestore en JSON e importar datos transformados, pero no entienden las relaciones pretendidas por la aplicación. Para Postgres administrado, suele ser más claro un extractor y cargador propio. En ambos casos, haz que la transformación sea determinista: el mismo registro de origen debe producir siempre la misma fila y el mismo identificador. Conserva una columna con el ID de origen hasta terminar la conciliación.

Un esquema de destino útil hace cumplir las afirmaciones que la aplicación ya formula. Este fragmento da una propiedad estable a los pedidos e impide que entregas repetidas de un webhook creen duplicados:

create table customers (
  id uuid primary key,
  firebase_uid text unique,
  email text not null
);

create table orders (
  id uuid primary key,
  customer_id uuid not null references customers(id),
  provider_event_id text not null unique,
  status text not null check (status in ('pending', 'paid', 'cancelled')),
  created_at timestamptz not null
);

Después de cargar, concilia hechos en vez de confiar en un código de salida correcto. Compara cantidades por categoría de negocio, sumas de dinero en la unidad monetaria mínima, fechas mínimas y máximas, propietarios distintos y una muestra de registros entre origen y destino. Guarda las consultas en control de versiones. Una migración que no se puede repetir y comprobar es una improvisación de una sola vez, no un proceso de lanzamiento.

La autenticación se mueve aparte de los datos de la aplicación

Las cuentas no son filas corrientes porque una cuenta válida incluye credenciales, identidades de proveedores, estado de verificación, sesiones, recuperación y referencias desde los datos del producto. Migrar una colección users no migra Firebase Authentication, aunque ambos usen el mismo UID.

Firebase CLI admite auth:export, y Firebase expone los parámetros de hash necesarios para importaciones compatibles. La guía de Supabase para migrar Firebase Auth usa una herramienta de dos partes: exporta usuarios de Firebase a JSON y los importa a la tabla de destino auth.users. La guía también pide conservar los parámetros SCRYPT de Firebase, entre ellos la clave de firma, el separador de sal, las rondas y el coste de memoria. Ese detalle marca la diferencia entre conservar el inicio de sesión normal de los usuarios con contraseña y obligar a todos a recuperar su cuenta.

No supongas que todas las identidades se transfieren bien. Inventaría cuentas con contraseña, enlaces por correo, usuarios de teléfono, anónimos y cada proveedor OAuth. Comprueba si una persona tiene proveedores vinculados bajo un solo UID. Verifica si el destino conserva los identificadores del proveedor y cómo trata correos duplicados. Las claims personalizadas necesitan un hogar explícito, quizá tablas de autorización o claims firmadas. Normalmente las sesiones no pasan entre sistemas de autenticación distintos, así que planifica la caducidad de tokens, la nueva autenticación y un mensaje claro para el usuario.

Hay tres patrones de cambio defendibles. Forzar un restablecimiento es lo más sencillo, pero genera solicitudes de soporte y debe ser una decisión de producto. Una importación masiva de hashes mantiene la verificación cuando el destino admite el algoritmo y los parámetros del origen. Una migración diferida valida la credencial antigua en el primer inicio de sesión, crea o actualiza la identidad de destino y deja de consultar el sistema anterior para ese usuario. La migración diferida reduce el alcance del primer día, pero alarga el periodo en que dos sistemas pueden conceder acceso.

Elijas lo que elijas, crea un mapa inmutable de identidades antes de mover las filas de negocio:

firebase_uid                         postgres_user_id
n7Yx...                              2d99150e-3b33-4afb-9c5b-7cbd20b91a4d

Nunca unas registros por correo durante la migración. Las personas cambian de dirección, los proveedores pueden normalizarla de modo distinto y suelen existir duplicados tras años de importaciones. Usa el UID de origen como identidad de migración y después adjunta el ID de destino. Prueba usuarios deshabilitados, no verificados, eliminados con datos persistentes, usuarios que solo usan un proveedor y recuperación de cuentas. El inicio de sesión feliz con contraseña demuestra muy poco.

La autorización debe reescribirse, no traducirse

Firestore Security Rules y la seguridad por fila de Postgres responden preguntas parecidas mediante modelos de ejecución distintos. Una traducción mecánica es peligrosa. Las reglas de Firestore evalúan una solicitud contra rutas de documentos y los datos propuestos. Las políticas de Postgres filtran filas para operaciones SQL, mientras los roles y permisos deciden a qué objetos accede quien llama. El código de servidor con credenciales privilegiadas puede saltarse ambos sistemas, así que la frontera de confianza importa tanto como la sintaxis.

Primero escribe una matriz de acceso en el lenguaje del producto. Para cada recurso, indica quién puede seleccionarlo, insertarlo, actualizarlo y borrarlo, además de qué campos o cambios de estado se permiten. «Los usuarios pueden actualizar su perfil» queda incompleto si la misma fila contiene is_admin. «Los propietarios pueden actualizar pedidos» es incorrecto si los clientes pueden cambiar status de pending a paid.

Una política de Supabase para consultar los pedidos propios podría verse así:

alter table orders enable row level security;

create policy "customers read own orders"
on orders for select
to authenticated
using (customer_id = auth.uid());

Esa política solo funciona si orders.customer_id guarda el mismo UUID que devuelve auth.uid(). Si la fila importada contiene un UID de Firebase como texto y el token nuevo contiene un UUID de Supabase, no devuelve filas. Si alguien desactiva la seguridad por fila para arreglar la pantalla, puede devolverlas todas. Por eso el mapa de identidades y el diseño del esquema forman parte de la revisión de autorización.

Postgres administrado por sí solo no ofrece auth.uid() salvo que la aplicación cree un contexto de sesión equivalente o filtre siempre mediante código de servidor confiable. Muchos equipos eligen lo segundo: los clientes llaman a una API, la API verifica la identidad y SQL recibe el ID autenticado como parámetro. Este modelo resulta más fácil de inspeccionar en un solo código, pero cada endpoint debe aplicar la autorización. El acceso directo desde el navegador exige roles y pruebas de políticas más estrictos.

Prueba la denegación, no solo el éxito. Para cada rol, intenta leer la fila de otro cliente, cambiar una columna de propiedad, actualizar un estado protegido, insertar un propietario ajeno e invocar la operación por cada ruta pública. Ejecuta estas pruebas con las mismas credenciales públicas y claims que usa el cliente. Una consulta desde la consola de administración no prueba el aislamiento.

Los flujos personalizados deciden si Supabase basta

Supabase suele bastar cuando el comportamiento puede vivir en restricciones SQL, funciones de base de datos, funciones edge, tareas programadas, webhooks y un número moderado de procesos en segundo plano. Postgres administrado resulta más claro cuando el producto necesita workers largos, runtimes especializados, colas complejas, redes privadas o un control del despliegue que choque con el modelo de funciones de la plataforma.

Enumera las Cloud Functions actuales por tipo de disparador, no por nombre de archivo. Las funciones HTTP son API. Las invocables vinculan al cliente con el protocolo de Firebase. Los disparadores de Firestore reaccionan a cambios de datos. Los hooks de autenticación reaccionan a eventos de identidad. Los de almacenamiento procesan archivos. Las funciones programadas realizan mantenimiento. Cada categoría necesita un destino con un comportamiento equivalente de entrega y reintento.

Presta especial atención a la entrega al menos una vez. Un webhook de pago, un evento de almacenamiento o un mensaje de cola puede llegar dos veces aunque normalmente no ocurra. El manejador nuevo debe reclamar el ID del evento en la misma transacción que cambia el estado. La restricción única del esquema anterior convierte la segunda entrega en un duplicado detectable. Una bandera en memoria o una línea de registro no ofrece esa garantía entre instancias.

No metas cada flujo en un disparador de base de datos solo porque Postgres pueda ejecutarlo. Los disparadores funcionan bien para invariantes locales y pequeños cambios derivados que deben compartir transacción. Son malos sitios para llamar a API externas, enviar correo o procesar medios lentamente. Esas acciones necesitan un trabajo duradero y un worker que reintente de manera idempotente. La base debe confirmar el cambio del negocio y encolar la intención a la vez.

La recomendación popular de reescribirlo todo en SQL atrae porque elimina código de aplicación. Es equivocada cuando esconde los flujos en funciones que el resto del equipo no puede desplegar, rastrear ni probar. Coloca las reglas de consistencia cerca de los datos. Coloca la coordinación en un servicio con registros, tiempos límite, reintentos y una persona responsable. Supabase puede alojar una versión pequeña de ese servicio; un diseño con Postgres administrado presupone que el equipo lo elegirá y operará en otro lugar.

La carga operativa es el trabajo que queda después del lanzamiento

La diferencia operativa no es «administrado frente a no administrado». Firebase, Supabase y Postgres administrado gestionan infraestructura en algún nivel. La comparación útil pregunta qué fallos siguen siendo tuyos y si el equipo puede detectarlos y repararlos.

Firebase elimina gran parte de la administración de la base, pero el equipo aún posee Security Rules, índices, cuotas, despliegues de funciones, sorpresas de costes, regiones y recuperación de la aplicación. Supabase administra Postgres y agrupa varios servicios, pero el equipo posee migraciones de esquema, políticas por fila, comportamiento de conexiones, rendimiento de consultas, compatibilidad de extensiones e interacción entre componentes. Un proveedor de Postgres administra el proceso de base de datos, copias y parte del mantenimiento mientras el equipo posee la capa API y los servicios auxiliares elegidos.

Pregunta quién realizará cinco trabajos recurrentes: aplicar un cambio de esquema sin romper clientes antiguos, restaurar datos a un punto conocido, responder a una credencial de servidor filtrada, diagnosticar una solicitud lenta entre servicios y rotar un secreto de autenticación. Si la respuesta es un fundador que nunca ha visto la configuración de despliegue, Postgres administrado más una pila propia es un primer paso demasiado grande. Si un equipo de backend con experiencia ya opera esos controles, las convenciones de plataforma quizá estorben más de lo que ayudan.

Las comparaciones de costes necesitan la misma carga y los mismos supuestos de fallo. Firestore cobra operaciones y almacenamiento según su modelo. Los planes de Postgres suelen agrupar cómputo y después limitar conexiones, memoria, almacenamiento o rendimiento. Una consulta que lee un agregado relacional no se compara con un cliente que obtiene cientos de documentos, y una instancia dimensionada para el pico no se compara con el coste inactivo sin servidores. Reproduce consultas parecidas a producción en un destino de pruebas y registra latencia, filas tocadas, conexiones y trabajo de ajuste. No extrapoles desde una demo vacía.

La portabilidad también tiene capas. Las tablas SQL se mueven entre proveedores de Postgres con más facilidad que los datos de Firestore hacia un esquema relacional. La autenticación, los metadatos de archivos, las API generadas, las políticas y las funciones edge específicas de Supabase aún crean trabajo de migración. Es aceptable cuando esos servicios ahorran hoy más trabajo del que podrían causar mañana. Llamar «sin dependencia» a cualquier backend oculta las dependencias que sí importan.

Un cambio seguro mantiene una autoridad para cada escritura

La migración más segura separa la copia de datos del cambio de autoridad. Durante la copia, Firestore sigue siendo la autoridad. Durante el cambio, cada entidad de negocio debe tener un solo escritor autorizado. Escribir en dos sistemas durante semanas sin conciliación crea dos versiones plausibles y hace más difícil volver atrás.

Usa esta secuencia como base:

1. Congela cambios de esquema e inventaría lectores, escritores, funciones, reglas, índices y secretos.
2. Construye el esquema de destino, el mapa de identidad, las pruebas de autorización y la importación determinista en un entorno aislado.
3. Ensaya una copia completa desde una exportación nueva, registra cuánto tarda y concilia hechos de negocio.
4. Copia los últimos datos, captura cambios ocurridos desde el comienzo y pausa las escrituras de origen para el delta final.
5. Cambia primero los escritores del servidor y después los clientes, vigila ambos sistemas y conserva una vuelta probada hasta que las escrituras nuevas la vuelvan insegura.

Un plan con poca interrupción puede usar captura de cambios o escrituras dobles temporales, pero necesita una regla de conflicto y un libro de conciliación. Registra el ID de operación de origen, la transacción de destino, la entidad, el resultado y el estado del reintento. Decide de antemano qué sistema gana si ambos cambian. Si nadie explica cómo reparar la segunda escritura fallida, la escritura doble no es segura.

Mantén la compatibilidad en el límite de la API cuando sea posible. Si los clientes ya llaman a una API, cambia su implementación de almacenamiento y conserva el contrato. Si hablan directamente con Firestore, introduce una capa de repositorio o una API antes de mover cada pantalla. Esta separación parece más lenta la primera semana y evita ediciones repetidas en el resto del lanzamiento.

Define la vuelta atrás como un procedimiento probado con fecha límite. Antes de empezar a escribir en el destino, puede consistir en devolver los clientes y descartar el destino. Después de crear registros exclusivos del destino, exige una transformación inversa o una pausa de escritura. Declara el evento exacto que cierra la ventana sencilla. Una copia de seguridad ayuda, pero no es un plan salvo que el equipo la haya restaurado y medido el tiempo.

Puede ser necesario reparar el código antes de mover el backend

Una migración amplifica todo lo que la aplicación actual no ha hecho explícito. Los proyectos generados suelen mezclar credenciales del navegador y del servidor, duplicar llamadas a la base entre componentes, confiar en IDs de propietario enviados por el cliente y esconder reglas de negocio en eventos de interfaz. Mover esas llamadas a Supabase o Postgres sin cambiar los límites transfiere los defectos.

Ejecuta la migración solo después de responder cuatro preguntas. ¿Qué módulos pueden acceder a la base? ¿Dónde se convierte la identidad del servidor en un ID confiable? ¿Qué servicio posee cada cambio de estado? ¿Qué entorno puede leer secretos privilegiados? Si las respuestas cambian por pantalla, crea primero un pequeño límite de acceso a datos. No necesita ser elegante. Debe volver visibles y comprobables todas las escrituras.

El manejo de secretos merece una revisión propia. La configuración web de Firebase identifica un proyecto y queda protegida por Security Rules y la configuración, mientras las credenciales de Admin SDK conceden acceso privilegiado. Supabase tiene credenciales públicas pensadas para trabajar con políticas por fila y credenciales privilegiadas de servidor que evitan restricciones normales. Las cadenas de conexión de Postgres administrado pertenecen normalmente al servidor, nunca al navegador. Los reemplazos automáticos suelen confundir estas categorías porque todas parecen variables de entorno.

FixMyMess puede auditar una aplicación de IA heredada, reparar su autenticación y lógica, reforzar la seguridad, refactorizar el código y preparar el despliegue antes o durante el traslado. El resultado útil no es cambiar de proveedor, sino tener un sistema cuya propiedad de datos, rutas privilegiadas y procedimiento de lanzamiento pueda explicar una persona.

No migres un código que no pueda superar una auditoría básica de escrituras. Estabiliza la identidad y las invariantes del negocio, elige el destino más pequeño que las soporte y ensaya hasta que la conciliación resulte rutinaria. Firebase, Supabase y Postgres administrado pueden ejecutar un producto sano. Ninguno puede aportar el modelo ausente de cómo debe comportarse el producto.