Dados & Database.
Data & Database.
Plataformas de dados governadas, HA em PostgreSQL/Oracle/SQL Server, pipelines batch e streaming, DBA 24×7 com SLA formal. Ledger de 429 migrações desde 2011 — cada uma com runbook próprio, fallback ensaiado e métrica de sucesso assinada com o cliente.
Governed data platforms, HA on PostgreSQL/Oracle/SQL Server, batch and streaming pipelines, 24×7 DBA with a formal SLA. 429-migration ledger since 2011 — each one with its own runbook, rehearsed fallback, and a success metric signed off with the client.
Inventário honesto antes de qualquer plano.
Antes da modernização, a verdade sobre o estado atual. Quantos bancos. Quais versões. Quais sob suporte estendido. Onde o backup falha. Onde o RPO está abaixo do contratado. Saímos com matriz de risco — não com slide bonito.
- 01
Inventário automatizado
Discovery de instâncias, schemas, jobs, db links. Versão, edição, licenciamento, idade do hardware.
- 02
Performance baseline
Métricas de 2 semanas: top SQL, espera por evento, IO pattern, locks. Base para qualquer comparação pós-cutover.
- 03
Compliance & backup audit
RPO/RTO declarado × testado. Backups validáveis. LGPD, BACEN, ANS — exposição mapeada por dado sensível.
- 04
Matriz de risco
Por banco: criticidade × idade × suporte × custo. Saída prioriza modernização por dor real, não por hype de vendor.
429 migrações. Cada uma com runbook próprio.
A migração de banco é onde a gente se especializou. Não é commodity. Cada engine tem armadilhas próprias, cada workload tem peculiaridade fiscal/regulatória, cada cliente tem janela diferente. O que se repete é o método.
PL/SQL convertido para PL/pgSQL. Packages, sequences, hierarchical queries reescritas linha-a-linha.
RDS for Oracle, Aurora PostgreSQL ou ambos. Licença, custo total, plano de retirada do legado.
O caso difícil. Smart Scan, HCC, particionamento agressivo. Reescrita de plano antes do cutover.
Quando a regulação exige on-prem. Oracle on AIX em arquitetura RAC, com tuning específico de I/O.
PL/SQL para T-SQL, ajuste de tipos, conversão de hints, reconciliação contínua durante a janela.
Conversa em 45 min com DBA sênior.
- 01
Conversão de schema & código
PL/SQL → PL/pgSQL, T-SQL → PL/pgSQL, packages, triggers, sequences, hierarchical queries. Ora2Pg + AWS SCT + revisão linha-a-linha. O que não converte automático, a gente reescreve.
- 02
Cargas iniciais & sincronismo contínuo
Carga full + CDC durante semanas para fechar o delta. Cutover de 30 min em janela de baixa, com fallback ensaiado duas vezes antes.
- 03
Validação cruzada
Reconciliação linha a linha pós-cutover. Em uma migração de 4,2M linhas, divergência tem que ser zero antes de declarar sucesso.
- 04
Tuning pós-migração
Plan que rodava bem em Oracle quase nunca roda igual em PostgreSQL. Reescrita de queries críticas, índices funcionais, particionamento. +27% performance média porque a migração inclui essa fase — não termina no cutover.
- 05
Coexistência prolongada
Quando o legado não pode morrer no D-zero. Réplica bidirecional, roteamento por feature flag, descomissionamento gradual.
Não é metodologia em PDF. É código.
Desde 2011, o ledger de migrações acumulou um framework próprio — runbooks parametrizáveis, scripts de reconciliação, harness de testes, checklist de pré/pós-cutover. Não é segredo industrial: a gente entrega tudo para o cliente. Mas é o que faz a 429ª migração ser tão sólida quanto a 1ª foi cuidadosa.
- F·01
Discovery automatizado
Inventário de objetos, dependências, jobs, DB links, sequences. Em 4h tem mapa que normalmente leva 2 semanas para alguém escrever no Excel.
- F·02
Runbook parametrizado
YAML que descreve cada onda. Pre-checks, execução, validação, rollback. Mesma estrutura para qualquer engine. Versionado, revisado por PR.
- F·03
Harness de testes estruturados
Sintético + amostragem + reconciliação. Roda em ambiente mirror antes do D-zero. Falha quebra o pipeline — não vira "warning aceitável".
- F·04
Análise de histórico
AWR, Statspack, pg_stat_statements, query store. Cruzamos 30 dias de carga real com o catálogo de objetos para priorizar tuning antes do cutover, não depois.
- F·05
Fallback ensaiado
Roll-forward é fácil. Voltar é o que separa migração séria de bravata. Cada onda tem fallback rodado em ambiente mirror na sexta antes.
- F·06
Postmortem obrigatório
Mesmo sem incidente. Em 5 dias úteis. Vai pro framework: o que aprendemos vira checklist da próxima.
Plataforma própria, construída por quem opera.
gator.red é a plataforma que a gente queria ter quando começou. Inventário vivo de bancos, observabilidade específica para DB, automação das tarefas DBA recorrentes, plantão integrado e — o módulo que mais usamos — o motor de migração com o framework empacotado.
Inventário vivo
Catálogo dos bancos da casa. Versão, patch, owner, contratos, janelas, dependências. Atualiza sozinho — não fica desatualizado em 6 meses.
Observabilidade DB-first
Métricas que importam para DBA: top queries, lock waits, replication lag, fragmentação. Dashboards que o time olha, não que existem para auditoria.
Automação de tarefas
Refresh de homolog, mascaramento, criação de réplica, rotação de credencial, patch coordenado. Self-service para o time do cliente.
Motor de migração
O framework empacotado. Discovery, runbook, harness, reconciliação, fallback. A 429ª migração rodou aqui dentro.
Plantão integrado
Alerta chega no engenheiro com contexto: histórico do banco, runbook do incidente parecido, último postmortem relacionado. Sem abrir 5 abas.
Análise de histórico
30, 60, 180 dias de carga real cruzada com catálogo. Gera priorização de tuning, alerta sobre query que mudou comportamento, sugere índice antes do problema.
Antes do cutover. Depois também.
A diferença entre uma migração tranquila e um sábado de madrugada perdido é teste estruturado. A gente trata banco como sistema de software: tem fixture, tem sintético, tem benchmark, tem regressão.
- 01
Análise de histórico de carga
AWR/Statspack/pg_stat_statements consolidados. Top 50 queries por tempo, por I/O, por execuções. Sabe-se o que dói antes de mexer.
- 02
Workload sintético
Reprodução fiel da carga real em ambiente mirror. Não é sysbench genérico — é o seu workload, na sua proporção.
- 03
Benchmark comparativo
Antes vs. depois, query a query. Latência p50/p95/p99, throughput, contention. Se piorou, fica claro onde e por quê.
- 04
Reconciliação de dados
Hash de partição, count cruzado, amostragem por chave. Em migração regulada (BACEN, BCB, ANS) vai para o auditor.
- 05
Regressão automatizada
Suite que roda em CI a cada release. Migração não é evento único — é cama elástica.
Honest inventory before any plan.
Before modernization, the truth about the current state. How many databases. Which versions. Which on extended support. Where backups fail. Where RPO is below contract. We leave with a risk matrix — not a pretty slide.
- 01
Automated inventory
Discovery of instances, schemas, jobs, db links. Version, edition, licensing, hardware age.
- 02
Performance baseline
2-week metrics: top SQL, wait events, IO pattern, locks. Baseline for any post-cutover comparison.
- 03
Compliance & backup audit
Declared RPO/RTO × tested RPO/RTO. Validatable backups. LGPD, BACEN, ANS — exposure mapped per sensitive datum.
- 04
Risk matrix
Per database: criticality × age × support × cost. Output prioritizes modernization by real pain, not vendor hype.
429 migrations. Each one with its own runbook.
Database migration is where we specialized. It is not a commodity. Each engine has its own traps, each workload has tax/regulatory quirks, each client has a different window. What repeats is the method.
PL/SQL converted to PL/pgSQL. Packages, sequences, hierarchical queries rewritten line by line.
RDS for Oracle, Aurora PostgreSQL or both. Licensing, total cost, plan for retiring the legacy.
The hard case. Smart Scan, HCC, aggressive partitioning. Plan rewriting before cutover.
When regulation requires on-prem. Oracle on AIX in RAC architecture, with I/O-specific tuning.
PL/SQL to T-SQL, type adjustments, hint conversion, continuous reconciliation during the window.
45-min chat with a senior DBA.
- 01
Schema & code conversion
PL/SQL → PL/pgSQL, T-SQL → PL/pgSQL, packages, triggers, sequences, hierarchical queries. Ora2Pg + AWS SCT + line-by-line review. What doesn’t convert automatically, we rewrite.
- 02
Initial loads & continuous sync
Full load + CDC for weeks to close the delta. 30-min cutover in a low-traffic window, with fallback rehearsed twice beforehand.
- 03
Cross-validation
Row-by-row reconciliation after cutover. On a 4.2M-row migration, divergence must be zero before declaring success.
- 04
Post-migration tuning
A plan that ran well on Oracle almost never runs the same on PostgreSQL. Critical query rewrites, functional indexes, partitioning. +27% average performance because migration includes this phase — it doesn’t end at cutover.
- 05
Prolonged coexistence
When the legacy can’t die at D-zero. Bi-directional replica, feature-flag routing, gradual decommissioning.
Not methodology in a PDF. It’s code.
Since 2011, the migration ledger has accumulated a proprietary migration framework — parameterizable runbooks, reconciliation scripts, test harnesses, pre/post-cutover checklists. It is not a trade secret: we hand it all to the client. But it is what makes the 429th migration as solid as the 1st was careful.
- F·01
Automated discovery
Inventory of objects, dependencies, jobs, DB links, sequences. In 4h we have a map that normally takes someone 2 weeks in Excel.
- F·02
Parameterized runbook
YAML describing each wave. Pre-checks, execution, validation, rollback. Same structure for any engine. Versioned, reviewed by PR.
- F·03
Structured test harness
Synthetic + sampling + reconciliation. Runs in a mirror environment before D-zero. Failure breaks the pipeline — it does not become "acceptable warning".
- F·04
Historical analysis
AWR, Statspack, pg_stat_statements, query store. We cross 30 days of real load with the object catalog to prioritize tuning before cutover, not after.
- F·05
Rehearsed fallback
Roll-forward is easy. Coming back is what separates a serious migration from bravado. Every wave has fallback rehearsed in a mirror environment the Friday before.
- F·06
Mandatory postmortem
Even with no incident. In 5 business days. Feeds the framework: what we learned becomes the next checklist.
Our own platform, built by people who operate.
gator.red is the platform we wished we had when we started. Live inventory of databases, DB-specific observability, automation of recurring DBA tasks, integrated on-call and — the module we use the most — the migration engine with the framework packaged in.
Live inventory
Catalog of in-house databases. Version, patch, owner, contracts, windows, dependencies. Updates itself — does not go stale in 6 months.
DB-first observability
Metrics that matter to a DBA: top queries, lock waits, replication lag, fragmentation. Dashboards the team actually looks at, not ones that exist for audit.
Task automation
Staging refresh, masking, replica creation, credential rotation, coordinated patching. Self-service for the client team.
Migration engine
The framework packaged. Discovery, runbook, harness, reconciliation, fallback. The 429th migration ran inside this.
Integrated on-call
Alert reaches the engineer with context: database history, runbook from similar incident, last related postmortem. Without opening 5 tabs.
Historical analysis
30, 60, 180 days of real load crossed with the catalog. Generates tuning priorities, alerts on queries that changed behavior, suggests indexes before the problem.
Before cutover. After it too.
The difference between a calm migration and a lost Saturday at dawn is structured testing. We treat a database like a software system: it has fixtures, synthetics, benchmarks, regressions.
- 01
Load history analysis
AWR/Statspack/pg_stat_statements consolidated. Top 50 queries by time, by I/O, by executions. We know what hurts before touching it.
- 02
Synthetic workload
Faithful reproduction of real load in a mirror environment. Not a generic sysbench — it is your workload, in your proportions.
- 03
Comparative benchmark
Before vs. after, query by query. p50/p95/p99 latency, throughput, contention. If it got worse, where and why becomes obvious.
- 04
Data reconciliation
Partition hash, cross-counts, sampling by key. In a regulated migration (BACEN, BCB, ANS) it goes to the auditor.
- 05
Automated regression
Suite that runs on CI on every release. Migration is not a one-off event — it is a trampoline.
Tem banco difícil para migrar, sincronizar ou converter? Conta o problema.
45 min com um DBA sênior. Sem pitch.
Got a tough database to migrate, sync, or convert? Tell us the problem.
45 min with a senior DBA. No pitch.