Fly Postgres, Gerido pela Supabase

Artigo original ↗ Discussão no Hacker News ↗

A Fly.io está fazendo parceria com a Supabase para oferecer um serviço de PostgreSQL totalmente gerenciado na infraestrutura da Fly, preenchendo uma lacuna antiga para equipes que queriam a plataforma distribuída da Fly, mas dependiam de bancos gerenciados por confiabilidade. Os comentaristas analisam os trade-offs entre o Postgres da Fly, “automatizado, mas não gerenciado”, e a abordagem gerenciada estilo Heroku da Supabase, com confiabilidade, HA, monitoramento e escala como preocupações centrais. O tópico também explora filosofias de preço, alternativas como SQLite distribuído e outros provedores de Postgres, além de questões arquiteturais como durabilidade do armazenamento, controles de saída de rede e quanto de lógica de negócio empurrar para o Postgres via ferramentas como PostgREST e row-level security.

Parceria e Oferta

  • A Supabase vai operar um serviço de Postgres gerenciado na infraestrutura da Fly.io, de forma semelhante à parceria existente da Fly com Redis.
  • O Postgres existente da Fly é “automatizado, mas não gerenciado”; a nova opção é explicitamente gerenciada, com a Supabase cuidando de monitoramento, saúde e operações.
  • Recursos de alta disponibilidade estão em teste; o timing e o conjunto exato de funcionalidades não estão totalmente especificados.

Postgres Gerenciado vs. Não Gerenciado

  • Gerenciado: mais próximo da experiência estilo Heroku. Você recebe uma string de conexão; o provedor cuida de escala, verificações de saúde, failover e resposta de plantão.
  • O Fly Postgres de hoje: fornece ferramentas de orquestração e clusterização, mas espera-se que os usuários monitorem, dimensionem e corrijam falhas por conta própria.
  • Vários comentaristas dizem: para dados centrais de produção, escolheriam a nova oferta gerenciada; o próprio Postgres da Fly é mais adequado para projetos paralelos, experimentos ou serviços de menor risco.

Confiabilidade, SLA e Modelo de Armazenamento

  • Surgem preocupações sobre o histórico de uptime da Fly e a postura de suporte “faça você mesmo”; outros dizem que a confiabilidade melhorou, especialmente após a migração para Machines.
  • Um pedido por um SLA formal fica sem პასუხ resposta no tópico.
  • Os volumes da Fly são NVMe local ao host, não SAN/armazenamento em rede; durabilidade e replicação precisam ser tratadas na camada da aplicação/banco de dados.
  • A Fly faz backups periódicos dos volumes e pode migrá-los internamente entre hosts, mas os volumes ainda são tratados como não equivalentes a S3 e não inerentemente “seguros”.

Tratamento de Conexões e Rede

  • A configuração da Supabase na Fly usará o próprio pooler de conexão Postgres da Supabase e o PostgREST, em vez do HAProxy da Fly.
  • Problemas anteriores com timeouts do HAProxy no Fly Postgres motivaram o interesse nisso.
  • Ter a Supabase dentro da rede da Fly evita problemas com IPs de saída instáveis e com allowlisting de IP entre apps da Fly e bancos externos.

Preço e Escopo

  • A indicação inicial é que o preço seguirá os planos atuais da Supabase, possivelmente com ajustes mais amigáveis para desenvolvedores após os testes.
  • Permanecem dúvidas sobre especificações exatas de recursos (CPU/RAM), preço de banco gerenciado independente e cobrança de banda interna; as respostas são incompletas ou pouco claras.

Plataforma Supabase e Escala

  • A Supabase é “apenas Postgres” (atualmente na AWS) com características de escala semelhantes às do RDS e alguns grandes usuários em produção citados.
  • Replicação lógica é suportada e destacada como diferencial em relação a alguns outros provedores de Postgres gerenciado.
  • Alguns consideram frustrantes os preços em camadas e as restrições de rede da Supabase; outros valorizam seu ecossistema Postgres, DX e add-ons.

APIs, Lógica de Negócio e RLS

  • A Supabase expõe:
    • Acesso direto ao Postgres.
    • REST gerado automaticamente (PostgREST).
    • Funções edge/serverless.
  • Vários comentaristas alertam que o uso complexo com PostgREST tende a empurrar a lógica de negócio para procedimentos armazenados (PL/pgSQL ou extensões JS), o que pode ser desajeitado e difícil de depurar.
  • O Row-Level Security é elogiado por sua expressividade, mas criticado por:
    • Problemas de desempenho em consultas complexas/agregadas.
    • Depuração e testes difíceis, especialmente quando as políticas envolvem joins.
  • Orientação: serve para casos simples; ACLs complexas exigem bastante experiência em SQL/PL/pgSQL e ajuste cuidadoso de desempenho.

Alternativas e Contexto Mais Amplo

  • Alguns argumentam que novos projetos poderiam considerar SQLite distribuído (por exemplo, Turso) ou stacks estilo Cloudflare de “edge + banco distribuído” em vez de Postgres.
  • Contra-argumentos:
    • Postgres tem recursos mais ricos (por exemplo, extensões como ltree, replicação lógica, ferramentas de busca).
    • O Cloudflare Workers não tem um equivalente nativo ao Postgres; D1 e opções semelhantes têm seus próprios trade-offs e questões de maturidade.
  • Outros ecossistemas mencionados: Crunchy Bridge, Neon, k3s + cloudnativepg, Tembo, ParadeDB; o tópico observa que a maioria das ofertas concorrentes de Postgres gerenciado historicamente não expunha WAL/replicação lógica, embora a Neon tenha adicionado CDC recentemente.