Discussão: caminho para reduzir a dependência de custo do Supabase Cloud a longo prazo

[eudanielhenrique]

O README e o ARCHITECTURE.md já deixam claro que o Supabase é obrigatório (Auth + RLS + Realtime + Storage), e o repo já reconhece o problema de custo/cota no docs/runbooks/custo-e-cota-do-supabase.md (free tier: 5 GB/mês de egress, 500 MB de banco). Para quem está distribuindo isso via hostgator-setup-kit/ como produto (1 VPS por cliente), esse custo por instância tende a crescer com o uso e virar um problema de escala do negócio, não só de um cliente isolado.

Levantei o estado atual do repo antes de propor algo:

• scripts/selfhost-prelude.sql já permite rodar o baseline.sql num Postgres puro, mas com stubs de auth/storage — hoje só serve para CI (scripts/test-db.sh), não para produção (o próprio comentário do arquivo diz isso).
• O guia de self-host já cogita "Supabase self-hosted também funciona, mas não é coberto por este guia" — nunca testado/documentado.
• O app fala com o Supabase via @supabase/supabase-js + @supabase/ssr em ~75 arquivos, 104 .rpc(), 134 políticas de RLS e Realtime via postgres_changes/broadcast.

Isso sugere três rotas, com custo de engenharia bem diferente:

Rota	Mudança no código	Trade-off
Supabase Cloud pago	nenhuma	resolve a cota, mas custo recorrente por instância continua
Supabase self-hosted (stack oficial: Postgres+GoTrue+PostgREST+Realtime+Storage-api+Kong, via compose)	nenhuma — mesmo protocolo	some o custo de SaaS; soma ~5 serviços por VPS, backup/patch viram responsabilidade de quem instala
Postgres puro, sem Supabase	reescrever Auth, RLS→app-level, Realtime, Storage	zero dependência externa, mas é uma reescrita grande no core multi-tenant, com risco em produção

Dado que o diferencial do produto é "1 comando instala tudo", a rota do meio (Supabase self-hosted como opção no docker-compose.prod.yml, ao lado do Supabase Cloud como default) parece o caminho que resolve custo sem exigir reescrever Auth/RLS/Realtime/Storage. A rota "Postgres puro" eu deixaria como visão de longo prazo — os stubs de auth/storage já foram conscientemente declarados insuficientes para produção.

Abrindo para discutir: alguém já tentou o caminho self-hosted-Supabase em produção? Faz sentido como próximo passo, ou tem alguma razão pra não ter sido o caminho escolhido desde o início?

[JankoBrasil]

Ola. Não sou programador, mas como o banco do deskcomm já é em postgres poderia se estudar para fazer a comunicação com banco de dados interno, evitando a transmissão externa e ao mesmo tempo contornando o problema do limite ou custo do supabase.

[eudanielhenrique]

Sim, essa é uma possibilidade e acho que vale estudar. Inclusive, como o Deskcomm já utiliza PostgreSQL, manter o banco internamente poderia realmente reduzir a dependência externa e os custos do Supabase Cloud.

O ponto é que o Deskcomm não utiliza o Supabase apenas como banco de dados. Existem outras partes da aplicação que dependem da infraestrutura do Supabase, como autenticação/login, Storage para arquivos e imagens, Realtime e a própria camada de API/permissões.

Então não seria simplesmente trocar o banco do Supabase por um PostgreSQL interno. Teríamos que analisar quais recursos do Supabase Cloud o Deskcomm utiliza e, para cada um deles, verificar se conseguimos manter internamente ou se precisaríamos substituir por outra solução.

Por isso acredito que existem dois caminhos para estudar:

1. Manter a arquitetura baseada em Supabase e avaliar até onde conseguimos levar isso para uma infraestrutura própria/self-hosted.

2. Fazer uma arquitetura mais independente, usando PostgreSQL diretamente e substituindo os demais serviços do Supabase por soluções próprias ou alternativas.

O segundo caminho pode eliminar praticamente toda a dependência do Supabase, mas provavelmente exigiria mais alterações no Deskcomm.

Então a ideia de utilizar o PostgreSQL interno faz sentido. O que precisamos avaliar é o que existe "ao redor" do PostgreSQL antes de concluir que basta fazer essa troca.

[NathanMIlke]

Eu estou criando o sistema minha própria empresa.

A VPS que estou usando é na AWS, tem com substituir o supabase para rodar tudo na AWS?

[eudanielhenrique]

Não uso AWS mas acredito que sim, da uma olhada na doc do supabase:
https://supabase.com/docs/guides/self-hosting

mas e como expliquei tem algumas coisas que não tem no Supabase self-hosted, uma duvida porque esta utilizando o sistema na AWS.

[NathanMIlke]

VOcê quer saber porque estou com o sistema na AWS? Não entendi se foi uma pergunta, amigo

[eudanielhenrique]

Isso mesmo @NathanMIlke

[NathanMIlke]

Eu já rodo na AWS o meu sistema de gestão de locação e o meu site onde o cliente faz reservas tudo por lá, o CRM eu fiz algumas conexões com sistema de locação, ai achei melhor colocar na VPS também, porque o bot precisa consultar o CRM para saber de disponibilidade de etc