Simplesmente use Postgres

• A maioria das aplicações web precisa de armazenamento persistente de dados, então, ao criar uma nova aplicação, é melhor escolher Postgres como padrão

Por que não sqlite?

• sqlite é um bom banco de dados, mas os dados ficam armazenados em um único arquivo
• Isso significa que a aplicação roda em apenas um único dispositivo
• É adequado para apps desktop ou mobile, mas pode não ser adequado para sites
  • Existem casos de sucesso usando sqlite em sites, mas em geral são casos em que a própria equipe construiu seus próprios servidores e infraestrutura
• Você pode acabar abrindo mão de backups automáticos do banco de dados oferecidos pela plataforma e da possibilidade de configurar vários servidores de aplicação

Por que não DynamoDB, Cassandra ou MongoDB?

• Esses bancos de dados entregam excelente desempenho, mas vêm com muitas premissas:
  • Você precisa saber exatamente o que a aplicação precisa fazer e quais serão os padrões de acesso
  • Quando há necessidade de escalar para um volume de dados muito grande
  • Quando é possível abrir mão de parte da consistência
• Esses bancos de dados funcionam de forma parecida com mapas de hash distribuídos, então é preciso refletir no modo de armazenamento dos dados o conhecimento sobre os padrões de consulta
• Se o padrão de acesso (consulta) mudar, talvez seja necessário reprocessar todos os dados
• Bancos de dados relacionais permitem adicionar índices com facilidade para executar consultas, mas isso é mais difícil em bancos NoSQL
• Não são adequados para consultas analíticas
• Se um universitário ou desenvolvedor júnior estiver usando MongoDB, provavelmente vai precisar de ajuda

Por que não Valkey?

• Esse banco de dados, conhecido como Redis, é muito famoso como um cache extremamente eficiente
• Ele pode ser usado como banco de dados principal, mas há problemas:
  • Armazena todos os dados em RAM, então é rápido, mas a capacidade de RAM é limitada
  • Exige concessões na modelagem dos dados

Por que não Datomic?

• Se você já conhece isso, ganha uma "estrela dourada"
• Datomic é um banco de dados NoSQL relacional que não sofre com o problema de "design antecipado (Up-front Design)" e tem algumas propriedades elegantes
  • Armazena dados como pares EAVT (entidade-atributo-valor-tempo) em vez de tabelas, e usa índices genéricos
  • Não é preciso se coordenar com o autor ao escrever consultas. Basta consultar o banco de dados no "momento atual" em um dado instante. Novos dados, e até exclusões (ou "retractions", revogações), não apagam de fato os dados anteriores
• Mas há algumas desvantagens:
  • Funciona apenas em linguagens da JVM
  • A API não é boa em linguagens que não sejam Clojure
  • As mensagens de erro causadas por consultas mal estruturadas são muito pouco amigáveis
  • Faltam ferramentas, já que não existe algo como o ecossistema de ferramentas de SQL

Por que não XTDB?

• Usuários de Clojure criam muitos bancos de dados
• É parecido com Datomic, mas tem as seguintes características:
  • Fornece uma API HTTP, então não fica preso à JVM
  • Permite consultas em dois eixos: "tempo do sistema" e "tempo de validade"
  • Suporta API SQL
• Mas o maior problema é que ainda é "novo demais". A API SQL saiu no ano passado, e recentemente todo o modelo de armazenamento foi alterado
  • Será que ainda vai existir daqui a 10 anos? O suporte de longo prazo é incerto

Por que não Kafka?

• Kafka é um log "append-only" excelente, adequado para processar dados em escala de TB
• Funciona incrivelmente bem quando você quer fazer trabalhos do tipo event sourcing com dados que chegam de vários serviços administrados por várias equipes
• Porém
  • Em pequena escala, uma tabela no Postgres já substitui isso muito bem
  • Criar consumidores de Kafka é mais sujeito a erros do que parece. No fim, você precisa rastrear sua própria posição no log
  • É preciso gerenciar infraestrutura adicional

Por que não ElasticSearch?

• Se a busca de dados é a principal funcionalidade do produto, ElasticSearch é uma boa escolha
  • Você precisa fazer ETL dos dados e gerenciar todo o processo, mas ElasticSearch foi feito para busca e faz isso bem
• Mas, se busca não for a funcionalidade principal, os recursos nativos de busca textual do Postgres já bastam
  • Depois, você pode adicionar um mecanismo de busca dedicado

Por que não MSSQL ou Oracle DB?

• A verdadeira pergunta a se fazer é: "vale o que custa?"
• É preciso considerar não só o custo de licença, mas também o custo de lock-in
• Se você armazenar seus dados na Oracle, vai pagar para a Oracle para sempre e terá de continuar treinando desenvolvedores
  • Você terá de escolher para sempre entre recursos enterprise e o seu bolso
• A menos que você realmente precise de um recurso específico, é melhor evitar
  • Não use a menos que exista algum recurso matador sem o qual você não possa viver no MSSQL

Por que não MySQL?

• Esta parte precisa de uma ajudinha do leitor
• MySQL pertence à Oracle, e alguns recursos ficam trancados na edição enterprise
  • Claro, MySQL é usado há muito tempo e existe uma edição gratuita amplamente utilizada
• Eu acredito que Postgres seja a melhor escolha, mas preciso de mais informações adicionais sobre MySQL

Por que não banco de dados vetorial de IA?

• A maioria dos bancos de dados vetoriais de IA é tecnologia nascente, e usá-los traz riscos
  • Negócios baseados na bolha de IA devem ser tratados com cautela
• Mesmo que o seu negócio seja só mais um grift (golpe) de IA, um simples import openai provavelmente já resolve

Por que não Google Sheets?

• Não há nenhuma desvantagem especial; se precisar, pode usar

[hilft]

Firestore...

[wedding]

Artigos que afirmam isso de forma tão categórica geralmente refletem erros que juniores cometem..

[nemorize]

Em vez disso, vou te dar
um CV
afetuoso
como presente
.

[roxie]

zzz

[bus710]

Isso meio que me faz lembrar daquela piada de “pra conseguir boas informações, provoque a galera”... haha
De qualquer forma, como a maioria dos desenvolvedores backend acaba usando postgresql primeiro...

[dicebattle]

Acho que o Postgres é a melhor escolha, mas preciso de mais informações sobre o MySQL

kkkk;;;;

[koxel]

O verdadeiro problema do MySQL Enterprise nem é a licença, e sim que até para quem paga, o suporte é realmente uma merda quando acontece alguma pane.
Antes, quando um índice do MySQL corrompeu e ele nem iniciava, mesmo abrindo chamado de suporte, tudo que a Oracle fez foi dizer que, se abríssemos um ticket, eles dariam suporte por telefone.
No fim, como o cliente disse que daquele jeito não dava, nós mesmos tivemos que resolver.
Melhor o gratuito do que confiar na Oracle e usar Enterprise..

[kaydash]

Por que não mariadb, impala, hive ou kudu?

[koxel]

Os recursos enterprise do MySQL são coisas não tão necessárias, como um pool de conexões próprio...
Se for enterprise de verdade, em vez de usar isso, instalar um SQL proxy na frente é mais eficaz para distribuir a carga.
Gosto de PgSQL, mas falar isso sem nem pesquisar sobre MySQL... hahaha

[iolothebard]

Simplesmente use MySQL…

• Por que não PostgreSQL? Nesta parte, preciso de um pouco de ajuda.

[love7peace]

E o MariaDB??

[aer0700]

Um post que certamente vai gerar muita discussão...

[aer0700]

O motivo para usar SQLite é simples: ele simplesmente funciona bem na maioria dos casos, mesmo em uma certa escala.
Basta implementar primeiro com SQLite e, se necessário depois, migrar para Postgres sem grande dificuldade.

[xguru]

De tempos em tempos aparece mais um texto exaltando o Postgres. Agora é só curtir!

Simplesmente use Postgres para tudo
PostgreSQL é suficiente
Desde quando o Postgres ficou tão legal?

[GN⁺]

Opinião do Hacker News

• Há muitas opiniões negativas sobre o MongoDB, mas a maioria está errada

  • O MongoDB se encaixa bem na fase inicial
  • Funciona sem problemas mesmo quando o volume de dados cresce
  • Os problemas de consistência também são bem resolvidos
  • O MongoDB não é um mapa de hash distribuído como o Dynamo
  • Muita gente não conhece bem os recursos de agregação do MongoDB
  • Dizer para não usar MongoDB só porque desenvolvedores iniciantes precisam aprender SQL é injusto

• Vantagens do SQLite

  • Como é baseado em arquivo, é fácil fazer backup
  • Se usar ORM, dá para migrar facilmente do SQLite para o Postgres

• Apontar falhas técnicas não tem muito sentido

  • Rick Houlihan, do MongoDB, atualmente trabalha no MongoDB

• Motivos para migrar do MySQL para o Postgres

  • O MySQL, por ser da Oracle, traz risco de negócio
  • O Postgres tem mais ferramentas para manter a consistência dos dados
  • Os recursos de extensão do Postgres economizam tempo de desenvolvimento
  • O ecossistema de ferramentas do Postgres é mais maduro e completo

• O suporte do Postgres a tabelas temporais é insuficiente

  • É necessário versionamento temporal duplo de SQL:2011 com tempo do sistema e tempo da aplicação
  • Em setores regulados com exigências complexas de relatórios, tabelas temporais são ideais

• Não entende por que usar SQLite

  • Instalar o Postgres não é difícil
  • É preciso explicar a diferença entre SQLite e Postgres

• Pedido de desculpas por ter mencionado errado o nome de Rick Houlihan

  • A comparação entre DynamoDB/Cassandra e MongoDB veio de uma palestra dele
  • O MongoDB é um banco de dados que armazena informações desnormalizadas e não é flexível a mudanças no padrão de acesso

• É importante usar o que se conhece e colocar em produção o que for útil

• MySQL é como JavaScript

  • Tem muitas decisões ruins e fatores de risco
  • Funciona bem, mas não há motivo para usá-lo quando o Postgres existe

[touguy]

O Postgres tem mais ferramentas para manter a consistência dos dados
=> Talvez você tenha algum exemplo?

[leftliber]

Uma desvantagem do SQLite em relação ao Postgres é que ele não oferece suporte a schema. Quando o número de tabelas passa de várias dezenas, fica mais organizado separá-las por schema no design, mas como o SQLite não permite isso, acaba sendo necessário colocar toda a distinção no nome das tabelas.