Awide Polar separa compute e storage no PostgreSQL e mira HTAP sem ETL

Um fork de um fork, com código aberto

A Awide Labs publicou em 19 de outubro de 2026 o código-fonte do Awide Polar, projeto que parte do PolarDB para PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → (o fork que a Alibaba mantém há anos) e aplica mudanças próprias em cima da base do PostgreSQL 17. Junto com o motor, a empresa abriu também o PolarFS, a camada de armazenamento compartilhado, e o Polar Proxy, um proxy baseado em ProxySQL para roteamento consciente de consistência entre réplicas.

Para quem arquiteta sistemas, o ponto central não é o anúncio em si, mas a arquitetura por trás dele: separação de compute e storage dentro do PostgreSQL, sem reescrever a aplicação. Isso ataca um problema concreto de quem já tentou escalar leitura em Postgres vanilla, onde cada réplica física carrega uma cópia completa dos dados e o custo de armazenamento cresce junto com o de computação, mesmo quando só se precisa de mais capacidade de leitura.

Como funciona a separação de storage

No desenho do Awide Polar, um primário concentra as escritas e réplicas de leitura acessam os mesmos arquivos de dados através do PolarFS, o sistema de arquivos compartilhado. Adicionar uma réplica não significa manter outra cópia inteira do banco: a réplica aponta para o mesmo storage e só precisa de capacidade de processamento.

Isso muda o cálculo de capacidade de quem opera o banco em produção. Hoje, no PostgreSQL com replicação física tradicional, dobrar a capacidade de leitura custa o dobro de disco. Na arquitetura do Awide Polar, compute e storage escalam em eixos separados, sem sharding de aplicação.

O modelo continua sendo single-writer: um único primário aceita escritas, e as réplicas servem leitura e trabalho analítico. O trabalho de performance anunciado pela Awide Labs mira justamente o caminho de commit desse escritor único, não a escrita distribuída entre múltiplos nós.

O que mudou no motor e no storage

A Awide Labs descreve três frentes de engenharia na publicação original, cada uma endereçando um ponto diferente de contenção:

• Motor de banco: WAL pipelining e MVCC baseado em CSN, portados do PolarDB 11 para a base PostgreSQL 17, com workers dedicados de escrita e flush do WAL e maior particionamento de locks em inserção de WAL, mapeamento de buffers, listas de flush e LogIndex.
• PolarFS: troca de comunicação por polling por filas lock-free e futex wake-ups, buffers compartilhados registrados para I/O zero-copy entre o PostgreSQL e o daemon de storage, além de caches fragmentados e locking mais fino.
• Polar Proxy: roteamento consciente de LSN sobre o ProxySQL, com suporte a prepared statements e ao protocolo estendido de consulta.

Nos testes de pgbench com carga mista de leitura e escrita, a Awide Labs reporta mais de 150.000 transações por segundo. Em testes de fio com 512 clientes, o PolarFS teria entregado cerca de 7 vezes o IOPS de escrita aleatória e 11 vezes o IOPS de leitura aleatória da versão original do PolarFS.

Vale a ressalva que a própria Awide Labs faz: são dois benchmarks distintos, com objetivos diferentes, e nenhum dos dois vem acompanhado de especificação de hardware, tamanho de dataset ou configuração de conexões. Para um DBA avaliando a tecnologia, isso é ponto de partida para reproduzir o teste no próprio ambiente antes de decidir qualquer coisa, não número para colocar em capacity planning.

Consistência de leitura em réplicas: o papel do proxy

Storage compartilhado resolve duplicação de dados, mas abre outro problema clássico de replicação: uma réplica pode responder com dado desatualizado em relação ao que o cliente acabou de escrever no primário. É aqui que entra o Polar Proxy, com dois modos de operação.

No modo de sessão, o proxy garante que um cliente leia suas próprias escritas confirmadas mesmo quando a leitura cai numa réplica. No modo global, qualquer leitura em réplica espera pelo LSN mais recente observado pelo proxy entre todas as sessões, trocando um pouco de latência por uma garantia mais forte de consistência entre clientes diferentes.

A própria Awide Labs é explícita sobre o limite dessa garantia:

Esse modo global do proxy é diferente de snapshots de transação coordenados globalmente, que seguem como trabalho planejado para o futuro.

This proxy-level global mode is distinct from globally coordinated transaction snapshots, which remain planned work.Vadim Iatsenko, Awide Labs

Ou seja: o proxy resolve consistência de leitura em réplica individual, mas não entrega snapshot isolation coordenado entre múltiplas transações em todo o cluster. Para quem desenha sistemas que dependem de isolamento forte entre transações concorrentes em réplicas diferentes, essa distinção decide se a arquitetura serve hoje ou só depois que esse trabalho planejado sair do papel.

HTAP sem pipeline de ETL

A segunda frente do projeto é HTAP: o motor de consulta paralela elástica do Polar distribui trabalho analítico entre workers de réplicas que acessam o mesmo dado orientado a linha usado pelas transações. Na prática, isso evita manter um pipeline de ETL separado só para alimentar um banco analítico com os mesmos dados que já estão no transacional.

O recurso já estava portado para o Awide Polar 15; a portabilidade para a versão 17, que é a base do restante do projeto, segue em andamento segundo a Awide Labs. Importa notar que, mesmo com compute de análise isolado em réplicas, o storage continua compartilhado: uma consulta analítica pesada ainda compete por I/O com o tráfego transacional no mesmo PolarFS, só não compete por CPU no mesmo nó.

Alta disponibilidade e o que a lista de correções revela

A Awide Labs estendeu o Patroni para entender a topologia de storage compartilhado do PolarDB e portou o DataMax, um relay somente de WAL, para o Awide Polar 17. Um DataMax próximo recebe WAL de forma síncrona e repassa de forma assíncrona para um standby remoto, tirando a latência de replicação remota do caminho de commit do primário. A promoção de um standby é guardada: ele busca o WAL restante antes de assumir, mas a recuperação sem perda de dados depende de esse WAL reconhecido continuar disponível, inclusive no próprio DataMax.

A publicação também lista correções de leituras obsoletas em réplica, problemas de visibilidade e snapshot ligados ao CSN, falhas de promoção e tratamento de erro de fsync no WAL, além de um lease de leitura e escrita entre hosts no PolarFS para proteger contra escritores concorrentes. Para um DBA, essa lista não é motivo de alarme: é sinal de que a Awide Labs testou cenários de falha reais antes de abrir o código. Mas também é lembrete de que se trata de um fork jovem, aberto há poucas horas, sem o histórico de produção que o PostgreSQL vanilla ou o PolarDB original já acumularam.

Quando faz sentido considerar

A arquitetura do Awide Polar atende bem um cenário específico: aplicações com leitura muito maior que escrita, que hoje pagam o custo de duplicar dados a cada réplica, ou times que querem rodar análise sobre dados operacionais sem manter um pipeline de ETL para um data warehouse separado.

Ela não resolve, pelo menos nesta versão, escrita distribuída entre múltiplos nós, já que o modelo continua single-writer. Times que precisam de escrita horizontal, de compatibilidade garantida com todo o ecossistema de extensões do PostgreSQL ou de um histórico de produção extenso antes de confiar dados críticos a um motor devem tratar o Awide Polar, por ora, como projeto para avaliar em ambiente controlado, não como substituto imediato de uma instalação PostgreSQL estabelecida. O código está nos repositórios da organização Awide Labs no GitHub, e a empresa promete posts técnicos mais detalhados sobre motor, storage e proxy nas próximas semanas.

Fonte: Planet PostgreSQL