Por que deixamos de recomendar o Vercel Blob em favor do Supabase Storage

A Vercel é a rainha indiscutível da Developer Experience (DX). Quando eles lançaram o Vercel Blob, o mercado explodiu. Com duas linhas de código em uma Server Action, você pegava um PDF de um formulário e jogava na nuvem global (Edge). Sem AWS S3, sem dores de cabeça com CORS, sem políticas IAM complexas.

Neste artigo, vou explicar o limite técnico onde o Vercel Blob deixa a desejar em sistemas corporativos e por que o Supabase Storage se tornou o padrão de infraestrutura de arquivos.

---

1. A Ilusão da Facilidade

Fazer o upload de uma foto de perfil ou de um PDF público no Vercel Blob é incrível. O problema começa quando você precisa construir um sistema SaaS Multi-tenant corporativo.

Imagine um cenário comum: Um portal de contabilidade. A empresa de contabilidade sobe o arquivo holerite_joao.pdf. Obviamente, o João é o único funcionário que tem o direito de fazer o download desse arquivo. O Pedro não pode, e nenhum usuário deslogado pode.

No Vercel Blob, você não tem um banco de dados integrado que conheça os seus usuários. Portanto, para proteger o download, você é obrigado a:

1. Fazer upload do arquivo como privado.
2. Escrever lógicas complexas no Next.js (Middlewares ou Server Actions) onde você checa manualmente no seu banco se o usuário atual tem permissão.
3. Se tiver, você pede para a Vercel gerar um link temporário, entrega ao usuário e espera que ele consiga baixar antes de expirar.

Isso é engenharia imperativa. Você está programando a segurança manualmente com if/else no backend. Se um desenvolvedor júnior esquecer um if, o Pedro acaba de acessar o holerite do João.

---

2. A Supremacia do Supabase Storage (RLS)

O motivo de recomendarmos o armazenamento de arquivos no Supabase Storage é um só: Row Level Security (RLS).

O Supabase Storage não é um serviço isolado; ele mora lado a lado com o seu banco de dados PostgreSQL. Ele sabe exatamente quem está logado, a qual empresa esse usuário pertence, e qual o nível de acesso dele.

Ao invés de programar a segurança no Node.js/Next.js, nós escrevemos uma política de banco de dados (matemática e inquebrável):

-- Exemplo de Segurança em Banco (RLS)
CREATE POLICY "Apenas donos podem ler os próprios holerites" 
ON storage.objects FOR SELECT 
USING (
  bucket_id = 'holerites' AND 
  auth.uid()::text = (storage.foldername(name))[1]
);

O que isso significa na prática?

Significa que nós delegamos a segurança para o motor do banco de dados. Se o desenvolvedor tentar fazer uma requisição no frontend pedindo a foto errada, o próprio banco de dados intercepta o pedido e bloqueia, devolvendo um Erro 403.

Não existem mais if/else esquecidos. A infraestrutura passa a ser segura por padrão (Secure by Default).

---

3. Quando o Vercel Blob (ainda) faz sentido?

Se você está construindo um blog simples, um portfólio, ou qualquer site onde 100% dos arquivos sofrem upload para serem públicos (imagens para artigos, banners de e-commerce), o Vercel Blob é espetacular.

Mas se o seu negócio possui a palavra "Privacidade", "Multi-tenant", "SaaS B2B" ou "Usuários Logados", fuja de storages isolados. A integração nativa entre o Supabase Auth, o Postgres (RLS) e o Supabase Storage é a arquitetura definitiva para dormir tranquilo sabendo que os dados dos seus clientes estão blindados.