Fly Postgres gerenciado pela Supabase
(supabase.com)- A colaboração de Postgres gerenciado entre Supabase e Fly.io foi uma tentativa de levar os recursos de banco de dados da Supabase para a infraestrutura da Fly, mas atualmente foi descontinuada
- O serviço tinha como objetivo implantar Postgres em um ambiente de edge computing executado em mais de 37 localidades da Fly.io, aproximando aplicações Fly e banco de dados
- O escopo de recursos incluía mais de 40 extensões, pgvector, Supavisor, backups diários, recuperação para um ponto no tempo, branching, observabilidade, migrações, dashboard e APIs geradas automaticamente de REST e GraphQL
- A implantação inicial aconteceria de forma gradual, e ainda restavam tarefas de integração entre as empresas como cobrança, transição de suporte, treinamento interno e correção de bugs encontrados por testadores iniciais
- Enquanto o Postgres existente da Fly era não gerenciado, com responsabilidade operacional do usuário, o Fly Postgres era um serviço gerenciado em que a Supabase cuidava de escalabilidade, backups, replicação e upgrades
Status de lançamento e escopo do serviço
- O Fly Postgres está atualmente descontinuado; mais detalhes podem ser vistos no aviso de descontinuação
- A Supabase e a Fly.io lançaram o Fly Postgres como um serviço de Postgres gerenciado executado na infraestrutura da Fly
- O banco de dados era executado na plataforma de edge computing da Fly.io, e era possível começar escolhendo entre mais de 37 localidades da Fly.io
- Aplicações intensivas em dados implantadas na Fly poderiam esperar menor latência ao manter o banco de dados na mesma infraestrutura
Recursos do Postgres gerenciado pela Supabase
- O Fly Postgres oferecia no ambiente Fly os principais recursos esperados de um banco de dados gerenciado pela Supabase
- Mais de 40 extensões do Supabase Postgres
- Suporte a workloads de Vector/AI com base em pgvector
- Supavisor, o pooler de conexões Postgres da Supabase
- Backups diários e recuperação para um ponto no tempo
- Branching, observabilidade e migrações
- Dashboard para administração do banco de dados
- Data API gerada automaticamente
- API REST usando PostgREST
- API GraphQL usando pg_graphql
Rollout gradual e testes iniciais
- O lançamento aconteceria em rollout gradual
- A integração entre as empresas incluía tarefas como cobrança, transição de suporte e treinamento da equipe da Supabase
- O serviço estava sendo validado com alguns testadores iniciais, e ainda havia bugs a corrigir
- Quem quisesse participar dos testes podia se registrar na waitlist
- Havia plano de aceitar mais testadores no mês seguinte e compartilhar um cronograma adicional de lançamento depois de garantir a segurança dos dados
Diferença entre Postgres gerenciado e não gerenciado
- A oferta existente de Postgres da Fly era não gerenciada
- O usuário precisava lidar diretamente com escalabilidade, backups point-in-time, replicação e upgrades de versões principais
- No Postgres gerenciado da Fly operado pela Supabase, o usuário podia focar mais na construção da aplicação
- O serviço gerenciado foi criado com a Fly extension API
- A mesma API também é usada no Fly Redis
- Os testadores podiam criar um banco de dados Postgres com o comando
fly extensionsfly extensions supabase create
- Quando o serviço estivesse estabilizado, a intenção era trocar para o namespace
postgresfly postgres create
Implementação baseada em Fly Machines
- O Fly Postgres foi construído sobre Fly machines
- Machines são VMs Firecracker leves, e a Machines API permite controle detalhado do ciclo de vida da aplicação
- Machines podem ser interrompidas quando ficam inativas e retomadas em poucos segundos quando chega uma nova requisição
- Para simplificar a interação com a API da Fly, a Supabase criou um wrapper em TypeScript chamado fly-admin
- Como a Supabase empacota alguns serviços adicionais junto com o Postgres, ela preparou uma única imagem Docker que pode ser enviada para a Fly Machines API
- O processo de build existente criava uma AMI para AWS com Packer, e parte desse pipeline foi reutilizada para construir a All In One Image
- A All In One Image inclui, dentro de um único contêiner Docker, todos os serviços necessários para executar um projeto Supabase
Transição para multicloud
- Com esse lançamento, a Supabase se tornaria oficialmente multicloud
- A Supabase evitou intencionalmente serviços gerenciados da AWS para simplificar a transição para multicloud
- Como os primitivos básicos variam muito entre provedores de nuvem, a mudança não é simples
- Fly Machines oferece uma forma de suspender VMs não utilizadas e retomá-las de forma transparente em poucos segundos
- Isso simplifica o processo de pausar bancos de dados inativos
- A AWS não tem um primitivo direto para alcançar isso
- Em contrapartida, a Fly não oferece alguns primitivos que a AWS fornece, exigindo soluções alternativas
- Fly Machines não tem armazenamento de rede conectado
- A Supabase tratava os dados dos volumes da Fly como dados temporários
- Para todos os projetos executados na Fly, eram feitos backups físicos com WAL-G
- As alterações no banco de dados eram continuamente transmitidas para o S3
- Se houvesse dano no host ou no volume, o projeto seria restaurado em um novo host da Fly usando os dados mais recentes do S3
Observabilidade operacional e publicação de imagens
- Na AWS, eventos do AWS Health events eram recebidos para detectar problemas de host
- Na Fly, logs de Machine eram enviados para o Logflare por meio do fly-log-shipper
- A Supabase publicava a All In One Image não apenas no registro de contêineres da AWS, mas também no registro Docker da Fly
- Publicar no registro Docker da Fly melhorava confiabilidade e desempenho ao iniciar projetos na Fly
Extensões da Fly e integração de autenticação
- A Fly oferece a Extensions API para expansões da plataforma
- A Supabase adicionou algumas rotas à API para provisionar usuários e projetos
- Usuários da Fly podiam acessar o dashboard da Supabase com suas credenciais da Fly existentes
- A API da Supabase iniciava um fluxo OAuth com a Fly para autenticar usuários
- A equipe do Supabase Auth criou o provedor OAuth da Fly para facilitar a integração da API
Desafios restantes
- A Supabase continuava trabalhando com a equipe da Fly em alguns desafios operacionais
-
Suporte a restrições de rede
- O recurso de restrição de rede exige que o contêiner receba o IP correto do cliente conectado
- Na configuração atual, o contêiner via o IP do proxy da Fly em vez do IP do cliente
- As conexões passavam pelo proxy da Fly, que expõe o Proxy protocol
- O Postgres não consegue usar essa informação diretamente, e a Supabase estudava uma forma de tornar o Supavisor compatível com proxy-protocol
-
Backups dentro da Fly
- Como a Fly ainda não oferece armazenamento Blob gerenciado, os backups de projetos na Fly eram feitos em AWS S3
- Esse método gerava custos de banda entre nuvens
- A Fly estava trabalhando em Blob Storage
Como começar e preços
- Era possível solicitar acesso ao preview no formulário de preview
- Quando a organização fosse adicionada à allowlist, seria possível começar pelo Quickstart da documentação
- Organizações da Fly receberiam 1 projeto gratuito
- Os detalhes de cobrança ainda estavam em elaboração, mas o preço não deveria mudar muito em relação aos preços atuais da Supabase
1 comentários
Opiniões no Hacker News
Sou o CEO da Supabase. O Postgres atual da Fly é não gerenciado, então estamos trabalhando com a Fly para operar um serviço gerenciado
É o mesmo modelo que temos com a equipe da Upstash no Fly Redis: https://fly.io/docs/reference/redis/
Ainda estamos lançando recursos de alta disponibilidade com testadores e não há uma data definida, mas vamos avançar com a equipe da Fly o mais rápido possível
Não lembro de muitos casos em que uma empresa externa entra para colaborar gerenciando uma versão hospedada de um serviço não hospedado de outra empresa
Dei uma olhada no Supabase há um tempo e fiquei confuso sobre como criar uma API REST básica
Parece bom que, ao criar tabelas, ele gere automaticamente uma API para interagir com elas, mas aí eu não sabia onde colocar a lógica de negócio
Também vi Edge Functions, mas os exemplos pareciam mais voltados a processamento de tarefas, então não ficou claro se era para usar para isso; fiquei com a sensação de que estava deixando passar algo simples
A API REST é bem conveniente para agregação de dados, como joins, mas assim que você precisa de algo como transações, começa a travar
A segurança em nível de linha (RLS) para controle de acesso baseado em papéis também foi trabalhosa, e a experiência de desenvolvimento deixou a desejar
Se os requisitos do banco de dados forem simples, a API REST é muito conveniente, mas, se você planeja algo complexo, é melhor aprender PL/pgSQL ou usar uma conexão comum com o banco
Para a maioria, a opção 1 é suficiente, e as opções 2 e 3 são mais ferramentas extras para usar quando necessário
Em muitos casos de uso, a lógica pode ficar em stored procedures SQL, e o PostgreSQL também permite stored procedures em JS ou Python
No entanto, para código de lógica, a experiência de desenvolvimento costuma ser melhor ao implantá-lo como contêineres ou funções em um CI/CD comum, e ambos são bastante usados dependendo do compromisso de custo
A Supabase recomenda funções serverless em Deno, mas, para projetos web, acho que a maioria preferiria implantar funções Node na Cloudflare
No fim, o público-alvo parece ser quem quer manter 99% da lógica no frontend em JS, deixando o backend cuidar apenas de CRUD e autenticação
Para essa parte, criamos um sistema de eventos baseado no WAL do Postgres e o tratamos como um sistema de callbacks
Também criamos uma pequena biblioteca para Elixir que começou como um fork do Supabase Realtime: https://github.com/cpursley/walex
Recentemente, adicionamos a capacidade de configurar o WalEx para entregar eventos por webhook ou EventRelay, sem precisar conhecer Elixir
Como usamos Next.js, muitas das chamadas ao banco estão dentro de funções serverless do Next
Ainda assim, pretendo avaliar mover parte da lógica para funções da Supabase para mantê-la o mais perto possível do banco, mas ainda não quis migrar para Deno
Ao acessar a Supabase pelo servidor, você pode usar os recursos do PostgREST usados pelo cliente Supabase ou acessar o Postgres diretamente com uma biblioteca comum como
pgEstou ansioso para migrar para isso. Ao criar o Booklet sobre Fly.io e Fly Postgres, estruturamos o app de forma distribuída: https://www.contraption.co/essays/booklet-architecture/
O maior problema foi a configuração do Fly Postgres. Em especial, a Fly coloca um HAProxy na frente do Postgres e impõe um limite de conexão de 30 minutos, derrubando conexões continuamente: https://community.fly.io/t/postgresql-connection-issues-have...
Deveria ser um problema gerenciável, mas o comportamento de encerramento de conexões não bate com a documentação, de um jeito estranho, então continua instável
Fico curioso se o novo Postgres também terá o mesmo HAProxy na frente
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
Vi isso hoje na documentação da Fly e pensei que talvez tivesse perdido no HN, mas era algo recém-lançado
Meu segundo pensamento foi que é estranho ter Postgres by Fly e Postgres by Supabase juntos na barra lateral
Também não há uma comparação evidente, então, se eu implantar um app na Fly e precisar de Postgres, fica confuso saber o que devo usar
Pessoalmente, se eu precisasse de um DBMS na Fly, acho que usaria o SQLite distribuído do LiteFS; se precisasse de Postgres, vejo a diferença entre Fly e Supabase, na prática, como não gerenciado versus gerenciado
Muito bom. Eu não gostava muito da configuração de restrições de rede do Supabase: https://supabase.com/docs/guides/platform/network-restrictio...
Pelo que lembro, quando vi isso antes havia algum problema estranho em expor o IP do app da Fly ao Supabase e travar o Supabase nesse IP
O fato de o Supabase realmente entrar dentro da rede da Fly é excelente
Isso também está na documentação de rede da Fly.io
Ouvi dizer que o Supabase tem problemas de escalabilidade quando passa da fase de protótipo, e queria saber se alguém com experiência em produção pode comentar
De que problemas específicos você está falando?
Aqui é o Joshua, da Fly.io. Se tiverem perguntas sobre essa integração, eu respondo
Uso em alguns side projects, mas ainda não em projetos grandes
O próximo item que eu gostaria é armazenamento de Blob; como, por padrão, prefiro usar serviços gerenciados para coisas com estado, fico feliz em saber que isso também está em andamento
Fiquei curioso se há detalhes sobre os preços da nova oferta de Postgres
Atualmente rodamos um DB grande na Fly e estamos procurando PostgreSQL gerenciado, então essa notícia é muito bem-vinda
Somos uma equipe totalmente de Elixir, então o timing não poderia ser melhor
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
Nunca usei AWS e também não conheço bem armazenamento conectado à rede, então queria entender exatamente como os volumes da Fly diferem do armazenamento conectado à rede de outros provedores
Acho que, ao criar um volume da Fly, era possível movê-lo para outro servidor na mesma região; então, tecnicamente, isso não seria armazenamento conectado à rede?
Internamente, conseguimos mover um volume de um host físico para outro; o modo como fazemos isso é bem interessante, mas ainda não expusemos muito publicamente
Pretendemos tornar isso mais visível este ano
Os Fly Volumes são regularmente copiados para armazenamento em bloco fora da rede, e em breve teremos mais anúncios relacionados a isso
O ponto básico a entender é que Fly Volumes não são armazenamento SAN, nem um armazenamento inerentemente confiável como S3
Dentro das Fly Machines, eles aparecem como um simples sistema de arquivos ext4, e, se você precisa de confiabilidade, durabilidade e replicação, isso deve ser fornecido na camada da aplicação
O Fly Postgres funciona como um cluster de réplicas de leitura, e qualquer réplica pode assumir o papel de líder de escrita quando necessário; por isso esse modelo faz sentido
É também por isso que mostramos um grande alerta vermelho no console quando alguém tenta criar um cluster Postgres de nó único
Acho que, nos próximos trimestres, vamos oferecer novas opções ao longo do espectro de confiabilidade e desempenho, mas provavelmente não na forma de operar diretamente drives SAN que apenas expõem dispositivos de bloco via algo como iSCSI
Eu realmente detesto o modelo de preços dessas duas empresas
Em uma ponta está o Supabase, com um produto em camadas no estilo plataforma de desenvolvedor como a Vercel, estruturado para fazer você pagar mais do que seu uso real
Na outra ponta está a Fly, com preços excessivamente granularizados por segundo, por memória e por CPU, como Lambda, em que você provavelmente vai pagar pouco demais e sofrer degradação de desempenho
Com algo como Cloudflare Workers, não entendo bem por que escolher um dos dois. Por que alguém ainda quer se preocupar com escala?
Também parece improvável que a Cloudflare ofereça Postgres de verdade. A filosofia da Cloudflare é que tudo que você publica seja distribuído globalmente, enquanto bancos de dados relacionais forçam um único servidor como fonte da verdade
Claro, eu ficaria feliz se provassem que estou errado
Os preços mensais da Fly são bem diretos e não se parecem em nada com Lambda. Na verdade, entre os dois, o modelo de preços do Cloudflare Workers é o mais parecido com Lambda