Supabase ETL: Pipelines de Dados em Tempo Real do PostgreSQL para Analytics
O Supabase lançou o Supabase ETL, um pipeline CDC que replica tabelas PostgreSQL para destinos analíticos em tempo quase real. Entenda como funciona, quando usar e os preços dessa nova ferramenta open source.
Se você trabalha com dados, provavelmente já enfrentou o dilema clássico: seu banco PostgreSQL de produção está ficando lento porque relatórios analíticos pesados competem com queries transacionais. A solução tradicional envolve montar pipelines complexas com Debezium, Kafka, Airbyte ou scripts de exportação agendados via cron.
O Supabase anunciou ontem (02 de dezembro de 2025) uma alternativa elegante: o Supabase ETL, um pipeline de captura de dados de alteração (CDC) que replica suas tabelas do PostgreSQL para destinos analíticos em tempo quase real.
O diferencial? A configuração leva apenas alguns minutos diretamente no painel do Supabase. Sem código, sem infraestrutura complexa.
Os primeiros destinos suportados são Analytics Buckets (com tecnologia Apache Iceberg) e BigQuery. E como tudo no ecossistema Supabase, o projeto é open source, disponível em github.com/supabase/etl.
Por que Separar OLTP e OLAP?
O PostgreSQL é excelente para cargas de trabalho transacionais: ler o registro de um único usuário, inserir um pedido, atualizar um perfil. Mas quando você precisa analisar milhões de linhas para fins analíticos, o PostgreSQL começa a sofrer.
Sistemas orientados a colunas, como o BigQuery, ou aqueles construídos em formatos abertos como o Apache Iceberg, são projetados exatamente para isso. Eles conseguem agregar conjuntos de dados massivos ordens de magnitude mais rápido, compactar dados com mais eficiência e lidar com consultas analíticas complexas que sobrecarregariam um banco transacional.
O Supabase ETL oferece o melhor dos dois mundos: mantenha seu aplicativo rápido no PostgreSQL enquanto desbloqueia análises poderosas em sistemas desenvolvidos especificamente para essa finalidade.
Como Funciona o Supabase ETL
O pipeline captura todas as alterações no seu banco PostgreSQL e as entrega ao destino de análise em tempo quase real. O fluxo opera da seguinte forma:
1. Publicação: Você cria uma publicação do PostgreSQL que define quais tabelas devem ser replicadas.
2. Conexão: O ETL conecta a publicação a um destino analítico configurado.
3. Captura: O processo ETL lê as alterações da publicação por meio de um slot de replicação lógica, capturando INSERT, UPDATE, DELETE e TRUNCATE.
4. Batching: As alterações são agrupadas em lotes para otimizar a escrita no destino.
5. Entrega: Seus dados ficam disponíveis para consulta no destino analítico.
O pipeline começa com uma cópia inicial das tabelas selecionadas e, em seguida, alterna para o modo de streaming. Suas análises permanecem atualizadas com latência medida em milissegundos a segundos.
Configuração via Painel do Supabase
Uma das grandes vantagens do Supabase ETL é a facilidade de setup. A configuração é feita inteiramente pelo Painel de Controle do Supabase, sem necessidade de código.
Passo 1: Criar uma Publicação
Uma publicação define quais tabelas serão replicadas. Você pode criá-la com SQL ou através da interface:
-- Replicar tabelas específicas
CREATE PUBLICATION analytics_pub
FOR TABLE events, orders, users;
-- Ou replicar todas as tabelas de um schema
CREATE PUBLICATION analytics_pub
FOR TABLES IN SCHEMA public;
Passo 2: Habilitar Replicação
Navegue até Database no Painel de Controle do Supabase. Selecione a aba Replication e clique em Enable Replication.
Passo 3: Adicionar um Destino
Clique em Add Destination e escolha o tipo de destino (Analytics Buckets ou BigQuery). Configure as credenciais e selecione a publicação. Clique em Create e depois Start para iniciar a replicação.
Passo 4: Monitorar o Pipeline
O painel exibe o status e o atraso (lag) do pipeline. Você pode iniciar, parar, reiniciar ou excluir pipelines no menu de ações.
Destinos Disponíveis
O objetivo do Supabase ETL é permitir que você conecte seus sistemas de dados existentes ao Supabase. A lista de destinos está em expansão ativa.
Analytics Buckets (Apache Iceberg)
Os Analytics Buckets são buckets de armazenamento especializados construídos sobre o Apache Iceberg, um formato de tabela aberto projetado para grandes conjuntos de dados analíticos. Os dados são armazenados em arquivos Parquet no S3.
Ao replicar para Analytics Buckets, suas tabelas são criadas com uma estrutura de changelog. Cada linha inclui uma coluna cdc_operation indicando se a alteração foi um INSERT, UPDATE ou DELETE. Esse formato append-only preserva o histórico completo de todas as alterações.
Você pode consultar os Analytics Buckets a partir de PyIceberg, Apache Spark, DuckDB, Amazon Athena ou qualquer ferramenta que suporte a API REST Catalog do Iceberg.
BigQuery
O BigQuery é o data warehouse serverless do Google, desenvolvido para análises em larga escala. Ele lida com petabytes de dados e se integra bem com ferramentas de BI e pipelines existentes.
Ao replicar para o BigQuery, o Supabase ETL cria uma view para cada tabela e usa uma tabela versionada subjacente para suportar todas as operações de forma eficiente. Você consulta a view e o ETL cuida do resto.
Gerenciando Tabelas no Pipeline
Você pode modificar quais tabelas serão replicadas após o pipeline estar em execução.
Adicionar uma tabela:
ALTER PUBLICATION analytics_pub ADD TABLE products;
Remover uma tabela:
ALTER PUBLICATION analytics_pub DROP TABLE orders;
Após alterar sua publicação, reinicie o pipeline no menu de Ações do Painel para que as alterações entrem em vigor.
Importante: O ETL não remove dados do destino quando você remove uma tabela da publicação. Isso é intencional para evitar perda acidental de dados.
ETL vs Read Replicas: Quando Usar Cada Um?
Read Replicas e ETL resolvem problemas diferentes:
Read Replicas ajudam quando você precisa escalar consultas simultâneas, mas ainda são PostgreSQL. Elas não tornam análises mais rápidas, apenas distribuem a carga de leitura.
ETL move seus dados para sistemas desenvolvidos especificamente para análise. Você obtém:
- Consultas mais rápidas em grandes conjuntos de dados
- Custos de armazenamento reduzidos através de compressão eficiente
- Separação completa entre workload de produção e análise
Você pode usar ambos: Read Replicas para escalar leituras do aplicativo e ETL para analytics.
Limitações Atuais
A replicação com o Supabase ETL apresenta algumas limitações que devem ser consideradas:
- Tabelas devem ter chaves primárias (requisito da replicação lógica do PostgreSQL)
- Colunas geradas (generated columns) não são suportadas
- Tipos de dados customizados são replicados como strings
- Alterações de schema não são propagadas automaticamente para os destinos
- Dados são replicados como estão, sem transformação
- Durante a cópia inicial, as alterações se acumulam no WAL e são reproduzidas quando o streaming começa
A equipe do Supabase está trabalhando no suporte a alterações de schema, destinos adicionais e diferentes técnicas de streaming para melhorar flexibilidade e performance.
Preços
O Supabase ETL é baseado em uso:
| Item | Valor |
|---|---|
| Conector | US$ 25/mês |
| Dados processados (após sync inicial) | US$ 15/GB |
| Cópia inicial | Gratuita |
Como Começar
O Supabase ETL está atualmente em alpha privado. Para solicitar acesso, entre em contato com seu gerente de contas do Supabase ou preencha o formulário disponível no Painel de Controle.
Se você quiser explorar o código, o framework ETL é open source e escrito em Rust. Confira o repositório em github.com/supabase/etl.
Quando Usar o Supabase ETL
Considere adotar o Supabase ETL nos seguintes cenários:
Separação de workloads OLTP/OLAP: Seu banco de produção está sendo impactado por queries analíticas. Você precisa de um data warehouse dedicado sem sacrificar a freshness dos dados.
Replicação near real-time: Dashboards e métricas precisam refletir mudanças em segundos, não horas. ETLs batch não atendem os requisitos de latência.
Ecossistema Supabase: Você já utiliza Supabase como backend e quer uma integração nativa, evitando dependências externas.
Analytics Buckets ou BigQuery na stack: Esses destinos já estão suportados nativamente.
Histórico completo de alterações: O formato changelog dos Analytics Buckets preserva todo o histórico de mudanças, ideal para auditoria e análises temporais.
Quando NÃO Usar o Supabase ETL
Evite o Supabase ETL em situações onde ele adiciona complexidade desnecessária:
Projetos de pequena escala: Se o PostgreSQL de produção suporta suas queries analíticas sem degradação perceptível, a separação de ambientes é prematura.
Destinos não suportados: Seu ambiente analítico não é BigQuery nem Analytics Buckets, e você não pode esperar pelos novos destinos.
Necessidade de transformação: Você precisa transformar dados durante a replicação. O ETL replica dados como estão.
Tabelas sem chave primária: A replicação lógica do PostgreSQL exige PKs. Será necessário adicionar chaves antes de usar o ETL.
Conclusão
O Supabase ETL chega ao mercado como uma solução elegante para um problema comum: separar workloads transacionais de analíticos sem a complexidade tradicional de pipelines CDC.
Com configuração via painel, suporte nativo a BigQuery e Analytics Buckets (Iceberg), e o código open source em Rust, a ferramenta se posiciona como uma alternativa acessível para equipes que já utilizam o ecossistema Supabase.
Por estar em alpha privado, vale solicitar acesso antecipado se você tem casos de uso que se beneficiariam da replicação em tempo quase real. A evolução do projeto pode ser acompanhada no repositório GitHub.
