Um protótipo criado por Vibe Coding pode aceitar cadastro, login e upload enquanto ainda permite acessos indevidos. A tela funcionando pode esconder três permissões diferentes: acessar a aplicação, consultar uma linha no PostgreSQL e abrir um objeto no Storage. O Supabase reúne essas partes, mas a revisão precisa separá-las.

Eu recomendo o Supabase para aplicações web e móveis porque ele mantém PostgreSQL, autenticação e arquivos no mesmo projeto. Essa proximidade reduz integrações iniciais. Ela também exige que você entenda qual componente autorizou cada ação antes de publicar o sistema.

Direto ao ponto

O Supabase oferece um backend baseado em PostgreSQL, com autenticação, armazenamento de arquivos e recursos de comunicação em tempo real. Você ainda precisa modelar tabelas, escrever policies de RLS (Row Level Security), proteger chaves administrativas e preparar a recuperação dos arquivos.

Revise esse backend por uma jornada de teste: crie uma sessão, grave o próprio perfil, envie um contrato e receba uma atualização na tela. Em cada etapa, use uma segunda sessão para tentar o mesmo acesso. Assim você confere se a integração funciona e se a separação entre clientes foi preservada.

O login identifica o cliente

O Auth administra identidades e emite tokens para a sessão. Depois do login, o frontend envia esse token nas chamadas feitas às APIs do projeto. O banco usa a identidade da sessão durante a avaliação das policies.

Autenticação e autorização não são equivalentes. Um cliente autenticado pode continuar sem permissão para abrir o contrato de outro cliente. Esse limite deve existir no banco ou no backend que medeia a leitura, pois esconder um botão na interface não impede uma chamada direta ao endereço.

Uma chave administrativa contorna a RLS e precisa permanecer fora do navegador. Revise o bundle publicado e as variáveis expostas pelo framework. A chave pública adequada trabalha junto da sessão, enquanto segredos usados por integrações ficam numa função ou num backend protegido.

A policy controla a linha no PostgreSQL

O PostgREST expõe tabelas pela API REST e o pg_graphql oferece consultas GraphQL. Essas interfaces permitem que o frontend leia e grave sem abrir uma conexão administrativa com o PostgreSQL. A policy de RLS define quais linhas ficam disponíveis para a sessão.

Na tabela de perfis, relacione o identificador do cliente ao usuário autenticado e teste com duas sessões. Ao ler e alterar o próprio perfil na primeira, você confere o acesso autorizado. Na segunda, a consulta precisa ocultar a linha alheia. Uma lista vazia pode ser o resultado correto da policy de leitura, mesmo quando a API responde sem erro.

O papel postgres no serviço Cloud possui privilégios administrativos com restrições descritas na documentação de superusuário. O acesso ao PostgreSQL continua amplo, porém a plataforma gerenciada preserva limites operacionais. Trate extensões e comandos administrativos de acordo com o suporte atual do serviço.

O arquivo fica no Storage e seus metadados no PostgreSQL

Depois de criar o perfil, o cliente envia um contrato. O Storage guarda o objeto num bucket e mantém metadados no PostgreSQL. A aplicação grava a relação entre arquivo e cadastro, além da política usada para permitir a leitura.

Uma URL assinada concede acesso durante a validade a qualquer cliente que a possua. Para conferir a sessão a cada download, sirva o arquivo por uma função autenticada. Em ambos os casos, teste o endereço fora da sessão original e depois do prazo configurado.

A recuperação merece um ensaio separado. O backup do banco inclui os metadados, mas não os objetos do Storage, conforme a documentação de backups. Restaurar a linha do contrato sem restaurar o arquivo deixa a interface apontando para um objeto ausente.

Prepare uma cópia externa dos objetos e restaure ambos num ambiente de teste. O cliente deve entrar, consultar o perfil e abrir o contrato recuperado. Esse percurso mede o que a cópia realmente devolve à aplicação. O artigo sobre infraestrutura para Vibe Coding acompanha os testes separados para banco e upload.

A atualização em tempo real respeita a mesma permissão

O Realtime envia presença, broadcast e alterações do banco por WebSocket. Num quadro colaborativo, o navegador recebe uma atualização sem recarregar a página. Nas alterações de tabelas, a RLS controla quais registros podem chegar à sessão. Os recursos Broadcast e Presence exigem configuração de canais privados e policies próprias, conforme a documentação de autorização do Realtime.

Abra duas sessões e altere um registro visível apenas para a primeira. A atualização deve chegar ao cliente autorizado e permanecer ausente na outra sessão. Em seguida, interrompa a conexão e verifique como a interface busca o estado atual ao retornar.

Para busca semântica, pgvector mantém embeddings no PostgreSQL. Preserve a relação do vetor com o documento original e aplique os filtros de acesso antes de enviar os trechos ao modelo. Uma consulta semelhante não pode atravessar a separação entre clientes. A explicação sobre Vectorize e os serviços de IA da Cloudflare examina essa relação entre documento, filtro e resposta numa arquitetura diferente.

A função protege a credencial e a fila executa o trabalho demorado

Uma Edge Function executa JavaScript ou TypeScript sobre Deno. Ela pode receber um webhook de pagamento e usar uma credencial privada para consultar o provedor. O log deve relacionar o identificador do evento à resposta externa, sem registrar o segredo.

Para trabalho demorado, o Supabase Queues usa pgmq no PostgreSQL. A função grava a mensagem, devolve um identificador e permite que outro processo continue depois. Como uma mensagem pode reaparecer, o consumidor reconhece o evento já processado antes de repetir uma cobrança ou notificação.

Esses componentes não corrigem uma jornada indefinida. Especifique a resposta para webhook inválido, provedor lento e tarefa repetida. Depois execute cada situação no ambiente de teste e confira banco, log e efeito externo.

Conexão direta ou pool para acessar o banco

Uma aplicação Laravel persistente pode usar conexão direta ou o Supavisor em modo de sessão, conforme a rede e a duração das conexões. Funções serverless costumam usar o pool em modo de transação. Esse modo não aceita prepared statements, portanto a biblioteca precisa receber a configuração compatível.

Os timeouts e a espera por conexão não se resolvem apenas com outro endereço. Consulte o tempo das queries, o número de sessões abertas e o plano de execução. O artigo da Promovaweb sobre Laravel para Vibe Coding mostra como as convenções do framework apoiam essa revisão.

Revise o Supabase pela jornada do cliente

Na comparação entre os componentes, eu considero a portabilidade maior no PostgreSQL do que nos serviços integrados. O banco preserva ferramentas conhecidas para transportar schema e tabelas, enquanto Auth, Storage, Realtime e funções carregam configurações próprias. Por isso, um pg_dump concluído não demonstra que login, arquivos e eventos funcionam no outro ambiente. A comparação entre Supabase Cloud e self-hosted desenvolve essa responsabilidade.

No Plano IA Makers da Promovaweb, essa revisão acompanha a construção de aplicações com IA. Para um protótipo existente com banco e integrações difíceis de explicar, o Diagnóstico de Produto e Arquitetura da Dev Side Studio documenta a jornada principal e identifica onde cada componente participa.