Nord42 EXPLAIN ANALYZE
Nord42 · Engenharia de dados em escala

PostgreSQL e ClickHouse afinados para throughput real.

Consultoria hiper-técnica em engenharia de dados — query tuning, replicação, particionamento, pipelines em tempo real e ClickHouse para analítico em escala. Sem prosa de enterprise, sem genérico de TI.

Ver benchmarks
PostgreSQL 13–16 ClickHouse 23+ Replicação · sharding p99 medido sempre
§ 02 / Serviços

Cinco coisas que a gente faz a sério.

Não somos consultoria genérica de TI. Cada serviço entrega benchmark antes/depois, plano de ação com nomes de commits e runbook operacional — não slide.

Frente 01 · Tuning

PostgreSQL tuning

Query tuning, indexes, autovacuum, particionamento, configuração de memória, work_mem, shared_buffers e parallel workers para o seu workload real.

  • EXPLAIN ANALYZE em todas as queries críticas
  • Index strategy revisada (B-tree, BRIN, GIN, parcial)
  • Particionamento declarativo (range, list, hash)
  • Autovacuum agressivo onde precisa
Frente 02 · ClickHouse

ClickHouse em escala

Modelagem analítica, MergeTree e suas variantes, materialização incremental, projections e Distributed engine — para tabelas de bilhões de linhas.

  • Escolha de engine por padrão de acesso
  • Materialized views incrementais
  • Sharding + replicação ZooKeeper/Keeper
  • Compressão e codecs por coluna
Frente 03 · Replication

Replicação & alta disponibilidade

Streaming replication com Patroni, hot standby, failover testado, logical replication para CDC e read replicas geográficas.

  • Patroni + etcd em produção
  • Failover automático < 30s
  • Backup contínuo com pgBackRest + WAL-G
  • Restore drill mensal documentado
Frente 04 · Pipelines

Pipelines de dados

Ingestão em tempo real com Kafka/Debezium, ETL incremental, CDC entre Postgres e ClickHouse, idempotência e dead-letter por padrão.

  • Kafka + Debezium para CDC
  • dbt + ClickHouse para modelagem
  • Exactly-once via offsets + Idempotência
  • Observabilidade · lag, throughput, error rate
§ 03 / Benchmarks

Antes e depois. Em milissegundos.

Casos reais resolvidos. Todos com EXPLAIN ANALYZE em produção, benchmark reproduzível e plano de ação versionado em Git. NDA limita o cliente, não o número.

FinTech · checkout

Query de fechamento mensal · Postgres

Relatório de fechamento usado pela controladoria batia timeout. Reescrita com window functions + index parcial.

Antes38 s
Depois410 ms
−98,9%Execução
E-commerce · catálogo

Busca por filtros · ClickHouse

Catálogo com 180M de SKUs e 40 facetas. Migração de OpenSearch para ClickHouse com projections.

p99 OpenSearch1 240 ms
p99 ClickHouse62 ms
−95,0%Latência p99
Logística · roteirização

Insert burst · Postgres

1.2B linhas/dia, contenção em autovacuum. Particionamento por hora + tuning de bgwriter resolveu sem mudar app.

Throughput12k/s
Throughput94k/s
7,8×Throughput
§ 04 / Manifesto técnico

Como a gente trabalha.

Quatro princípios que aparecem em todo projeto. Não é cultura de slide — é o que recusamos negociar quando o prazo aperta.

01
Reproduzível ou não aconteceu

Todo benchmark vem com dataset sintético público, script de carga e ambiente Docker. Se você não consegue rodar, não estamos vendendo.

02
p99, não média

Latência média esconde os 10% piores. Toda métrica é p50, p95, p99, p99.9 — porque é onde o usuário sente.

03
Git, não Word

Documentação técnica entregue como código (markdown + diagramas-as-code), versionada no repo do cliente. Não há "anexos finais" no e-mail.

04
Sem prosa de enterprise

Não vendemos "soluções estratégicas de dados". Vendemos índices, queries, partições, replicas. Coisas que existem no banco.

§ 05 / Stack que dominamos

Profundidade em poucos. Sem dispersão.

A gente já tropeçou nos edge cases que você não conhece ainda. Esse é o stack que efetivamente tunamos em produção — para o resto, indicamos quem faz melhor.

PostgreSQL13 → 16 · core
ClickHouse23+ · OLAP
PatroniHA · failover
pgBackRestBackup contínuo
DebeziumCDC streaming
KafkaMensageria
dbtModelagem analítica
RedisCache · streams
TimescaleDBTime-series
PgBouncerConnection pool
Grafana + PromObservabilidade
Stack próprioConversar
§ 06 / Processo

Diagnóstico antes de qualquer commit.

A gente não toca em config sem medir antes. Quatro fases, entregáveis claros e sem surpresa de fechamento — você sabe o que ganhou em ms a cada sprint.

Fase 01

Audit

Snapshot completo do banco em produção: schema, queries lentas, locks, autovacuum, replicação, índices não usados.

Semana 1
Fase 02

Plano de ação

Roadmap priorizado por impacto vs esforço. Cada item tem benchmark esperado e plano de rollback definido.

Semana 2
Fase 03

Execução

Sprints semanais, mudanças em staging, benchmark antes/depois, deploy controlado em prod com observabilidade.

Núcleo · 4–10 sem
Fase 04

Handover

Runbook operacional, treinamento da equipe, dashboards de observabilidade configurados e período de garantia.

2 semanas
Próximo passo

Manda a query lenta.

30 minutos de conversa técnica, sem briefing comercial. Você cola o EXPLAIN ANALYZE da query que está incomodando, a gente fala o que faria. Sem assinatura, sem custo.

Resposta em até 1 dia útil · NDA disponível