 |
| 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é.
