HeliosProxy, switchover sem perdas, Transaction Replay e muito além disso.
Daniel Moya
Inventx AG + GPC International Enterprise AG
Um proxy de protocolo PostgreSQL com switchover sem perdas, shadow execute para validar upgrades e detecção de anomalias na borda.
Operadores PostgreSQL hoje montam um quebra-cabeça: pgbouncer ou pgcat para pooling, HAProxy ou Patroni para failover, código da aplicação ou pg_audit para detecção de anomalias, e um cluster de staging separado (mais muita esperança)
para upgrades de major version. Cada peça funciona isolada, mas é nas costuras que moram os incidentes: o script de failover que descarta transações em voo, o upgrade que passa em staging e quebra ORDER BY em produção, o SQL injection que só aparece no log da aplicação seis horas depois.
Esta apresentação introduz o HeliosProxy, um proxy open-source de protocolo PostgreSQL escrito em Rust que consolida essas preocupações num único componente onde seus clientes psql, asyncpg, JDBC e pgx se conectam sem mudar uma linha de código.
A talk é estruturada em três demos ao vivo:
1. Switchover sem perdas com transaction journal. Vamos derrubar o primário no meio de uma workload, ver o HeliosProxy bufferizar os statements em voo, promover um standby, e fazer replay da janela jornalizada num replica defasado via POST /api/replay para que ele alcance o estado atual sem reseed. O cliente vê uma pausa breve, sem erros.
2. Shadow execute para upgrades de major version. Apontamos o proxy para um primário PG14 e um candidato PG16, mandamos cada query para os dois, e diferenciamos os resultados. Vamos provocar uma divergência real — ordenação de NULL, mudança de comportamento de regex, mudança de ordem de linhas induzida pelo planner — e vê-la aparecer em /api/shadow antes de qualquer cliente tocar a versão nova. É a rede de segurança que a maioria dos times constrói à mão e nunca confia totalmente.
3. Detecção de anomalias na borda do fio. Vamos disparar um burst de credential stuffing e uma sondagem clássica de SQLi do tipo UNION contra o proxy, e ver /anomalies sinalizar os dois em segundos, com a sessão ofensora, o padrão casado e o z-score. A detecção acontece no proxy, não no log da aplicação — o que significa que funciona para sistemas legados que não podem ser modificados.
Fechamos com um tour de 60 segundos pelo sistema de plugins WASM: oito plugins first-party (cost-governor, column-mask para PII, residency-router, llm-guardrail para sidecars de IA, pgvector-router, audit-chain, token-budget, ai-classifier) são distribuídos como artefatos OCI assinados e fazem hot-reload sem reiniciar o proxy.
O que a audiência leva para casa:
- Modelo mental claro do que um wire-protocol proxy pode e não pode fazer pelo seu deployment PostgreSQL.
- Receita reproduzível para upgrades PG14→PG16 (ou 15→17) mais seguros usando shadow execute.
- Padrão de switchover que não descarta transações, com endpoint de replay para catch-up de standby defasado.
- Detecção de anomalias na L7 sem tocar no código da aplicação.
- Repositório com 22 demos docker-compose que dão para rodar no laptop na mesma noite.
Nível: intermediário. Útil para DBAs avaliando estratégias de HA, devs cansados de escrever lógica de retry com failover, e platform engineers operando Postgres multi-tenant.
HeliosProxy, switchover sem perdas, Transaction Replay e muito além disso.
Daniel Moya
Inventx AG + GPC International Enterprise AG
Um proxy de protocolo PostgreSQL com switchover sem perdas, shadow execute para validar upgrades e detecção de anomalias na borda.
Operadores PostgreSQL hoje montam um quebra-cabeça: pgbouncer ou pgcat para pooling, HAProxy ou Patroni para failover, código da aplicação ou pg_audit para detecção de anomalias, e um cluster de staging separado (mais muita esperança)
para upgrades de major version. Cada peça funciona isolada, mas é nas costuras que moram os incidentes: o script de failover que descarta transações em voo, o upgrade que passa em staging e quebra ORDER BY em produção, o SQL injection que só aparece no log da aplicação seis horas depois.
Esta apresentação introduz o HeliosProxy, um proxy open-source de protocolo PostgreSQL escrito em Rust que consolida essas preocupações num único componente onde seus clientes psql, asyncpg, JDBC e pgx se conectam sem mudar uma linha de código.
A talk é estruturada em três demos ao vivo:
1. Switchover sem perdas com transaction journal. Vamos derrubar o primário no meio de uma workload, ver o HeliosProxy bufferizar os statements em voo, promover um standby, e fazer replay da janela jornalizada num replica defasado via POST /api/replay para que ele alcance o estado atual sem reseed. O cliente vê uma pausa breve, sem erros.
2. Shadow execute para upgrades de major version. Apontamos o proxy para um primário PG14 e um candidato PG16, mandamos cada query para os dois, e diferenciamos os resultados. Vamos provocar uma divergência real — ordenação de NULL, mudança de comportamento de regex, mudança de ordem de linhas induzida pelo planner — e vê-la aparecer em /api/shadow antes de qualquer cliente tocar a versão nova. É a rede de segurança que a maioria dos times constrói à mão e nunca confia totalmente.
3. Detecção de anomalias na borda do fio. Vamos disparar um burst de credential stuffing e uma sondagem clássica de SQLi do tipo UNION contra o proxy, e ver /anomalies sinalizar os dois em segundos, com a sessão ofensora, o padrão casado e o z-score. A detecção acontece no proxy, não no log da aplicação — o que significa que funciona para sistemas legados que não podem ser modificados.
Fechamos com um tour de 60 segundos pelo sistema de plugins WASM: oito plugins first-party (cost-governor, column-mask para PII, residency-router, llm-guardrail para sidecars de IA, pgvector-router, audit-chain, token-budget, ai-classifier) são distribuídos como artefatos OCI assinados e fazem hot-reload sem reiniciar o proxy.
O que a audiência leva para casa:
- Modelo mental claro do que um wire-protocol proxy pode e não pode fazer pelo seu deployment PostgreSQL.
- Receita reproduzível para upgrades PG14→PG16 (ou 15→17) mais seguros usando shadow execute.
- Padrão de switchover que não descarta transações, com endpoint de replay para catch-up de standby defasado.
- Detecção de anomalias na L7 sem tocar no código da aplicação.
- Repositório com 22 demos docker-compose que dão para rodar no laptop na mesma noite.
Nível: intermediário. Útil para DBAs avaliando estratégias de HA, devs cansados de escrever lógica de retry com failover, e platform engineers operando Postgres multi-tenant.