Cloudflare R2 vs Supabase Storage: cuándo añadir R2 en 2026

El object storage es un namespace plano de archivos servidos por HTTP, facturado de dos formas: por los gigabytes que guardas y por los gigabytes que mueves. Si tienes un SaaS sobre Supabase, ya tienes object storage. Así que la pregunta real en 2026 casi nunca es qué proveedor elegir desde cero. Es si el storage incluido en Supabase basta, o si añades Cloudflare R2 para los medios pesados. La respuesta depende casi solo de un número: el egress.

En breve. Mantén los archivos en Supabase Storage cuando son privados, ligados a un usuario logueado y se sirven a poco volumen. La integración con la row-level security y las transformaciones de imagen incluidas valen más que el egress que ahorrarías. Añade Cloudflare R2 cuando sirves medios públicos a gran escala: su egress a coste cero convierte una factura que sube con el éxito del producto en una que sube solo con lo que almacenas. Muchos equipos acaban usando los dos, divididos por la línea público/privado.

Cuánto cuestan en 2026

Los dos servicios ponen precio al almacenamiento a menos de un tercio de distancia. Ponen precio a la salida de bytes a un orden de magnitud de distancia. En esa brecha se decide todo.

• Almacenamiento por GB al mes. R2 cuesta $0.015 en su tier Standard y $0.01 en Infrequent Access. Supabase Storage incluye 100 GB en el plan Pro de $25, luego $0.021 por GB. Solo por bytes almacenados R2 es más barato, pero el almacenamiento rara vez es la partida que duele.
• Egress hacia internet. R2 no cobra nada, a través de la API S3, la API de Workers, el dominio r2.dev o un dominio propio. Supabase factura el egress a $0.09 por GB sin caché y $0.03 por GB servido desde su CDN, con 250 GB incluidos en el plan Pro. Esta es la diferencia que se acumula.
• Operaciones. R2 cobra $4.50 por millón de operaciones Class A (escrituras, list) y $0.36 por millón de Class B (lecturas). Supabase cuenta las peticiones al storage dentro de su conteo normal de peticiones, en lugar de facturar por operación sobre el objeto.
• Cuota gratuita. R2 da 10 GB de almacenamiento, 1 millón de operaciones Class A y 10 millones de Class B cada mes. El plan Free de Supabase incluye 1 GB de file storage y 5 GB de egress, compartidos en todo el proyecto.

Son precios de tarifa en dólares, antes de cualquier descuento por volumen. Las cifras vienen directas de la página de precios de R2 y de la documentación de precios de Supabase Storage. Contrástalas con tu tráfico real antes de decidir.

La cuenta del egress, la parte que nadie hace hasta que llega la factura

Dos hechos sobre el egress de Supabase deciden buena parte de esta comparación, y los dos son fáciles de pasar por alto.

Primero, el egress incluido es compartido. Los 250 GB del plan Pro no son una cuota para el storage. Son un único pool consumido a la vez por las consultas a la base de datos, las llamadas a Auth, los canales Realtime, las Edge Functions y las descargas del storage. Un dashboard con muchas consultas puede gastar la mayor parte de esa cuota antes de servir una sola imagen. El titular "250 GB incluidos" es el techo para todo el backend, no para los medios.

Segundo, el egress en caché y sin caché cuestan cifras distintas. Los bytes servidos desde la caché del CDN de Supabase cuestan $0.03 por GB. Los bytes que fallan la caché y llegan al origen cuestan $0.09 por GB, igual que el S3 clásico. Un asset público bien cacheado cuesta un tercio en servirse frente a uno sin caché, y por eso la tasa de acierto de caché, no el tráfico bruto, es el dato que mueve la factura del storage en Supabase. Supabase triplicó el descuento de caché y duplicó la cuota incluida en una actualización de precios de 2025, así que las comparaciones viejas que citan un $0.09 fijo están desfasadas.

Pongámosle números. Un vídeo de producto de 50 MB descargado 20.000 veces en un mes son unos 1 TB de egress. En Supabase Pro, pasado el pool incluido, ese único asset cuesta unos $30 si cada byte está en caché y unos $90 si ninguno lo está. En R2 ese mismo terabyte no cuesta nada en egress, más unos céntimos de lecturas Class B. Un solo archivo popular basta para justificar un segundo bucket.

Dónde gana Supabase Storage

El motivo para mantener los archivos en Supabase no es el precio. Es que el storage ya está conectado al resto de tu stack.

La autorización viene de la base de datos. Un objeto del storage se rige por las mismas políticas de row-level security que tus tablas. Un usuario logueado lee solo los archivos de su tenant, gracias a una política que hace el join con la fila que referencia el archivo. Sin segundo modelo IAM, sin rotación de claves aparte, sin gestión de signed URLs. Para los archivos privados ligados al usuario es esto lo que importa, y R2 no tiene equivalente.

Las transformaciones de imagen están incluidas. Supabase redimensiona y reconvierte imágenes al vuelo a través de su API de transformación por $5 cada 1.000 imágenes de origen, las primeras 100 gratis, y convierte a WebP de forma automática para los navegadores que lo soportan. R2 no tiene transformación nativa: añadirías Cloudflare Images como producto aparte o usarías un Worker de transformación. Si sirves avatares, miniaturas o sets de imágenes responsive, esa pipeline incluida es un motivo concreto para dejar las imágenes en Supabase.

Un servicio, un solo SDK. Subidas, descargas y políticas de acceso usan el mismo cliente de Supabase que ya llamas para las consultas. El Storage habla además el protocolo S3 y soporta subidas reanudables de hasta 50 GB por archivo en el plan Pro, así que los archivos grandes y el tooling S3 estándar funcionan sin salir de la plataforma.

Dónde gana Cloudflare R2

R2 se gana el sitio en el momento en que los bytes salen de tus servidores en cantidad.

Egress cero, a cualquier escala. Es el titular, y aguanta. Servir 5 TB o 50 TB de medios públicos cuesta lo mismo en egress: nada. Una factura que en Supabase o S3 subiría con cada compartido, cada embed y cada pico de atención se queda en cambio plana y sigue solo lo que almacenas. Para vídeo, assets descargables o imágenes servidas de forma amplia por CDN, no hay competencia.

Almacenamiento más barato y un tier frío. El almacenamiento Standard cuesta $0.015 por GB, e Infrequent Access lo baja a $0.01 para los datos que lees poco, con $0.01 por GB de recuperación y una duración mínima de 30 días. Para subidas de usuario de cola larga, backups o logs que quedan intactos durante meses, el tier frío queda por debajo del $0.021 fijo de Supabase.

Ha crecido más allá del simple object storage. R2 ahora ofrece event notifications que envían a una cola y activan un Worker en cada cambio, y R2 Data Catalog, una capa gestionada de Apache Iceberg para consultar objetos como tablas. Supabase respondió el mismo año con los Analytics Buckets, también basados en Iceberg. Los dos convergen hacia el mismo futuro analítico desde puntos opuestos, señal de que la elección del storage en sí se está estrechando a egress e integración.

El punto de equilibrio: cuándo añadir R2 de verdad

El detonante no son los bytes almacenados. La brecha entre $0.015 y $0.021 por GB es real pero pequeña, y tendrías que almacenar terabytes para que cuente por sí sola. El detonante es el egress.

La línea honesta: mientras el egress de tus medios públicos quepa dentro del egress que tu plan ya incluye, después del tráfico de base de datos y API que comparten el pool, Supabase Storage es prácticamente gratis con la suscripción, y añadir R2 es complejidad prematura. Cuando las descargas de medios se vuelven la partida principal de tu factura de Supabase, de cientos de gigabytes a terabytes al mes, el egress cero de R2 gana con claridad, incluso contando la gestión de un segundo servicio.

La señal más clara es un grupo pequeño de assets que genera tráfico desproporcionado: un vídeo de lanzamiento, una descarga popular, una imagen pública incrustada por medio internet. El día en que el egress de ese archivo aparece como una cifra real en la factura, mueve los medios públicos a R2 y deja el resto donde está.

El esquema híbrido en el que acaban muchos SaaS

La división que funciona corre por la línea público/privado, y coincide también con la línea del egress.

Los archivos privados y ligados al auth se quedan en Supabase Storage: datos de perfil, documentos por tenant, CSVs subidos, todo aquello donde el join de la RLS hace autorización de verdad y el tráfico es modesto. Los medios públicos y servidos de forma amplia pasan a R2 detrás de un CDN de Cloudflare: imágenes de marketing, fotos de producto, vídeo, recursos descargables, todo aquello cuyo público es cualquiera y cuyo coste es el egress.

Mover un archivo fuera de Supabase te cuesta dos cosas, y cada una la sustituyes de forma consciente. Pierdes la autorización RLS, así que los medios públicos en R2 los sirves en abierto, detrás de un Worker que comprueba una sesión antes de servir el objeto, o con signed URLs con caducidad. Pierdes las transformaciones de imagen incluidas, así que pre-generas las variantes, añades Cloudflare Images o usas un Worker de transformación. Para assets de verdad públicos ninguna de las dos pérdidas molesta: no hay usuario que autorizar, y las variantes se generan una sola vez.

Migrar los medios públicos de Supabase a R2

La migración es más pesada que difícil, y la copia de bytes es la parte fácil. Super Slurper de Cloudflare tira de S3 y Google Cloud Storage, no de Supabase, así que aquí no hay un import de un clic. En su lugar apuntas rclone al endpoint compatible con S3 de Supabase como origen y R2 como destino, y lo dejas transferir los objetos. Un movimiento puntual de unos cientos de gigabytes corre en una tarde.

El trabajo real es la capa de acceso, y lo haces antes de copiar nada. Cada camino de código que tomaba un archivo a través del cliente de Supabase, apoyándose en la RLS para la autorización, hay que reescribirlo para tomarlo de R2 con su nuevo modelo: público para los assets abiertos, un signed URL o una comprobación con Worker para lo que aún necesita protección. Mapea primero esos caminos. Luego mantén los dos stores en paralelo al menos un ciclo de facturación: escribe las nuevas subidas en ambos, lee primero de R2 con Supabase como fallback, y deja de escribir en Supabase solo cuando el camino de lectura desde R2 se vea limpio en los logs. Cambia las lecturas antes que las escrituras, y las escrituras al final.

Qué elegimos por defecto en 2026

Para un SaaS nuevo donde Supabase ya es la base de datos y la capa de auth, nuestro default es empezar solo con Supabase Storage. Es un servicio menos, la autorización es gratis, y la mayoría de los productos nunca empuja suficiente egress público como para necesitar más. Añadimos R2 solo cuando la forma del tráfico lo pide: un producto cargado de contenido, una biblioteca de medios, una descarga pública que crece con el marketing más que con el número de usuarios.

Cuando R2 entra, entra para una sola tarea, los medios públicos detrás de un CDN, mientras Supabase se queda con todo lo ligado a un usuario. La trampa es apostar por R2 desde el primer día porque el titular del egress cero es atractivo. Un segundo servicio de storage que aún no necesitas es complejidad que pagas en cada ruta de subida, cada comprobación de acceso y cada migración, mucho antes de que te ahorre un céntimo. El almacenamiento es fontanería. Añade la segunda tubería cuando la primera esté de verdad bajo presión, no antes.

Si tu decisión también tiene que sopesar Amazon S3, por una infraestructura AWS existente o una certificación de cumplimiento concreta, tratamos la comparación a tres en Cloudflare R2 vs S3 vs Supabase Storage.