7 bancos de dados para 2025

xguru · 2024-12-09T09:56:01+09:00

Apresentação de 7 bancos de dados que valem a atenção para resolver diferentes tipos de problemas Esta não é uma lista dos “melhores DBs”, mas de ferramentas que oferecem perspectivas novas e úteis Em 2025, vale a pena investir uma semana em cada um deles (7 DBs in 7 Weeks) 1. PostgreSQL: o banco de dados padrão PostgreSQL é uma tecnologia estável usada como padrão A frase “Just use Postgres” é um meme amplamente conhecido e uma expressão de confiança Segue ACID e oferece recursos robustos, incluindo replicação física e lógica É um banco de dados estável com amplo suporte entre os principais fornecedores O maior atrativo do PostgreSQL: extensibilidade É possível adicionar funcionalidades originais por meio de extensões Exemplos de extensões importantes: AGE: suporte a estruturas de dados em grafo e à linguagem de consulta Cypher TimescaleDB: suporte para trabalhar com dados de séries temporais Hydra Columnar: fornece um mecanismo de armazenamento colunar As extensões são o elemento central que diferencia o PostgreSQL de outros bancos de dados Utilidade e escalabilidade do PostgreSQL Possui um ecossistema variado, com configurações padrão razoáveis e amigáveis ao usuário Até serviços que não são PostgreSQL oferecem compatibilidade com clientes usando o protocolo wire do Postgres É leve o suficiente para ser instalado até em ambientes WebAssembly (Wasm) Recomendação de aprendizado do PostgreSQL Vale a pena investir tempo para entender as possibilidades e os limites do PostgreSQL Ex.: compreender a complexidade do MVCC (Multi-Version Concurrency Control) Recomenda-se desenvolver uma aplicação CRUD simples e até escrever extensões para PostgreSQL 2. SQLite: banco de dados local-first SQLite é um banco de dados “local-first” que pode rodar de forma independente Sai do modelo cliente-servidor e roda no mesmo ambiente da aplicação Exemplo: WhatsApp e Signal usam SQLite dentro do dispositivo para armazenar os dados de chat Casos de uso mais avançados do SQLite Permite usos criativos para além de um banco de dados básico compatível com ACID Novas ferramentas e extensões: Litestream: fornece backup em streaming para SQLite LiteFS: oferece acesso distribuído para implementar topologias mais flexíveis CR-SQLite: usa CRDTs (Conflict-free Replicated Data Types) para eliminar a necessidade de resolver conflitos ao mesclar conjuntos de alterações Renovado destaque do SQLite Está voltando ao centro das atenções graças ao Ruby on Rails 8.0 37signals: desenvolve módulos do Rails baseados em SQLite (como Solid Queue) Suporte do Rails para gerenciar múltiplos bancos SQLite (database.yml) Bluesky: usa um banco SQLite separado por usuário como Personal Data Server Recomendação de aprendizado com SQLite Experimentar arquiteturas centradas no local usando SQLite Tentar substituir o modelo cliente-servidor tradicional baseado em PostgreSQL por SQLite 3. DuckDB: o banco de dados que consulta tudo DuckDB é um banco de dados embarcado especializado em OLAP Assim como o SQLite, funciona junto com a aplicação, mas foca em OLAP em vez de OLTP É um sistema projetado para análise e consultas sobre dados A característica “Query-Anything” do DuckDB Permite consultar diretamente via SQL diversas fontes de dados: formatos de arquivo comuns como CSV, TSV e JSON suporte a formatos avançados como Parquet Esse recurso oferece grande flexibilidade, por exemplo na análise do fluxo de dados do Bluesky Extensibilidade e ecossistema O DuckDB também tem extensões, embora não tão ricas quanto as do Postgres (é um projeto relativamente mais novo) Há muitas extensões criadas pela comunidade, e gsheets (integração com Google Sheets) merece destaque Recomendação de aprendizado com DuckDB Experimentar análise e processamento de dados com notebooks Python ou com o Evidence Combinar com SQLite: delegar consultas analíticas sobre um banco SQLite ao DuckDB para melhorar o desempenho 4. ClickHouse: banco de dados colunar ClickHouse é um banco de dados especializado em cargas OLAP A combinação ideal é PostgreSQL para OLTP e ClickHouse para OLAP Lida com workloads analíticos em grande escala e suporta alta velocidade de inserção por meio de escalabilidade horizontal e sharding Principais características do ClickHouse Suporte a armazenamento em camadas: permite separar e armazenar “dados quentes” e “dados frios” Ex.: a documentação do GitLab detalha um caso de uso dessa abordagem Processamento de grandes conjuntos de dados e análise em tempo real: adequado para datasets grandes demais para o DuckDB lidar com facilidade oferece desempenho forte em cenários que exigem análise em tempo real Facilidade operacional A documentação sobre implantação, expansão, backup e operação em geral é organizada e detalhada Ex.: há documentação até sobre como definir a configuração adequada de CPU Recomendação de aprendizado com ClickHouse Experimentar com grandes datasets analíticos ou converter para ClickHouse análises já feitas com DuckDB Usar a versão embarcada do ClickHouse, chDB, para compará-lo mais diretamente com o SQLite 5. FoundationDB: banco de dados em camadas FoundationDB é um sistema único que serve como “fundação de banco de dados” Foi projetado como um armazenamento chave-valor, mas funciona menos como um banco simples e mais como uma “base” para construir bancos de dados É usado por grandes empresas como Apple, Snowflake e Tigris Data Principais características e limitações Restrições: os dados de uma transação não podem ultrapassar 10MB uma transação não pode ultrapassar 5 segundos após a primeira leitura Essas restrições permitem oferecer transações ACID completas mesmo em ambientes de grande escala Ex.: há casos de operação de clusters com mais de 100TiB Projeto e testes do FoundationDB Foi projetado com foco em workloads específicos Testes de simulação comprovam sua estabilidade e escalabilidade: A mesma metodologia de testes é usada também pela Antithesis e por outros bancos de dados Materiais relacionados: documentos de Tyler Neely e Phil Eaton FoundationDB como banco de dados “em camadas” O acoplamento entre mecanismo de armazenamento e modelo de dados é frouxo: é possível remapear o mecanismo de armazenamento em diferentes camadas Ex.: camada Record e camada Document (fornecidas pela organização FoundationDB) Vale a pena consultar o caso de projeto de camadas escrito pela Tigris Data Recomendação de aprendizado com FoundationDB Fazer os tutoriais e explorar o potencial de substituir sistemas como RocksDB Ler os Design Recipes e artigos relacionados Entender as limitações de uso e os problemas que ele resolve por meio dos documentos Anti-Features e Features 6. TigerBeetle: um banco de dados obcecado por exatidão TigerBeetle é um banco de dados de propósito único especializado em transações financeiras Diferentemente de bancos de dados de uso geral, foca em um objetivo específico, especialmente transações financeiras É open source e foi projetado com a meta de alcançar altíssimo nível de confiabilidade e precisão Filosofia de projeto voltada à exatidão extrema Implementa as Power of Ten Rules da NASA e Protocol-Aware Recovery Usa strict serialisability e Direct I/O para evitar problemas relacionados ao page cache do kernel Dá para perceber esse rigor na documentação de segurança (Safety doc) e no estilo de programação peculiar chamado “Tiger Style” Abordagem inovadora implementada em Zig Zig é uma linguagem de programação de sistemas relativamente nova, mas ideal para os objetivos do TigerBeetle Suas vantagens são aproveitadas para maximizar simplicidade e desempenho Sugestões de aprendizado e uso do TigerBeetle Experimentar a modelagem de contas financeiras em um ambiente de implantação local: instalar e usar seguindo o Quick Start Consultar a documentação de arquitetura do sistema (System Architecture docs) para explorar possibilidades de combinação com bancos de uso geral Ex.: ampliar casos de uso integrando-o com PostgreSQL ou FoundationDB 7. CockroachDB: banco de dados global CockroachDB é um banco de dados distribuído global É compatível com o protocolo wire do PostgreSQL, suporta escalabilidade horizontal e forte consistência Seu projeto, inspirado no Google Spanner, permite expandir o banco de dados entre múltiplas regiões Principais características técnicas do CockroachDB Tecnologia de sincronização de tempo: O Google Spanner usa relógios atômicos e GPS, mas o CockroachDB foi projetado para funcionar também em hardware comum Compensação de atraso de sincronização baseada em NTP, comparação de clock drift entre nós e encerramento de membros ao exceder o deslocamento máximo Configuração multirregional: o recurso Table Localities permite otimização conforme os trade-offs de leitura/escrita os dados são distribuídos de acordo com a localização geográfica dos usuários, melhorando desempenho e latência Sugestões de aprendizado com CockroachDB Reimplementar o exemplo MovR: implementar o MovR (exemplo de aplicação distribuída) usando a linguagem e o framework de sua preferência Experimentar o design de aplicações globais aproveitando as estratégias multirregionais e de escalabilidade do CockroachDB Por que escolher o CockroachDB Diferentemente de outros bancos distribuídos como o DynamoDB, ele pode rodar gratuitamente em ambiente local Oferece como diferencial forte consistência e suporte à distribuição global Conclusão Os bancos de dados apresentados foram projetados para resolver problemas e necessidades diferentes Em 2025, explore essas tecnologias para descobrir formas mais interessantes e criativas de resolver problemas!

(matt.blwt.io)

53 pontos por xguru 2024-12-09 | 14 comentários | Compartilhar no WhatsApp

Apresentação de 7 bancos de dados que valem a atenção para resolver diferentes tipos de problemas
Esta não é uma lista dos “melhores DBs”, mas de ferramentas que oferecem perspectivas novas e úteis
Em 2025, vale a pena investir uma semana em cada um deles (7 DBs in 7 Weeks)

1. PostgreSQL: o banco de dados padrão

PostgreSQL é uma tecnologia estável usada como padrão
- A frase “Just use Postgres” é um meme amplamente conhecido e uma expressão de confiança
- Segue ACID e oferece recursos robustos, incluindo replicação física e lógica
- É um banco de dados estável com amplo suporte entre os principais fornecedores
O maior atrativo do PostgreSQL: extensibilidade
- É possível adicionar funcionalidades originais por meio de extensões
- Exemplos de extensões importantes:
  - AGE: suporte a estruturas de dados em grafo e à linguagem de consulta Cypher
  - TimescaleDB: suporte para trabalhar com dados de séries temporais
  - Hydra Columnar: fornece um mecanismo de armazenamento colunar
- As extensões são o elemento central que diferencia o PostgreSQL de outros bancos de dados
Utilidade e escalabilidade do PostgreSQL
- Possui um ecossistema variado, com configurações padrão razoáveis e amigáveis ao usuário
- Até serviços que não são PostgreSQL oferecem compatibilidade com clientes usando o protocolo wire do Postgres
- É leve o suficiente para ser instalado até em ambientes WebAssembly (Wasm)
Recomendação de aprendizado do PostgreSQL
- Vale a pena investir tempo para entender as possibilidades e os limites do PostgreSQL
- Ex.: compreender a complexidade do MVCC (Multi-Version Concurrency Control)
- Recomenda-se desenvolver uma aplicação CRUD simples e até escrever extensões para PostgreSQL

2. SQLite: banco de dados local-first

SQLite é um banco de dados “local-first” que pode rodar de forma independente
- Sai do modelo cliente-servidor e roda no mesmo ambiente da aplicação
- Exemplo: WhatsApp e Signal usam SQLite dentro do dispositivo para armazenar os dados de chat
Casos de uso mais avançados do SQLite
- Permite usos criativos para além de um banco de dados básico compatível com ACID
- Novas ferramentas e extensões:
  - Litestream: fornece backup em streaming para SQLite
  - LiteFS: oferece acesso distribuído para implementar topologias mais flexíveis
  - CR-SQLite: usa CRDTs (Conflict-free Replicated Data Types) para eliminar a necessidade de resolver conflitos ao mesclar conjuntos de alterações
Renovado destaque do SQLite
- Está voltando ao centro das atenções graças ao Ruby on Rails 8.0
- 37signals: desenvolve módulos do Rails baseados em SQLite (como Solid Queue)
  - Suporte do Rails para gerenciar múltiplos bancos SQLite (database.yml)
- Bluesky: usa um banco SQLite separado por usuário como Personal Data Server
Recomendação de aprendizado com SQLite
- Experimentar arquiteturas centradas no local usando SQLite
- Tentar substituir o modelo cliente-servidor tradicional baseado em PostgreSQL por SQLite

3. DuckDB: o banco de dados que consulta tudo

DuckDB é um banco de dados embarcado especializado em OLAP
- Assim como o SQLite, funciona junto com a aplicação, mas foca em OLAP em vez de OLTP
- É um sistema projetado para análise e consultas sobre dados
A característica “Query-Anything” do DuckDB
- Permite consultar diretamente via SQL diversas fontes de dados:
  - formatos de arquivo comuns como CSV, TSV e JSON
  - suporte a formatos avançados como Parquet
- Esse recurso oferece grande flexibilidade, por exemplo na análise do fluxo de dados do Bluesky
Extensibilidade e ecossistema
- O DuckDB também tem extensões, embora não tão ricas quanto as do Postgres (é um projeto relativamente mais novo)
- Há muitas extensões criadas pela comunidade, e gsheets (integração com Google Sheets) merece destaque
Recomendação de aprendizado com DuckDB
- Experimentar análise e processamento de dados com notebooks Python ou com o Evidence
- Combinar com SQLite: delegar consultas analíticas sobre um banco SQLite ao DuckDB para melhorar o desempenho

4. ClickHouse: banco de dados colunar

ClickHouse é um banco de dados especializado em cargas OLAP
- A combinação ideal é PostgreSQL para OLTP e ClickHouse para OLAP
- Lida com workloads analíticos em grande escala e suporta alta velocidade de inserção por meio de escalabilidade horizontal e sharding
Principais características do ClickHouse
- Suporte a armazenamento em camadas:
  - permite separar e armazenar “dados quentes” e “dados frios”
  - Ex.: a documentação do GitLab detalha um caso de uso dessa abordagem
- Processamento de grandes conjuntos de dados e análise em tempo real:
  - adequado para datasets grandes demais para o DuckDB lidar com facilidade
  - oferece desempenho forte em cenários que exigem análise em tempo real
Facilidade operacional
- A documentação sobre implantação, expansão, backup e operação em geral é organizada e detalhada
- Ex.: há documentação até sobre como definir a configuração adequada de CPU
Recomendação de aprendizado com ClickHouse
- Experimentar com grandes datasets analíticos ou converter para ClickHouse análises já feitas com DuckDB
- Usar a versão embarcada do ClickHouse, chDB, para compará-lo mais diretamente com o SQLite

5. FoundationDB: banco de dados em camadas

FoundationDB é um sistema único que serve como “fundação de banco de dados”
- Foi projetado como um armazenamento chave-valor, mas funciona menos como um banco simples e mais como uma “base” para construir bancos de dados
- É usado por grandes empresas como Apple, Snowflake e Tigris Data
Principais características e limitações
- Restrições:
  - os dados de uma transação não podem ultrapassar 10MB
  - uma transação não pode ultrapassar 5 segundos após a primeira leitura
- Essas restrições permitem oferecer transações ACID completas mesmo em ambientes de grande escala
  - Ex.: há casos de operação de clusters com mais de 100TiB
Projeto e testes do FoundationDB
- Foi projetado com foco em workloads específicos
- Testes de simulação comprovam sua estabilidade e escalabilidade:
  - A mesma metodologia de testes é usada também pela Antithesis e por outros bancos de dados
  - Materiais relacionados: documentos de Tyler Neely e Phil Eaton
FoundationDB como banco de dados “em camadas”
- O acoplamento entre mecanismo de armazenamento e modelo de dados é frouxo:
  - é possível remapear o mecanismo de armazenamento em diferentes camadas
  - Ex.: camada Record e camada Document (fornecidas pela organização FoundationDB)
- Vale a pena consultar o caso de projeto de camadas escrito pela Tigris Data
Recomendação de aprendizado com FoundationDB
- Fazer os tutoriais e explorar o potencial de substituir sistemas como RocksDB
- Ler os Design Recipes e artigos relacionados
- Entender as limitações de uso e os problemas que ele resolve por meio dos documentos Anti-Features e Features

6. TigerBeetle: um banco de dados obcecado por exatidão

TigerBeetle é um banco de dados de propósito único especializado em transações financeiras
- Diferentemente de bancos de dados de uso geral, foca em um objetivo específico, especialmente transações financeiras
- É open source e foi projetado com a meta de alcançar altíssimo nível de confiabilidade e precisão
Filosofia de projeto voltada à exatidão extrema
- Implementa as Power of Ten Rules da NASA e Protocol-Aware Recovery
- Usa strict serialisability e Direct I/O para evitar problemas relacionados ao page cache do kernel
- Dá para perceber esse rigor na documentação de segurança (Safety doc) e no estilo de programação peculiar chamado “Tiger Style”
Abordagem inovadora implementada em Zig
- Zig é uma linguagem de programação de sistemas relativamente nova, mas ideal para os objetivos do TigerBeetle
- Suas vantagens são aproveitadas para maximizar simplicidade e desempenho
Sugestões de aprendizado e uso do TigerBeetle
- Experimentar a modelagem de contas financeiras em um ambiente de implantação local:
  - instalar e usar seguindo o Quick Start
- Consultar a documentação de arquitetura do sistema (System Architecture docs) para explorar possibilidades de combinação com bancos de uso geral
- Ex.: ampliar casos de uso integrando-o com PostgreSQL ou FoundationDB

7. CockroachDB: banco de dados global

CockroachDB é um banco de dados distribuído global
- É compatível com o protocolo wire do PostgreSQL, suporta escalabilidade horizontal e forte consistência
- Seu projeto, inspirado no Google Spanner, permite expandir o banco de dados entre múltiplas regiões
Principais características técnicas do CockroachDB
- Tecnologia de sincronização de tempo:
  - O Google Spanner usa relógios atômicos e GPS, mas o CockroachDB foi projetado para funcionar também em hardware comum
  - Compensação de atraso de sincronização baseada em NTP, comparação de clock drift entre nós e encerramento de membros ao exceder o deslocamento máximo
- Configuração multirregional:
  - o recurso Table Localities permite otimização conforme os trade-offs de leitura/escrita
  - os dados são distribuídos de acordo com a localização geográfica dos usuários, melhorando desempenho e latência
Sugestões de aprendizado com CockroachDB
- Reimplementar o exemplo MovR:
  - implementar o MovR (exemplo de aplicação distribuída) usando a linguagem e o framework de sua preferência
- Experimentar o design de aplicações globais aproveitando as estratégias multirregionais e de escalabilidade do CockroachDB
Por que escolher o CockroachDB
- Diferentemente de outros bancos distribuídos como o DynamoDB, ele pode rodar gratuitamente em ambiente local
- Oferece como diferencial forte consistência e suporte à distribuição global

Conclusão

Os bancos de dados apresentados foram projetados para resolver problemas e necessidades diferentes
Em 2025, explore essas tecnologias para descobrir formas mais interessantes e criativas de resolver problemas!

14 comentários

wfedev 2025-11-28

Consulte qualquer coisa! 😆🐤

budaestew 2024-12-16

Fiquei surpreso com o quão excelente é o desempenho analítico do DuckDB.

halfenif 2024-12-09

Há alguns meses venho trabalhando com sqlite. Por data. Estou executando um trabalho que processa cerca de 2 milhões de registros, em um volume de dados na faixa de 5 GB.

A velocidade de processamento é satisfatória... mas está demorando demais para pegar esse material, processá-lo novamente e transformá-lo em Excel para fornecer às partes interessadas.

Acho que vou precisar pesquisar um pouco mais a abordagem de usar OpenPyXl.

kimjj81 2024-12-18

Não sei que tipo de mágica tem nisso, mas parece que estão usando a combinação duckDB + sqlite.

channprj 2024-12-09

Surpreendentemente, o MongoDB não foi mencionado.

felizgeek 2024-12-09

Se você estiver em um ambiente em que a curva de aprendizado dos desenvolvedores seja uma preocupação, recomendo o SQLite. Como ele é baseado em arquivos, é fácil.

savvykang 2024-12-09

Se ficar claro que não há necessidade de acesso remoto, é uma solução realmente muito satisfatória. Elimina os pontos de administração do DB, e a edição de dados, backup e recuperação também ficam simples, o que é ótimo.

aer0700 2024-12-09

Se você disser que vai usar SQLite, é fácil levar bronca, mas antes de contar que usou SQLite, ninguém percebe também... SQLite é melhor do que parece.

jpumpkin94 2024-12-09

Já faz dezenas de anos(??) que uso só MySQL,
Tenho curiosidade sobre o PostgreSQL e espero muitos comentários de quem usa PostgreSQL em produção no dia a dia.

zuppiy 2024-12-09

"Os elefantes são superiores às focas"
Isso é verdade na maioria das situações

roxie 2024-12-11

kkkk

kibae 2024-12-09

Em 2001, migrei do mysql cheio de bugs (na época, v3.x) para o pgsql.
Acho que há muitos pontos em que ele é superior, mas... na prática, acredito que a existência de Partial Index seja o recurso mais poderoso.

chanhee 2024-12-09

Por causa do trabalho na empresa, eu só usava Oracle e Sqlserver, então quando tentei usar MySQL havia coisas demais que me faziam pensar de verdade: "por que isso não funciona?". Eu também não me lembro exatamente do que era.
No fim, acabei migrando para o Postgres.

bbulbum 2024-12-09

Ao sair de um lugar que usava Postgres e vir para um lugar que usa MySQL, há várias coisas que me fazem pensar, pela sensação, “por que isso não funciona?” “por que isso não tem esse desempenho?”.
Não me lembro bem exatamente o que era (pode ser algo trivial ou não).