Um protótipo criado por Vibe Coding aceita cadastro, login e upload em poucas horas. 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 PostgreSQL acompanhado por APIs, Auth, Storage, Realtime, Edge Functions e filas. A combinação atende jornadas comuns sem esconder o banco. Você ainda precisa modelar tabelas, escrever policies de RLS (Row Level Security), proteger chaves administrativas e preparar a recuperação dos arquivos.

O melhor modo de revisar esse backend é acompanhar um cliente realista. Ele cria uma sessão, grava o próprio perfil, envia um contrato e recebe uma atualização na tela. Em cada etapa, use uma segunda sessão para tentar o mesmo acesso. O resultado mostra 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

PostgREST expõe tabelas pela API REST e 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. Crie dois cadastros de teste. A primeira sessão deve ler e alterar o próprio perfil. A segunda deve receber o resultado previsto ao consultar o identificador que não lhe pertence.

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 contrato exige banco e Storage

Depois de criar o perfil, o cliente envia um contrato. 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.

A atualização em tempo real respeita a mesma permissã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. O canal precisa manter a mesma separação aplicada à consulta inicial.

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.

Funções protegem segredos e filas retiram espera

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, 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.

O backend persistente escolhe a conexão adequada

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.

Timeouts e 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

O PostgreSQL preserva ferramentas conhecidas para transportar schema e tabelas. Auth, Storage, Realtime e funções carregam configurações e comportamentos adicionais. Um pg_dump concluído não demonstra que login, arquivos e eventos funcionam em 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.

Termine com as duas sessões abertas. O primeiro cliente entra, altera o perfil, envia o contrato e recebe a atualização. O segundo tenta acessar cada recurso e encontra a recusa definida. Quando esse percurso sobrevive à recuperação do banco e dos objetos, você conhece o backend que foi criado.