Explore as ideias centrais de Michael Stonebraker por trás de Ingres, Postgres e Vertica — e como elas moldaram bancos SQL, motores analíticos e as stacks de dados atuais.
Michael Stonebraker é um cientista da computação cujos projetos não só influenciaram a pesquisa em bancos de dados — eles moldaram diretamente produtos e padrões de design que muitas equipes usam todo dia. Se você já usou um banco relacional, um data warehouse analítico ou um sistema de streaming, se beneficiou de ideias que ele ajudou a provar, construir ou popularizar.
Isto não é uma biografia nem um tour acadêmico pela teoria de bancos de dados. Em vez disso, conecta os sistemas principais de Stonebraker (como Ingres, Postgres e Vertica) às escolhas que você vê nas stacks de dados modernas:
Um banco de dados moderno é qualquer sistema que possa, de forma confiável:
Diferentes bancos otimizam esses objetivos de formas distintas — especialmente quando você compara aplicações transacionais, painéis de BI e pipelines em tempo real.
Focaremos no impacto prático: ideias que aparecem no mundo de hoje de “warehouse + lake + stream + microservices” e como elas influenciam o que você compra, constrói e opera. Espere explicações claras, trade-offs e implicações do mundo real — não uma imersão em provas ou detalhes de implementação.
A carreira de Stonebraker é mais fácil de entender como uma sequência de sistemas construídos para trabalhos específicos — e então observar as melhores ideias migrarem para produtos mainstream.
Ingres começou como um projeto acadêmico que provou que bancos relacionais podiam ser rápidos e práticos, não apenas teoria. Ajudou a popularizar consultas no estilo SQL e o pensamento de otimização baseada em custo que depois virou padrão em engines comerciais.
Postgres (o sistema de pesquisa que levou ao PostgreSQL) explorou outra aposta: bancos não deveriam ser função fixa. Você deveria poder adicionar novos tipos de dados, novos métodos de indexação e comportamentos mais ricos sem reescrever o motor todo.
Muitas features “modernas” têm raízes nessa era — tipos extensíveis, funções definidas pelo usuário e um banco que pode se adaptar conforme as cargas mudam.
Com o crescimento da analítica, sistemas orientados a linhas sofreram com grandes varreduras e agregações. Stonebraker impulsionou o armazenamento colunar e técnicas de execução relacionadas, voltadas a ler apenas as colunas necessárias e compactá-las bem — ideias que hoje são padrão em bancos analíticos e data warehouses na nuvem.
Vertica pegou as ideias de pesquisa de armazenamento colunar e as transformou em um motor SQL massivamente paralelo (MPP) viável comercialmente, desenhado para grandes consultas analíticas. Esse padrão se repete na indústria: um protótipo de pesquisa valida um conceito; um produto o endurece para confiabilidade, tooling e restrições de clientes reais.
Trabalhos posteriores se expandiram para processamento de streams e motores específicos por workload — argumentando que um banco generalista raramente vence em tudo.
Um protótipo é construído para testar uma hipótese rapidamente; um produto precisa priorizar operabilidade: upgrades, monitoramento, segurança, desempenho previsível e suporte. A influência de Stonebraker aparece porque muitas ideias de protótipo viraram capacidades padrão em bancos comerciais, em vez de opções de nicho.
Ingres (abreviação de INteractive Graphics REtrieval System) foi a prova inicial de Stonebraker de que o modelo relacional podia ser mais que uma teoria elegante. Na época, muitos sistemas eram construídos em torno de métodos de acesso customizados e caminhos de dados específicos de aplicação.
Ingres buscava resolver um problema simples e voltado ao negócio:
Como permitir que as pessoas façam perguntas flexíveis sobre dados sem reescrever o software sempre que a pergunta muda?
Bancos relacionais prometiam que você poderia descrever o que quer (por exemplo, “clientes na Califórnia com faturas em atraso”) em vez de como buscá-lo passo a passo. Mas tornar essa promessa real exigia um sistema capaz de:
Ingres foi um grande passo rumo à versão “prática” do processamento relacional — uma que rodava no hardware da época e ainda respondia de forma aceitável.
Ingres ajudou a popularizar a ideia de que o banco de dados deveria fazer o trabalho pesado de planejar consultas. Em vez de desenvolvedores tunarem cada acesso a dados, o sistema podia escolher estratégias como que tabela ler primeiro, quais índices usar e como juntar tabelas.
Isso fez o pensamento em SQL se espalhar: quando você pode escrever consultas declarativas, itera mais rápido, e mais pessoas conseguem fazer perguntas diretamente — analistas, times de produto e finanças — sem esperar por relatórios sob medida.
A grande ideia prática é a otimização baseada em custo: escolher o plano de consulta com menor “custo” esperado (geralmente mistura de I/O, CPU e memória), com base em estatísticas dos dados.
Isso importa porque frequentemente significa:
Ingres não inventou cada pedaço da otimização moderna, mas ajudou a estabelecer o padrão: SQL + um otimizador é o que faz sistemas relacionais escalarem de “boa ideia” para ferramenta do dia a dia.
Bancos relacionais iniciais tendiam a assumir um conjunto fixo de tipos de dados (números, texto, datas) e um conjunto fixo de operações (filter, join, aggregate). Isso funcionava bem — até equipes começarem a armazenar novos tipos de informação (geografia, logs, séries temporais, identificadores específicos de domínio) ou precisarem de recursos de desempenho especializados.
Com um projeto rígido, cada novo requisito vira uma escolha ruim: encaixar dados em blobs de texto, empurrar para um sistema separado ou esperar o fornecedor adicionar suporte.
Postgres defendeu uma ideia diferente: um banco deve ser extensível — ou seja, você pode adicionar novas capacidades de forma controlada, sem quebrar a segurança e correção esperadas do SQL.
Em termos simples, extensibilidade é como adicionar acessórios certificados a uma ferramenta elétrica em vez de reconfigurar o motor você mesmo. Você pode ensinar o banco “novos truques”, mantendo transações, permissões e otimização de consultas funcionando de forma coerente.
Essa mentalidade aparece claramente no ecossistema atual do PostgreSQL (e muitos sistemas inspirados em Postgres). Em vez de esperar por uma feature no núcleo, equipes podem adotar extensões aprovadas que se integram bem com SQL e ferramentas operacionais.
Exemplos de alto nível comuns incluem:
O ponto central é que o Postgres tratou “mudar o que o banco pode fazer” como um objetivo de design — não como um pensamento tardio — e essa ideia ainda influencia como plataformas de dados modernas evoluem.
Bancos não são apenas sobre armazenar informação — são sobre garantir que a informação continue certa, mesmo quando muitas coisas acontecem ao mesmo tempo. Isso é o que transações e controle de concorrência fazem, e é uma razão importante pela qual sistemas SQL se tornaram confiáveis para trabalho real de negócios.
Uma transação é um conjunto de mudanças que deve ou todas serem aplicadas ou nenhuma.
Se você transferir dinheiro entre contas, fizer um pedido ou atualizar inventário, não pode aceitar resultados “meio feitos”. Uma transação garante que você não termine com um pedido que cobrou o cliente mas não reservou estoque — ou estoque reduzido sem que o pedido tenha sido registrado.
Na prática, transações dão:
Concorrência significa muitas pessoas (e apps) lendo e mudando dados ao mesmo tempo: checkouts de clientes, agentes de suporte editando contas, jobs em background atualizando status, analistas rodando relatórios.
Sem regras cuidadosas, concorrência cria problemas como:
Uma abordagem influente é MVCC (Multi-Version Concurrency Control). Conceitualmente, MVCC mantém múltiplas versões de uma linha por um curto período, para que leitores possam continuar vendo um snapshot estável enquanto escritores fazem atualizações.
O grande benefício é que leituras não bloqueiam escritas com tanta frequência, e escritores não ficam constantemente presos atrás de consultas de longa duração. Você ainda obtém correção, mas com menos espera.
Bancos atuais frequentemente servem workloads mistos: muitas escritas de aplicação junto com leituras frequentes para dashboards, visualizações de clientes e análises operacionais. Sistemas SQL modernos usam técnicas como MVCC, locks mais inteligentes e níveis de isolamento para equilibrar velocidade e correção — assim você escala atividade sem perder confiança nos dados.
Bancos orientados a linhas foram projetados para processamento transacional: muitas leituras e escritas pequenas, tipicamente tocando um cliente, um pedido ou uma conta por vez. Esse desenho é ótimo quando você precisa buscar ou atualizar um registro inteiro rapidamente.
Pense em uma planilha. Um row store é como arquivar cada linha em sua própria pasta: quando você precisa de “tudo sobre o Pedido #123”, puxa uma pasta e pronto. Um column store é como arquivar por coluna: uma gaveta para “order_total”, outra para “order_date”, outra para “customer_region”.
Para analítica, raramente você precisa da pasta inteira — normalmente pergunta algo como “Qual foi a receita por região no último trimestre?” Essa consulta pode tocar apenas alguns campos em milhões de registros.
Consultas analíticas frequentemente:
Com armazenamento colunar, o motor pode ler apenas as colunas referenciadas na consulta, ignorando o resto. Menos dados lidos do disco (e menos movimentados pela memória) é frequentemente o maior ganho de desempenho.
Colunas tendem a ter valores repetitivos (regiões, status, categorias). Isso as torna altamente compressíveis — e compressão pode acelerar a analítica porque o sistema lê menos bytes e às vezes opera diretamente sobre dados comprimidos de forma mais eficiente.
Os column stores ajudaram a marcar a migração de bancos OLTP-first para motores com foco em analítica, onde varredura, compressão e agregações rápidas viraram objetivos de design primários em vez de reflexos tardios.
Vertica é um dos exemplos mais claros de como ideias de Stonebraker sobre bancos analíticos viraram um produto que equipes podiam rodar em produção. Pegou lições de armazenamento colunar e as combinou com um design distribuído focado em um problema específico: responder consultas SQL analíticas grandes rapidamente, mesmo quando volumes excedem um servidor único.
MPP significa processamento massivamente paralelo. A forma mais simples de pensar nisso: muitas máquinas trabalham numa única consulta SQL ao mesmo tempo.
Em vez de um servidor ler todos os dados e fazer todo o agrupamento e ordenação, os dados são divididos entre nós. Cada nó processa sua fatia em paralelo, e o sistema combina os resultados parciais numa resposta final.
É assim que uma consulta que levaria minutos numa máquina pode cair para segundos quando espalhada por um cluster — assumindo que os dados estejam bem distribuídos e a consulta seja paralelizável.
Sistemas analíticos estilo Vertica brilham quando você tem muitas linhas e quer varrê-las, filtrá-las e agregá-las eficientemente. Casos de uso típicos incluem:
Motores analíticos MPP não são substitutos diretos para sistemas transacionais (OLTP). Eles são otimizados para ler muitas linhas e computar resumos, não para lidar com muitas atualizações pequenas.
Isso leva a trade-offs comuns:
A ideia-chave é foco: Vertica e sistemas similares ganham velocidade ao ajustar armazenamento, compressão e execução paralela para analítica — e então aceitam restrições que sistemas transacionais evitam.
Um banco pode “armazenar e consultar” dados e ainda assim parecer lento para analítica. A diferença frequentemente não está no SQL que você escreve, mas em como o motor o executa: como lê páginas, move dados pela CPU, usa memória e minimiza trabalho desperdiçado.
Projetos focados em analítica de Stonebraker empurraram a ideia de que desempenho de consulta é tanto um problema de execução quanto de armazenamento. Esse pensamento ajudou a deslocar times de otimizar buscas de linha única para otimizar varreduras longas, joins e agregações sobre milhões (ou bilhões) de linhas.
Muitos engines antigos processam consultas “tupla-a-tupla” (linha por linha), o que cria muitas chamadas de função e overhead. A execução vetorizada inverte esse modelo: o motor processa um lote (um vetor) de valores em um loop apertado.
Em termos simples, é como mover compras com um carrinho em vez de carregar um item por viagem. Batching reduz overhead e permite que CPUs modernas façam o que sabem bem: loops previsíveis, menos branches e melhor uso de cache.
Motores analíticos rápidos se obsessam por ser eficientes em CPU e cache. Inovações de execução comumente focam em:
Essas ideias importam porque consultas analíticas frequentemente são limitadas por largura de banda de memória e faltas de cache, não por velocidade bruta de disco.
Data warehouses modernos e engines SQL — warehouses na nuvem, sistemas MPP e ferramentas analíticas rápidas em-processo — frequentemente usam execução vetorizada, operadores conscientes de compressão e pipelines cache-friendly como prática padrão.
Mesmo quando vendors vendem funcionalidades como “autoscaling” ou “separação de storage e compute”, a velocidade do dia a dia ainda depende muito dessas escolhas de execução.
Se você está avaliando plataformas, pergunte não apenas o que elas armazenam, mas como rodem joins e agregações por baixo dos panos — e se o modelo de execução é construído para analítica em vez de workloads transacionais.
Dados de streaming são simplesmente dados que chegam continuamente como uma sequência de eventos — pense em “uma nova coisa acabou de acontecer”. Um swipe de cartão, uma leitura de sensor, um clique numa página de produto, um scan de pacote, uma linha de log: cada um aparece em tempo real e continua chegando.
Bancos tradicionais e pipelines batch são ótimos quando você pode esperar: carregar os dados de ontem, rodar relatórios, publicar dashboards. Mas necessidades em tempo real não esperam pelo próximo job horário.
Se você processa dados apenas em batch, frequentemente acaba com:
Sistemas de streaming são desenhados em torno da ideia de que computações podem rodar continuamente à medida que eventos chegam.
Uma consulta contínua é como uma consulta SQL que nunca “termina”. Em vez de retornar um resultado uma vez, ela atualiza o resultado à medida que novos eventos chegam.
Como streams são ilimitados (não terminam), sistemas de streaming usam janelas para tornar cálculos manejáveis. Uma janela é uma fatia de tempo ou de eventos, como “últimos 5 minutos”, “cada minuto” ou “últimos 1.000 eventos”. Isso permite calcular contagens móveis, médias ou top-N sem reprocessar tudo.
Streaming em tempo real é mais valioso quando timing importa:
Stonebraker defende há décadas que bancos não deveriam ser todos construídos como máquinas generalistas “faça tudo”. A razão é simples: workloads diferentes recompensam escolhas de design diferentes. Se você otimiza fortemente para um trabalho (por exemplo, atualizações transacionais pequenas), normalmente torna outro trabalho mais lento (como varrer bilhões de linhas para um relatório).
A maioria das stacks modernas usa mais de um sistema porque o negócio pede mais de um tipo de resposta:
Isso é “um tamanho não serve para todos” na prática: você escolhe engines que casam com a forma do trabalho.
Use este filtro rápido ao escolher (ou justificar) outro sistema:
Múltiplos engines podem ser saudáveis, mas somente quando cada um tem um workload claro. Uma nova ferramenta deve ganhar seu lugar reduzindo custo, latência ou risco — não por novelty.
Prefira menos sistemas com forte propriedade operacional, e aposente componentes que não tenham um propósito mensurável e nítido.
Os fios de pesquisa de Stonebraker — fundamentos relacionais, extensibilidade, colunar, execução MPP e “a ferramenta certa para o trabalho” — são visíveis nas formas padrões de plataformas de dados modernas.
O warehouse reflete décadas de trabalho em otimização SQL, armazenamento colunar e execução paralela. Quando você vê dashboards rápidos sobre tabelas enormes, frequentemente está vendo formatos colunar + processamento vetorizado e escala estilo MPP.
O lakehouse pega ideias de warehouse (schemas, estatísticas, caching, otimização baseada em custo) mas as coloca sobre formatos de arquivo abertos e storage de objetos. A mudança de “storage é barato, compute elástico” é nova; o pensamento de consulta e transação por baixo não é.
Sistemas analíticos MPP (shared-nothing) são descendentes diretos de pesquisa que provou que você pode escalar SQL particionando dados, movendo computação para os dados e gerenciando cuidadosamente movimento de dados durante joins e agregações.
O SQL virou a interface comum entre warehouses, engines MPP e até camadas de consulta sobre lakes. Times o usam como:\n\n- um contrato estável para ferramentas de BI e analistas\n- uma camada de portabilidade quando engines mudam\n- uma superfície de governança (views, permissões, acesso auditado)
Mesmo quando a execução ocorre em engines diferentes (batch, interativo, streaming), o SQL frequentemente permanece a linguagem voltada ao usuário.
Armazenamento flexível não elimina a necessidade de estrutura. Schemas claros, significado documentado e evolução controlada reduzem quebras a jusante.
Boa governança é menos burocracia e mais tornar dados confiáveis: definições consistentes, propriedade, checagens de qualidade e controles de acesso.
Ao avaliar plataformas, pergunte:
Se um vendor não consegue mapear o produto a esses básicos em linguagem simples, a “inovação” pode ser mais embalagem do que substância.
A linha de pensamento de Stonebraker é simples: bancos funcionam melhor quando são desenhados para um job específico — e quando podem evoluir conforme esse job muda.
Antes de comparar features, escreva o que você precisa realmente fazer:\n\n- Analytics: varreduras longas, grandes agregações, muitas leituras\n- Transações: muitas atualizações pequenas, correção estrita, respostas rápidas\n- Workloads mistos: ambos, mas frequentemente à custa de tuning cuidadoso e prioridades claras\n- Feeds em tempo real: ingestão contínua e computação incremental
Uma regra útil: se você não consegue descrever seu workload em poucas frases (padrões de consulta, tamanho dos dados, necessidades de latência, concorrência), acabará comprando por buzzwords.
Times subestimam com que frequência requisitos mudam: novos tipos de dados, métricas, regras de compliance, novos consumidores.
Prefira plataformas e modelos de dados que tornem mudanças rotineiras em vez de arriscadas:\n\n- Separação clara entre armazenamento, consulta e pontos de extensão\n- Maneiras seguras de evoluir schemas e lançar nova lógica\n- Performance mensurável que não colapse com crescimento orgânico
Respostas rápidas só valem se forem as respostas certas. Ao avaliar opções, pergunte como o sistema lida com:\n\n- Escritas concorrentes (o que acontece quando duas pessoas/processos atualizam o mesmo registro?)\n- Isolamento e consistência (quais garantias você obtém e o que é sacrificado para consegui-las?)\n- Modos de falha operacionais (reinícios, outages parciais, backfills)
Faça um pequeno “proof com seus dados”, não só um demo:\n\n- Execute 3–5 queries representativas e meça tempo e custo.\n- Teste concorrência de pico (o spike de segunda de manhã).\n- Valide frescor dos dados, passos de recuperação e quem pode operá-lo no dia a dia.
Muita orientação em bancos de dados para por aí “escolha o motor certo”, mas times também precisam entregar apps e ferramentas internas em torno desse motor: painéis admin, dashboards, serviços de ingestão e workflows de back-office.
Se você quer prototipar isso rápido sem reinventar todo o pipeline, uma plataforma do tipo vibe-coding como Koder.ai pode ajudar a girar web apps (React), serviços backend (Go + PostgreSQL) e até clientes móveis (Flutter) a partir de um fluxo guiado por chat. Isso é útil ao iterar no design de schemas, construir um pequeno “data product” interno ou validar como um workload realmente se comporta antes de assumir infraestrutura de longo prazo.
Se quiser se aprofundar, procure por armazenamento colunar, MVCC, execução MPP e processamento de streams. Mais explainers vivem em /blog.
Ele é um caso raro em que sistemas de pesquisa se tornaram DNA de produto real. Ideias comprovadas em Ingres (SQL + otimização de consultas), Postgres (extensibilidade + pensamento MVCC) e Vertica (colunar + MPP analítico) aparecem hoje na forma como data warehouses, bancos OLTP e plataformas de streaming são construídos e posicionados.
O SQL venceu porque permite descrever o que você quer, enquanto o banco de dados resolve como obter isso de forma eficiente. Essa separação possibilitou:
Um otimizador baseado em custo usa estatísticas das tabelas para comparar planos de consulta possíveis e escolher o de menor custo esperado (I/O, CPU, memória). Na prática, isso ajuda a:
MVCC (Multi-Version Concurrency Control) mantém múltiplas versões de linhas para que leitores vejam um snapshot consistente enquanto escritores atualizam. No dia a dia:
Extensibilidade significa que o banco pode crescer com novas capacidades — tipos, funções, índices — sem você ter que bifurcar ou reescrever o motor. É útil quando você precisa:
Regra operacional: trate extensões como dependências — versioná-las, testar upgrades e limitar quem pode instalá-las.
Bancos em linha (row stores) são ótimos quando você frequentemente lê ou escreve registros inteiros (OLTP). Armazenamentos colunar brilham quando você varre muitas linhas mas toca poucas colunas (analítica).
Heurística simples:
MPP (processamento massivamente paralelo) divide dados entre nós para que muitas máquinas executem uma consulta SQL juntas. É adequado para:
Fique atento a trade-offs como escolha de distribuição de dados, custos de shuffle durante joins e ergonomia mais fraca para atualizações de linha de alta frequência.
Execução vetorizada processa dados em lotes (vetores) em vez de uma linha por vez, reduzindo overhead e usando o cache da CPU melhor. Normalmente você percebe como:
Sistemas batch executam jobs periodicamente, então os dados “frescos” podem ficar defasados. Streaming trata eventos como entrada contínua e calcula resultados incrementalmente.
Lugares comuns onde streaming compensa:
Para manter os cálculos contidos, o streaming usa janelas (por exemplo, últimos 5 minutos) em vez de “todo o tempo”.
Use múltiplos sistemas quando cada um tiver um limite de workload claro e benefício mensurável (custo, latência, confiabilidade). Para evitar proliferação de ferramentas:
Se precisar de um framework de seleção, reutilize a checklist descrita no post e peças relacionadas em /blog.
