House M.D., COBOL e o Caso do Banco de Dados que se Recusava a Esquecer: Datomic versus Db2 na Sala de Diagnóstico

 

Bellacosa Mainframe e a comparacao entre datomic e db2

☕ Um Café no Bellacosa Mainframe

House M.D., COBOL e o Caso do Banco de Dados que se Recusava a Esquecer: Datomic versus Db2 na Sala de Diagnóstico

🩺 SQL contra Datalog, UPDATE contra imutabilidade, buffer pools contra caches, logs contra história nativa, scale-up contra scale-out, décadas de cicatrizes contra arquitetura funcional — e a pergunta que ninguém deveria responder com religião tecnológica: “qual deles eu usaria para guardar o dinheiro?”

House entra na sala.

Olha para o quadro.

De um lado:

IBM Db2

Do outro:

Datomic

Foreman pergunta:

— Qual é o diagnóstico?

House apoia a bengala na mesa.

— Um deles tem quase meio século de experiência em ambientes corporativos. O outro nasceu em 2012 de um cara que achava que mudar estado demais era uma péssima ideia.

Cameron:

— Então Db2 ganha?

House:

— Você não entendeu nada.

Chase:

— Datomic ganha?

House:

— Você também não.

Ele olha para todos.

— Banco de dados não é concurso de popularidade. É diagnóstico diferencial.

E aí começa nossa consulta.

Porque comparar Datomic com Db2 apenas perguntando “qual é melhor?” é como perguntar se um bisturi é melhor que uma ressonância magnética.

Depende do problema.

Depende do paciente.

Depende do risco.

E, principalmente:

depende do que você está tentando preservar, consultar, transacionar e recuperar quando tudo der errado às 03h17 da manhã.

Pegue o café.

Hoje vamos abrir o paciente.

---

1. Primeiro sintoma: ambos guardam dados, mas pensam diferente

Db2 nasceu dentro da tradição relacional.

Você pensa em:

TABLE
ROW
COLUMN
PRIMARY KEY
FOREIGN KEY
INDEX
SQL

Exemplo:

CREATE TABLE CONTA (
    ID        CHAR(10) NOT NULL,
    TITULAR   VARCHAR(100),
    SALDO     DECIMAL(15,2),
    PRIMARY KEY (ID)
);

Depois:

SELECT SALDO
FROM CONTA
WHERE ID = '000123';

Simples.

Familiar.

Décadas de ferramentas, otimizadores, DBAs, utilities, backups, logs, reorgs, statistics, access paths e trauma acumulado.

Datomic pensa diferente.

Ele enxerga fatos.

Conceitualmente:

ENTITY
ATTRIBUTE
VALUE
TRANSACTION

Algo como:

[1001 :conta/id "000123"]
[1001 :conta/titular "Arthur Dent"]
[1001 :conta/saldo 1000]

Então já aparece a primeira diferença fundamental:

Db2

“Tenho registros relacionais.”

Datomic

“Tenho fatos sobre entidades ao longo do tempo.”

House olha para o quadro.

— Não são duas implementações do mesmo modelo.

— Então são doenças diferentes?

— Não. São anatomias diferentes.

---

2. O grande choque: UPDATE

Aqui começa a parte que faz o COBOLzeiro apertar a caneca.

Em Db2:

UPDATE CONTA
   SET SALDO = 800
 WHERE ID = '000123';

Estado anterior:

SALDO = 1000

Estado atual:

SALDO = 800

Claro: Db2 possui transaction log, temporal tables, auditing, CDC e recursos para reconstruir histórico.

Mas o modelo lógico mais comum continua sendo:

ANTES
  ↓
UPDATE
  ↓
DEPOIS

Datomic trata a evolução do dado de forma diferente.

O histórico faz parte do modelo.

Conceitualmente:

T1
conta/saldo = 1000

T2
retract saldo 1000
assert saldo 800

Você não simplesmente “apagou” a existência anterior.

Você criou uma nova realidade temporal.

House aponta:

— Um sofre amnésia por padrão lógico.

Wilson responde:

— Db2 não perde o passado, House.

— Eu disse lógico, não físico. Preste atenção.

Essa distinção é importante.

---

3. Db2 tem logs. Datomic tem memória histórica como filosofia

Db2 registra transações para recovery.

Isso é central.

BEGIN
  UPDATE
  UPDATE
COMMIT

Db2 precisa saber como:

ROLLBACK
REDO
UNDO
RECOVER

O log é infraestrutura de sobrevivência.

Datomic trata a história como parte natural do database value.

Você pode consultar algo como:

as-of
since
history

Ou seja:

QUAL ERA O BANCO
EM T1?

não é uma pergunta excepcional.

É parte natural da arquitetura.

Aqui está uma diferença conceitual enorme.

Db2:

histórico pode ser construído, configurado, auditado e recuperado.

Datomic:

histórico está no DNA.

Nenhum dos dois é “mais sério” automaticamente.

Mas o segundo torna alguns problemas temporais muito mais naturais.

---

4. Diagnóstico diferencial: SQL versus Datalog

Db2 fala SQL.

E SQL é provavelmente uma das linguagens técnicas mais difundidas da história.

SELECT C.NOME,
       SUM(M.VALOR)
FROM CLIENTE C
JOIN MOVIMENTO M
  ON M.CLIENTE_ID = C.ID
WHERE C.STATUS = 'ATIVO'
GROUP BY C.NOME;

Milhões de pessoas entendem isso.

Datomic usa Datalog.

Exemplo conceitual:

[:find ?nome (sum ?valor)
 :where
 [?c :cliente/nome ?nome]
 [?c :cliente/status :ativo]
 [?m :movimento/cliente ?c]
 [?m :movimento/valor ?valor]]

O modelo é declarativo também.

Mas pensa mais em relações lógicas.

House olha.

— Isso é SQL depois de passar três semanas num retiro filosófico?

Cameron:

— É Datalog.

— Exatamente o que eu disse.

😂

---

5. Db2 tem tabelas. Datomic tem entidades e atributos

No mundo relacional:

CLIENTE
  |
  +-- ID
  +-- NOME
  +-- CPF
  +-- STATUS

No Datomic:

ENTITY 1001
  |
  +-- :cliente/id
  +-- :cliente/nome
  +-- :cliente/cpf
  +-- :cliente/status

Isso pode parecer semanticamente parecido.

Mas não é idêntico.

No Db2, schema é fortemente estruturado em tabelas.

No Datomic, atributos são entidades do próprio schema.

A flexibilidade muda.

E também muda a maneira de evoluir schema.

Em Datomic existe uma tendência forte a schema aditivo:

adiciona atributo
adiciona relação
preserva passado

No Db2 você pode fazer:

ALTER TABLE

com todos os cuidados que conhece.

O ponto é:

ambos possuem schema, mas a filosofia de evolução é diferente.

---

6. Índices: Db2 pergunta “qual index?”. Datomic responde “qual ordenação?”

No Db2:

TABLE
  |
  +-- INDEX A
  +-- INDEX B
  +-- INDEX C

Você escolhe índices conforme acesso.

O DBA pensa em:

CLUSTERING
CARDINALITY
SELECTIVITY
INDEX ONLY
MATCHING COLUMNS
ACCESS PATH

Datomic organiza datoms em índices como:

EAVT
AEVT
AVET
VAET

Onde:

E = Entity
A = Attribute
V = Value
T = Transaction

Para um COBOLzeiro com VSAM no DNA, isso é surpreendentemente compreensível.

Você pergunta:

— Como chego ao dado?

Resposta:

— Escolha a ordenação adequada.

Não é VSAM.

Mas seu cérebro reconhece o cheiro de índice.

---

7. Buffer pool versus cache: dois mundos, mesma física

Agora entramos numa comparação deliciosa.

No Db2, buffer pools são críticos.

DISK
  ↓
BUFFERPOOL
  ↓
SQL

Quanto mais páginas úteis permanecem em memória:

menos I/O
mais performance

Você pensa em:

GETPAGE
HIT RATIO
PAGESET
BUFFER POOL SIZE
PREFETCH

No Datomic:

STORAGE
  ↓
CACHE
  ↓
PEER / COMPUTE
  ↓
QUERY

A diferença é que segmentos imutáveis são particularmente amigáveis a cache.

Se um pedaço histórico não muda, ele não sofre o mesmo problema clássico de invalidação.

House:

— Então descobriram que dados que não mudam são fáceis de cachear?

Foreman:

— Simplificando, sim.

— Nobel amanhã.

😂

Mas tecnicamente é uma vantagem real.

---

8. Working set: aqui os dois se encontram

Essa é uma das partes mais importantes.

Imagine:

DATABASE = 20 TB
WORKING SET = 10 GB

e você possui cache/memória suficiente.

Pode funcionar muito bem.

Agora:

DATABASE = 2 TB
WORKING SET = 1,5 TB

e sua memória útil é 64 GB.

Problema.

Isso vale tanto para arquiteturas relacionais quanto para Datomic.

O tamanho total do banco não é a única pergunta.

A pergunta é:

quanto do dado útil precisa estar quente ao mesmo tempo?

O velho DBA e o engenheiro Clojure podem brigar sobre filosofia.

A física ignora os dois.

---

9. CPU: Db2 e Datomic gastam por razões diferentes

Db2 usa CPU em:

SQL execution
sort
join
predicate evaluation
index access
locking
logging
utilities
compression

Datomic usa CPU em:

queries
Datalog
transaction processing
indexing
caching
application-side computation
GC

E aqui aparece uma diferença importante:

Datomic vive no ecossistema JVM.

Então:

GARBAGE COLLECTION

entra no prontuário.

O COBOLzeiro:

— Finalmente achei o tumor.

House:

— Não. Só um sintoma.

---

10. Transações: ambos levam ACID a sério

Db2:

BEGIN
UPDATE
INSERT
COMMIT

ou:

ROLLBACK

Transação é parte central da arquitetura.

Datomic também oferece transações ACID.

Mas sua coordenação de escrita é arquiteturalmente distinta.

No Datomic Pro clássico:

WRITES
  ↓
TRANSACTOR
  ↓
STORAGE

Leituras podem ser distribuídas através de peers.

Isso cria um trade-off interessante:

READ SCALE
↑

muito bem horizontalizado.

Mas writes possuem uma coordenação ordenada.

O veterano imediatamente pergunta:

qual é o throughput máximo de escrita por database?

Essa é uma pergunta correta.

---

11. Db2 escala diferente

Db2 historicamente escala de várias maneiras.

No mainframe:

Db2
  |
DATA SHARING
  |
Parallel Sysplex

Você pode ter múltiplos members compartilhando dados com locking e buffer management distribuído.

Além disso:

partitioning
parallelism
zIIP
buffer pools
workload management

A filosofia é muito mais:

um sistema transacional extremamente poderoso e coordenado.

Datomic tende mais a:

muitos databases/domínios, reads distribuídos, facts imutáveis e sharding arquitetural.

Nenhuma solução é “mais moderna” por definição.

São estratégias diferentes.

---

12. Escala: uma base monstruosa ou vários domínios?

No mundo tradicional, é natural encontrar:

PRODUCTION DB2
████████████████████████████████
muitos sistemas
muitas tabelas
muitos anos
████████████████████████████████

Datomic, especialmente em arquiteturas de microservices, incentiva uma decomposição maior:

SERVICE A → DATABASE A
SERVICE B → DATABASE B
SERVICE C → DATABASE C
SERVICE D → DATABASE D

Isso ajuda a explicar números como dezenas de milhares de databases em uma empresa como Nubank.

Mas traz outra complexidade:

distributed consistency
cross-service workflows
events
reconciliation
ownership
observability

House escreve no quadro:

MONOLITO:
complexidade interna

MICROSERVIÇOS:
complexidade distribuída

— Escolha onde quer sofrer.

---

13. Recovery: aqui o velho médico fica sério

Db2 possui uma história monumental de recuperação.

Você tem:

logs
image copies
RECOVER
REORG
RUNSTATS
utilities
PIT recovery
system-level backup
data sharing recovery

Décadas de prática.

Datomic também possui mecanismos de durabilidade, HA, backups e reconstrução, mas o ecossistema operacional é diferente e muito menor.

Se você perguntar:

“Quem conhece todos os detalhes de recuperação do Db2 em produção?”

há um mercado gigantesco de experiência.

Para Datomic:

o universo é muito menor.

Isso é risco.

Não necessariamente falha da tecnologia.

Mas risco de skills e tooling.

---

14. Operação: o que acontece às 03:17?

Essa talvez seja a diferença mais subestimada.

Db2 tem:

DBA
sysprog
vendor support
utilities
APARs
PTFs
Redbooks
manuals
decades of incidents

Datomic tem:

smaller community
Clojure expertise
specialized knowledge
fewer battle-tested operators

Hoje possui produção gigantesca em Nubank.

Mas não possui a mesma ubiquidade operacional.

House:

— O remédio novo pode ser excelente.

Wilson:

— Mas?

— Se ninguém no hospital sabe dosar, administrar ou tratar efeitos colaterais, isso também entra no diagnóstico.

Exatamente.

---

15. Skill gap versus obscuridade

Db2:

difícil achar bons especialistas?
sim

mas existem muitos.

Datomic:

especialistas?
existem

mercado?
pequeno

Agora coloque Clojure junto.

Seu pool de recrutamento diminui ainda mais.

Isso pode ser aceitável para uma empresa que constrói cultura própria, treina pessoas e domina a stack.

Pode ser um desastre para uma empresa que terceiriza tudo e troca consultoria a cada dois anos.

Essa é uma consideração organizacional, não apenas técnica.

---

16. Vendor lock-in: os dois têm, mas de formas diferentes

Db2:

IBM ecosystem
z/OS integration
utilities
features
licensing
skills

Se você explora profundamente recursos específicos, migrar pode ser caro.

Datomic:

Datomic model
Datalog
Clojure ecosystem
API model
temporal semantics

Também cria dependência.

A diferença é que no caso Datomic o ecossistema é menor.

Mas há uma peculiaridade histórica:

Nubank acabou adquirindo Cognitect.

Então:

usuário
  ↓
produto
  ↓
fabricante

vira

usuário + mantenedor

Isso reduz um risco para Nubank.

Não necessariamente para todos.

---

17. Histórico e auditoria: Datomic brilha

Se seu domínio vive perguntando:

qual era o estado?
quando mudou?
quem introduziu?
qual sequência produziu isso?

Datomic possui uma elegância impressionante.

Isso pode ser ouro em:

fraude
compliance
investigação
reprodução de estado
auditoria
reprocessamento

Db2 faz isso muito bem com ferramentas e recursos adequados.

Mas frequentemente você precisa arquitetar mais explicitamente:

temporal tables
audit columns
CDC
history tables
logs
triggers

Datomic coloca o tempo no centro.

Essa é provavelmente uma das maiores razões para escolhê-lo.

---

18. Mas histórico custa storage

Datomic preserva fatos.

Além disso, datoms aparecem em múltiplas ordenações de índice.

Então:

mais história
+
mais índices
=
mais storage

Pode haver compressão e atributos noHistory, mas a filosofia continua.

Db2 pode ser mais econômico se o requisito for apenas estado atual e histórico limitado.

Então:

Datomic

“O passado é precioso.”

Db2

“Diga quanto passado você quer e eu configuro.”

House:

— Um é historiador.

— E o outro?

— Contador.

---

19. Throughput de escrita: aqui Datomic exige respeito

Se seu sistema é:

READS >>> WRITES

Datomic pode se encaixar muito bem.

Se seu problema é:

WRITE FIREHOSE

você precisa medir cuidadosamente.

Porque a serialização transacional por database e background indexing criam limites naturais.

Se a taxa de entrada ultrapassa a capacidade de indexação:

MEMORY INDEX cresce
   ↓
back pressure
   ↓
write throughput reduz

Db2 também possui limites, obviamente.

Locks.

Log throughput.

I/O.

Latches.

Buffer contention.

Mas sua arquitetura e histórico de workloads OLTP de escrita extrema são muito conhecidos.

Para uma central bancária gigantesca, isso pesa.

---

20. Query analítica: nenhum dos dois substitui tudo

Datomic não deveria virar:

data lake
warehouse
log bucket
BI universal

Da mesma forma, Db2 OLTP não deveria necessariamente ser martelado com qualquer analytics gigantesco sem arquitetura adequada.

No mundo moderno:

SYSTEM OF RECORD
   ↓
CDC/EVENTS
   ↓
ANALYTICS PLATFORM

é frequentemente melhor.

House:

— Então não coloque tudo no mesmo banco?

— Exato.

— Finalmente uma ideia saudável.

---

21. Mainframe versus cloud: não confunda database com plataforma

Db2 pode existir em várias plataformas, mas para nosso universo Bellacosa, pense em Db2 for z/OS.

Aí você ganha:

IBM Z
z/OS
WLM
Sysplex
RACF
zIIP
SMF
RMF
CICS
IMS
MQ

O database vive dentro de uma infraestrutura extremamente integrada.

Datomic normalmente vive numa arquitetura distribuída/cloud-native:

AWS
compute
storage
DynamoDB/S3 em Datomic Cloud
Clojure
services
Kafka
Kubernetes

Então parte da comparação não é:

Datomic vs Db2

É:

ARQUITETURA DISTRIBUÍDA
vs
PLATAFORMA INTEGRADA

Isso muda custo, skills, observabilidade, DR e operação.

---

22. Segurança: Db2 herda um castelo

Db2 for z/OS vive num ambiente com:

RACF
SAF
audit
SMF
encryption
TLS
dataset protection
roles
privileges

É um ecossistema de segurança brutalmente maduro.

Datomic depende de sua arquitetura e da cloud:

IAM
network policies
KMS
secrets
AWS controls
application authorization

Ambos podem ser seguros.

Mas segurança no mainframe tende a ser altamente centralizada e conhecida.

No cloud-native, a superfície é mais distribuída.

Mais flexível.

E também mais fácil de configurar errado.

---

23. Observabilidade: SMF versus mundo distribuído

Db2:

SMF
RMF
IFCID
statistics
accounting traces
performance monitors

Você consegue investigar profundamente.

Datomic + microservices:

metrics
logs
traces
OpenTelemetry
application telemetry
AWS metrics
JVM metrics
GC metrics

O problema moderno é que uma transação pode atravessar dez serviços.

Então observability distribuída vira essencial.

O velho DBA olha para isso e diz:

— Vocês desmontaram o sistema e agora precisam descobrir onde cada pedaço está.

😂

É maldade.

Mas contém um pouco de verdade.

---

24. Latência: proximidade importa

Db2 for z/OS próximo de CICS:

CICS
 ↓
COBOL
 ↓
Db2

latência muito baixa e altamente previsível dentro da plataforma.

Datomic pode ganhar em leituras locais através de caches/peers.

Mas numa arquitetura cloud existem mais possibilidades de:

network hop
service hop
timeout
retry

Em compensação, você pode escalar serviços independentemente.

Trade-off.

Sempre trade-off.

---

25. Consistência distribuída: Datomic simplifica algumas coisas e complica outras

Dentro de um database Datomic, consistência é forte e transações são ordenadas.

Mas se você possui:

DB A
DB B
DB C

e um workflow precisa alterar todos:

agora você tem uma questão distribuída.

Pode usar:

events
sagas
reconciliation
idempotency

O velho mainframe pensa:

“Então vocês tiraram a complexidade do banco e colocaram na aplicação?”

Às vezes, sim.

Não por incompetência.

Por escolha arquitetural.

---

26. Db2 também não é mágico

Agora vamos bater no outro paciente.

Db2 pode virar:

monstro

com:

milhares de tabelas
milhares de índices
stored procedures
triggers
views
packages
utilities
bindings
access paths
partitions

E se ninguém cuida:

RUNSTATS velho
REBIND errado
buffer mal dimensionado
index demais
SQL ruim
locking
tablespace gigante

a criatura degrada.

House:

— Tecnologia madura não cura arquitetura ruim.

Exatamente.

---

27. Por que eu escolheria Db2?

Se eu tivesse:

core financeiro crítico
alto volume OLTP
equipe mainframe madura
CICS
COBOL
IMS/MQ
necessidade de SQL
forte integração z/OS
ferramentas robustas
auditoria consolidada

Db2 seria uma escolha extremamente natural.

Principalmente quando:

risk tolerance = LOW

e:

operational predictability = VERY HIGH

Você compra não apenas database.

Compra décadas de ecossistema.

---

28. Por que eu escolheria Datomic?

Se eu tivesse:

greenfield
Clojure
domínio temporal forte
histórico essencial
muitos reads
arquitetura distribuída
microservices
preciso reconstruir estados

Datomic poderia ser extremamente atraente.

Especialmente se minha organização estivesse disposta a dominar:

Clojure
Datalog
capacity model
sharding
observability
cloud operations

Ele pode reduzir complexidade em problemas históricos/temporais que seriam mais trabalhosos em bancos tradicionais.

---

29. O maior erro: escolher Datomic porque Nubank usa

House escreve:

NUBANK USES IT
≠
YOU SHOULD USE IT

Isso vale para qualquer tecnologia.

Netflix usa algo?

Legal.

Google usa algo?

Interessante.

Banco X usa algo?

Ótimo.

Pergunta:

seu problema é igual?

Provavelmente não.

Arquitetura de referência não é receita de bolo.

---

30. O segundo maior erro: escolher Db2 só porque “sempre usamos”

Agora House vira para o outro lado.

WE ALWAYS USED DB2
≠
DB2 IS BEST HERE

Se o sistema é novo, isolado, temporal, distribuído e possui requisitos diferentes, talvez Db2 seja exagero ou inadequado economicamente.

Legado pode ser estabilidade.

Mas também pode virar automatismo.

O bom arquiteto pergunta:

por que estamos escolhendo isso?

Não:

“qual tecnologia eu já conheço?”

---

31. Comparativo direto

Tema	Db2	Datomic
Modelo	Relacional	Fatos imutáveis
Query	SQL	Datalog
Atualização	UPDATE	assert/retract
Histórico	Recursos específicos/logs/temporal	Nativo ao modelo
Transações	ACID	ACID
Escritas	OLTP altamente maduro	Serializadas por database
Leituras	Muito escalável, inclusive Data Sharing	Peers/compute horizontais
Cache	Buffer pools	Segments/caches imutáveis
Índices	Definidos pelo schema/workload	EAVT/AEVT/AVET/VAET
Ecossistema	Gigantesco	Pequeno
Skills	Amplamente disponíveis	Nicho
Tooling	Extremamente maduro	Especializado
HA/DR	Décadas de soluções	Disponível, arquitetura diferente
Cloud fit	híbrido/múltiplas opções	forte
Mainframe fit	nativo em z/OS	não
Temporalidade	poderosa, mas configurada	central
Vendor risk	IBM	ecossistema Datomic/Nubank
Greenfield	depende	forte candidato
Core bancário legado	excelente fit	migração não trivial

---

32. Easter egg: House faz o teste do saldo

House escreve:

SALDO INICIAL = 1000

Depois:

COMPRA = 200

Pergunta:

— Db2?

UPDATE CONTA
SET SALDO = 800;

— Datomic?

assert novo saldo 800
retract saldo 1000

House:

— Qual está certo?

Foreman:

— Ambos.

— Finalmente.

Depois:

— Qual consegue dizer que o saldo foi 1000 antes?

Cameron:

— Ambos podem, se o Db2 estiver adequadamente configurado.

House sorri.

— Agora você está aprendendo.

---

33. O verdadeiro teste não é performance

É falha.

Pergunte:

O que acontece se:

• storage ficar lento?

• rede quebrar?

• processo morrer?

• região cloud falhar?

• transaction log encher?

• buffer pool degringolar?

• indexing atrasar?

• GC congelar?

• deploy inserir bug?

• schema mudar errado?

• restore falhar?

• DR não estiver testado?

Tecnologia não se prova em benchmark.

Prova-se:

quando o mundo fica feio.

---

34. O diagnóstico final de House

House olha para o quadro.

De um lado:

Db2

Do outro:

Datomic

Ele apaga a palavra:

VERSUS

e escreve:

FOR WHAT?

Porque esse é o diagnóstico.

Db2 não é “velho demais”.

Datomic não é “novo demais”.

Db2 traz:

maturidade
ecossistema
ferramentas
performance OLTP
integração z/OS
skills
previsibilidade

Datomic traz:

imutabilidade
tempo
fatos
histórico
read scaling
arquitetura funcional
modelagem diferente

São propostas distintas.

---

☕ Epílogo — O paciente sobrevive

São 03h42.

Produção liga.

Foreman atende.

— Temos problema.

House:

— Db2?

— Não.

— Datomic?

— Também não.

— Então?

— A aplicação cobrou o cliente duas vezes.

House olha para o time.

— Infrastructure?

— Tudo verde.

— Database?

— Consistente.

— Logs?

— Perfeitos.

— Então quem errou?

Silêncio.

House aponta para o quadro:

APPLICATION LOGIC

— Everybody lies.

Incluindo código.

O COBOLzeiro no canto toma café.

Porque essa é a verdade que atravessa VSAM, IMS, Adabas, Db2, Datomic, Oracle, PostgreSQL e qualquer banco que ainda inventaremos:

um database pode armazenar perfeitamente a coisa errada.

No final, a pergunta nunca foi:

“Qual database é melhor?”

É:

“Qual arquitetura torna mais difícil errar, mais fácil detectar quando erramos e mais seguro recuperar quando inevitavelmente errarmos?”

Para um core bancário tradicional fortemente integrado ao IBM Z, com décadas de lógica COBOL/CICS e requisitos de altíssimo throughput transacional, Db2 continua sendo uma escolha absurdamente forte.

Para um sistema greenfield, distribuído, fortemente temporal, Clojure-native, com histórico e reconstrução de estado no centro do problema, Datomic pode oferecer uma elegância que o modelo relacional não entrega da mesma maneira sem bastante engenharia adicional.

Mas se alguém entrar na reunião dizendo:

“Vamos usar Datomic porque Nubank usa.”

House deveria expulsá-lo.

E se outro disser:

“Vamos usar Db2 porque sempre usamos.”

House também.

Depois perguntaria:

QUAL É O PROBLEMA?

Só então escolheria o tratamento.

Porque banco de dados, assim como medicina, não é sobre preferência pessoal.

É sobre diagnóstico correto, efeitos colaterais conhecidos e o paciente continuar vivo depois do deploy.

☕ Fim do café.