HeliosProxy · PGConf.Brasil 2026

Posicionamento

A família HeliosDB

Um motor, muitas formas — do embarcado ao gerenciado.

Nanoembarcado · 32 MB · multi-modelo▲ PH · 15 set

Any2HeliosDBmigração de dados legados

MCPgateway para agentes de IA

HeliosDB-Lite

HeliosProxyfrontend · roteador PG-wire▲ PH · 9 set

HeliosCorebackend · o motor

HeliosDB-Full distribuído · enterprise · multi-região · 14 protocolos de fio (PG, Oracle, MySQL, Redis, Mongo…)

HeliosDB Cloud gerenciado · DBaaS (banco sob demanda, backups) + BaaS (auth, APIs, funções)

Visão geral

O que o HeliosProxy prova ao vivo

O cliente não muda nada. Quatro diferenciais, cada um vs o concorrente real.

Transaction ReplayA sessão sobrevive à queda do primary: re-home + estado restaurado; leituras re-executadas só quando toda função chamada é comprovadamente sem efeitos colaterais; transação não confirmada re-aplicada (opt-in). COMMIT incerto nunca é repetido.

Shadow executionA mesma query em dois backends, com diff.

Anomalias no fioSQL injection detectado no proxy — sem tocar na aplicação.

Pooling de verdadeThroughput sob carga, medido contra o PgBouncer.

A superfície completa

17 capacidades. Você prova 4 ao vivo.

Uma camada PG-wire, sem extensão no banco — as marcadas DEMO são as de hoje.

Pooling & roteamento

DEMO 4Pooling — sessão / transação / statement
Load balancing — split leitura/escrita
Roteamento lag-aware — read-your-writes
Roteamento por schema / shard-key
Multi-tenancy — DB / schema / linha / branch

Resiliência & continuidade

DEMO 1Transaction Replay — failover em sessão (tr_mode, 1.7.0) + journal /api/replay
Failover automático
Circuit breaker
Mirror — cauda de escrita → Nano

Dados, cache & geografia

Edge / geo — leitura multi-região
Cache de resultados
Branch estilo Git
Migração online — snapshot / cutover

Validação, segurança & gateways

DEMO 2Shadow — diff entre dois backends
DEMO 3Anomalias no fio — SQL injection
Auth SCRAM/LDAP/HBA · rate limit · rewrite
Plugins WASM · gateways GraphQL / HTTP / MCP

Projetadas para escalar

Sharding & ativo-ativo — sem extensão, sem lock-in

Seis capacidades combinam para distribuir um banco Postgres-compatível — transparente, na frente de qualquer backend PG-wire.

Shard-key · roteamento por schema Multi-tenancy · DB/schema/linha Split R/W + réplicas lag-aware Edge · leitura ativo-ativo multi-região Mirror · cauda de escrita Failover + replay

CitusDB & afins

Distribuem dentro de um Postgres: coordenador + workers, SQL distribuído. Poderoso — mas você adota um motor específico e acopla a aplicação a ele.

HeliosProxy + Nano

Distribui no fio: sharding por schema/tenant, leitura ativo-ativo multi-região, failover com replay — sem extensão. E cada nó pode ser um Nano de 32 MB.

A tese

Camada diferente do planejador do Citus. Para rotear, replicar e distribuir bancos Postgres-compatíveis de forma transparente, é a camada mais completa — e, com o Nano, a mais barata de escalar.

DEMO 01

Transaction Replay

O journal guarda cada escrita — e re-aplica quando você pede

Escreva → o backend perde os dados → POST /api/replay re-aplica a janela journalada.

Demo 1 — Transaction Replay em três colunas

Proxy + PostgreSQL

journal → replay → statements_replayed=3. Linhas voltam.

PgBouncer + PostgreSQL

sem journal → nada a re-aplicar → dados perdidos p/ sempre.

Proxy + Nano

mesmo journal+replay no Nano. Funciona nos dois = upgrade drop-in.

honesto

1.7.0: tr_mode faz failover em sessão — conexão viva, re-home no novo primary, SET/GUC restaurados; leituras re-executadas (select) apenas quando toda função chamada é comprovadamente sem efeitos colaterais — built-in do PostgreSQL na allowlist ou nome declarado em tr_read_functions; leitura opaca devolve 08007 e nunca roda duas vezes; transação não confirmada re-aplicada (transaction, opt-in). COMMIT de resultado desconhecido nunca é repetido (08007) — sem double-apply, sem promessa de zero perda em voo.

tr_mode · HeliosProxy 1.7.0 vs a indústria

O espectro de resiliência a falha

tr_mode	O que o proxy faz na perda do backend	Análogo
none	erro PostgreSQL real (57P01) e a conexão fecha	PgBouncer / PG puro
session (padrão)	conexão fica viva: re-home no novo primary + SET/GUC restaurados; a instrução interrompida recebe um erro (57P01 não entregue · 08007 resultado desconhecido); autocommit não entregue é re-executado	Oracle TAF · SESSION
select	+ leituras interrompidas re-executadas de forma transparente — só quando toda função chamada é comprovadamente sem efeitos colaterais (built-in na allowlist ou nome em tr_read_functions); leitura opaca → 08007, nunca roda duas vezes	Oracle TAF · SELECT
transaction (opt-in)	+ re-aplica a transação não confirmada no novo primary e continua; falha no replay → 40001	Oracle Application Continuity

Fronteira honesta: em todos os modos, um COMMIT de resultado desconhecido nunca é repetido (08007) — sem double-apply, sem promessa de zero perda em voo. O replay é verificado: as frames de resposta de cada instrução são digeridas como o cliente as viu e re-conferidas no backend substituto — divergência desfaz o replay e devolve 40001. Transações em SERIALIZABLE ou REPEATABLE READ nunca são re-aplicadas. Exceder o teto de estado de sessão rastreado (tr_max_session_set_statements, 256) recusa o failover com 08006. COPY em andamento → 08006. Backends com senha exigem o proxy como fronteira de auth ([auth] mode = "scram"). Verificado ao vivo: tr-failover-test.sh, 77 checks, 4 modos, PostgreSQL 18.4. A promoção do standby fica com o seu orquestrador HA — ou com a HA nativa do Nano.

DEMO 02

Shadow execution

Migre com evidência, não com fé

POST /api/shadow: a mesma query em dois backends, com diff. Valida upgrade (PG→PG) e migração (PG→Nano).

Demo 2 — Shadow execution em três colunas

Proxy · PG → PG

valida o upgrade: is_clean=true; depois uma linha muda → DRIFT CAUGHT.

PgBouncer · não faz

um pooler fala com um backend só. Nada para comparar.

Proxy · PG → Nano

valida a migração — a prova do Any2Helios — clean, depois drift capturado.

bônus real

Flagrou até a serialização de NUMERIC diferente entre PG e Nano no fio. Captura tudo.

DEMO 03

Anomalias no fio

Veja o ataque antes que vire vazamento

Detector no proxy: o SQL injection aparece em GET /anomalies, com os padrões que casaram.

Demo 3 — Anomalias no fio em três colunas

Proxy + PostgreSQL

sql_injection flagrado: classic_or_payload, union_select, information_schema_probe.

PgBouncer + PostgreSQL

um pooler não lê o SQL. A injeção passa sem ser vista.

Proxy + Nano

mesma guarda — a detecção é no proxy, agnóstica de backend.

takeaway

Você descobre o ataque no /anomalies — não no relatório de incidente.

DEMO 04

Pooling · bônus

Drop-in, e aguenta a carga

pgbench · 8 clientes · mesmo workload. Competitivo — enquanto faz journal, replay e anomalias.

Proxy + PostgreSQL

~30k tps

PgBouncer + PostgreSQL

~26k tps

Proxy + Nano

~28k tps

honesto

Gravados back-to-back no mesmo host. O ponto: pooling de verdade sem abrir mão dos outros três recursos.

Encerramento

Dois lançamentos. Salve as datas.

Escaneie: lembrete no calendário + link do Product Hunt. Apoie e compartilhe nas primeiras horas 🙏

1º HeliosProxy

09 SET · 0h PT / 9h CEST

▲ Product Hunt

HeliosDB-Nano

15 SET · 0h PT / 9h CEST

▲ Product Hunt

Daniel Moya

Inventx AG · GPC

danimoya.com

Apache-2.0 · crates.io/crates/heliosdb-proxy · crates.io/crates/heliosdb-nano