Supabase branching no es un backup. Solo va hacia adelante.

Encendiste el branching de Supabase porque parecía la forma cuidadosa de trabajar. Ahora hay una rama de preview al lado de tu proyecto, los cambios se prueban ahí antes de que nadie los vea, y todo el montaje se siente bastante más seguro que el mes pasado.

Y es más seguro. Solo que no es un backup, y la diferencia aparece exactamente un día.

Aquí está la parte que las guías de branching se saltan: una rama es una segunda base de datos al lado de la primera, no una versión anterior de ella. El branching es el sitio al que vas antes de hacer un cambio. Un backup es el sitio al que vas cuando algo ya salió mal. Encender el branching no deja una copia de tus datos en ninguna parte.

¿El branching de Supabase es un backup?

No. Una rama arranca como una base de datos vacía vestida con tu esquema, y nada en el branching devuelve una versión anterior de tus datos.

La propia documentación de Supabase es directa: «Las ramas nuevas no arrancan con ningún dato de tu proyecto principal. Esto busca proteger mejor tus datos sensibles de producción». Una rama se construye a partir de tus migraciones, y una migración describe la forma de una base de datos. Las tablas, las columnas, las policies. Nunca las filas.

Así que la rama que está junto a tu proyecto no es la copia del martes. Es una base de datos nueva que nunca ha visto a tus usuarios.

Si nunca has averiguado qué está copiando de verdad tu base de datos, ese es justo el encargo al que este artículo quiere mandarte, y tu plan resuelve casi todo en dos minutos.

Qué es una rama en realidad

Un segundo proyecto entero de Supabase, con todo lo suyo propio.

«Cada rama es un entorno separado con su propia instancia de Supabase y sus propias credenciales de API», así lo dice la documentación. Su propia cadena de conexión, sus propias claves, su propio Storage, sus propias cuentas de acceso, sus propias filas. Nada dentro está cableado al proyecto en el que están tus usuarios, que es precisamente lo que hace seguro romper cosas ahí.

Ese aislamiento es toda la funcionalidad, y también es la razón por la que no puede hacer de backup. La copia de tus datos que esperabas nunca se tomó, y el sitio donde irías a buscarla lleva vacío desde el día en que se creó.

Qué hace un merge, y qué no hace

Lleva tus cambios de esquema a producción. Nunca lleva filas, en ninguna dirección, en ningún momento.

Cuando haces merge, Supabase aplica las migraciones de tu rama a tu base de producción y despliega tus cambios de Edge Functions. Esa es toda la carga. Una tabla nueva, una columna nueva, una policy reescrita: eso viaja. Las filas que creaste mientras probabas se quedan en la rama, y las filas de producción se quedan exactamente como estaban, incluidas las que esperabas reemplazar.

La gente espera una versión de esto que no existe: un merge que meta la mano en producción y devuelva las cosas a como estaban. Lo que el branching tiene en su lugar es un despliegue, aplicado hacia adelante, sobre lo que haya en producción en ese momento.

Pero yo cloné mis datos de producción en la rama

Entonces tienes una copia de tus filas, y tres cosas sobre esa copia deciden lo que vale el día que la necesites.

Se puede hacer y no es nada exótico. La CLI de Supabase describe la opción como clonar los datos de producción a la base de datos de la rama, y la API de management acepta esa misma opción al crear una rama. Si la usaste, tu rama sí contiene tus datos.

• Se tomó una vez. El clon ocurre al crear la rama y después nada lo rellena. Cada pedido, cada registro y cada comentario desde entonces vive en producción y en ningún otro sitio, y esa es toda la diferencia entre una copia y un calendario.
• Está dentro de la misma cuenta. Una rama es otro proyecto bajo la misma organización, en la misma tarjeta, detrás del mismo acceso. Todas las formas de perder tu cuenta de Supabase se llevan la rama con ellas, y ese es un desastre distinto de romper tus propios datos.
• Nadie la ha leído de vuelta. Un clon que se quedó a medias es idéntico por fuera a uno que terminó, hasta el momento en que lo abres.

La rama es la parte diseñada para desaparecer

Una rama de preview se borra cuando su pull request se mergea o se cierra. Ese es el comportamiento documentado de la función.

Supabase llama a las ramas de preview «efímeras y adecuadas para pruebas concretas» y dice que «se borran automáticamente cuando una PR se mergea o se cierra». La otra clase, las ramas persistentes, son «de larga vida y recomendadas para entornos como staging, QA o desarrollo», y esas sobreviven al cierre de la pull request.

Así que con el ajuste por defecto, la rama que guarda tu única copia clonada es justo lo que tu flujo de trabajo tira el día en que el trabajo termina. Conservarla significa hacerla persistente, y una rama persistente es un segundo proyecto de Supabase encendido. Supabase ofrece branching en los planes de pago y lo factura por rama y por hora, en su página de precios.

Para qué sirve de verdad el branching

Para bastante, y este artículo sería deshonesto si no lo dijera.

Una rama es el sitio más barato que hay para descubrir que una migración borra una columna, antes de que borre la columna en la que están sentados tus clientes. Te deja ensayar un cambio de policy contra una base con la misma forma que la tuya, con sus propias claves, de modo que un error no alcanza a nadie. Le da a una IA un lugar donde equivocarse que no es tu app en producción. Un backup no puede hacer nada de eso.

El hueco está en qué clase de accidente cubre. El branching protege los cambios que pasan por una pull request. La mayor parte de lo que de verdad le cuesta los datos a la gente no pasa por ahí: un borrado en el editor de tablas de Supabase que alcanzó más filas de las previstas, un script de seed apuntado al proyecto en producción, una migración que escribió una IA y aprobaste a la una de la madrugada, una limpieza de lo que parecían datos de prueba. Ninguno de esos atraviesa una rama camino de producción, que es la misma razón por la que volver atrás el código no trae de vuelta una tabla borrada.

Esa segunda clase de accidente es lo que responde un backup. Está detrás de ti en el tiempo, guardando el estado de tu base de datos en un momento que puedes nombrar, para que un error cometido fuera de tu flujo de trabajo todavía tenga adónde volver.

Eso es también lo que es Reeve Care: copias programadas de tu base de datos de Supabase, guardadas fuera de tu cuenta de Supabase, leídas de vuelta y comprobadas antes de que ninguna cuente como hecha. Conecta tus buckets de Storage y los archivos que subieron tus usuarios viajan con ellas, así que una restauración devuelve las filas y las imágenes a las que esas filas apuntan.

Deja el branching encendido de todos modos. Nada de lo anterior es un argumento para apagarlo.

Qué hacer esta semana

Antes de cerrar esta pestaña, abre tu proyecto de Supabase y mira si algo está sacando una copia según un calendario. Esa única respuesta es todo el trabajo de hoy, y el branching no la cambia en ningún sentido. La checklist de seguridad de 10 minutos lo cubre junto al resto de lo que conviene confirmar en una app recién lanzada, y qué contiene una copia y qué hace de verdad el botón de restaurar está desplegado en la página de backups de Supabase.