Porque a primeira escolha é SEMPRE utilizar SQL

SIM, VOCÊ TÁ VIAJANDO — E VOU TE CONTAR PORQUÊ.

SQL não é "chato" — é PODER. E quando você entende isso, percebe que 99% dos projetos nunca precisarão de outra coisa. A não ser que você seja o próximo Google ou Amazon,. Spoiler: nunca sera.

SQL é PURAMENTE DECLARATIVO. Você não "trabalha" pra definir esquemas, você DECLARA o que quer, e o banco faz todo o trabalho pesado. Isso é o oposto de "trabalhoso". Enquanto você tem gente gritando que "NoSQL é mais fácil", outros estão calados escrevendo JOIN, GROUP BY, WINDOW FUNCTION e fazendo os dados dançarem conforme o programa, e não o contrário. 💥

Nada existe num vácuo. O que NoSQL resolve?

Essa ideia de que "no começo não preciso de relações complexas" é uma armadilha. Mesmo que você não veja as relações explicitamente no início, elas sempre existem. Um pedido tem um cliente. Um produto tem uma categoria. Um tweet tem um autor. Até seu JSONzinho "desestruturado" no MongoDB tem relações implícitas — você só tá varrendo a sujeira pra debaixo do tapete e chamando de "flexibilidade". Tudo, absolutamente tudo, é relacional.

MAS ESPERA, TEM MAIS. Você já ouviu falar do JSONB do PostgreSQL? É o seguinte: você tem TODA a "liberdade" do "NoSQL", mas com indexação, consultas complexas, e a capacidade de, pasme, RELACIONAR ISSO COM OUTRAS TABELAS. Basicamente, é o MongoDB, só que melhor. E o SQLite? Faz tudo isso e ainda roda até num microcontrolador de 2 reais.

Então não me venha com "NoSQL escala melhor" como um dogma. PostgreSQL escala muito bem horizontalmente. E mesmo o SQLite, dá para escalar para centenas de milhares de conexões. Escalabilidade é arte, não religião. Enquanto tem 'cloud engineer' configurando auto-scaling sem entender o que tá acontecendo, tem programador raiz otimizando cada ciclo de CPU que a consulta gasta.

MAS CALMA, NÃO SOU FANBOY:

"NoSQL" é um termo burro. São 50 tipos de banco diferentes e cada um serve pra um propósito ESPECÍFICO. E vamos falar a verdade, esse termo "NoSQL" é uma bagunça! O que você quer dizer com isso? Existem bancos de dados de documentos (como o MongoDB), bancos de dados de chave-valor (como o Redis), bancos de dados de grafos (como o Neo4j), bancos de dados de colunas (como o Cassandra)... cada um com suas particularidades e casos de uso específicos. Não existe um "NoSQL" genérico que sirva para tudo. Mas existe o SQL, entendeu agora?

1. SQL não é perfeito, mas é BOM O SUFICIENTE pra quase tudo.

2. Bancos especializados são ÓTIMOS pra problemas específicos, mas DESASTROSOS como escolha padrão.

3. COMEÇAR COM SQL É SEMPRE A ESCOLHA SEGURA. Se um dia você precisar de algo diferente, AÍ VOCÊ MIGRA.

O PONTO É: comece com SQL. Sem discussão. USE. Se um dia, e só se, você esbarrar num problema que exija um banco específico (ex: "preciso processar 1 milhão de eventos por segundo"), AÍ VOCÊ MIGRA. Não comece no NoSQL por medo de um futuro que provavelmente nunca chegará.

Vai lá e escreve umas queries como se o mundo dependesse disso. Porque depende.

Agora, o elefante na sala: tem projeto que usa banco relacional só pra FICAR REFÉM DE UM ORM chinfroso, ou pior fazer um SELECT * FROM users depois um SELECT * FROM carts, e processar tudo no Javascript. Aí, óbvio, fica uma bosta mesmo. Se é para tratar o PostgreSQL como um "dado bruto" e jogar tudo na memória; e trafegar tudo Internet, então sim, vai de NoSQL mesmo — porque o problema não é o banco, é o dev.

Eu meio que respondi aqui: https://www.tabnews.com.br/maniero/22e29cfe-89fe-46d4-a456-e8931a58006a. E tem outro comentário meu lá que ajuda entender, tem links para você entender melhor.

Note que o termo NoSQL é horrível porque várias tecnologias incluidas nele, então nem dá para compara com banco de dados relacional (que usa SQL ou não) porque é o mesmo que você dizer que veículo é melhor avião. Você tem dizen que o que é melhor que avião? Trem? Carro? Navio? Bicicleta? Órgão que vende mídia? Quando a pessoa usa o termo NoSQL eu já sei que ela está só falando de hype e não de algo real.

É verdade que muitos chamam o banco de dados de modelo de documentos como NoSQL. Em geral a comparação é com esse modelo de NoSQL e não os outros (embora alguns modelos de documentos usam SQL).

Em resumo onde NoSQL/documento é bom:

• Você tem um problema muito específico que ele se encaixa perfeitamente (a maioria dos sistemas não são assim, mas tem aplicações importantes de nichoi que podem se beneficiar)
• Você está fazendo uma %$@#!&* qualquer então qualquer porcaria que você usar dá na mesma
• A tecnologia do sistema que está fazendo exige ou se beneficia de um modelo assim. Aí o problema já é a tecnologia que escolheu, então não é o melhor argumento
• Você só conhece NoSQL - péssimo argumento técnico
• Você não sabe o que está fazendo, não entende as deficiências disso e acredita em mentiras contadas por alguns - mais uma vez um argumento ruim

Você precisa da escalabilidade horizontal? Duvido. O Stack Overflow era um dos 30 sites mais acessados do mundo e sempre rodou com um banco de dados SQL e rolava até em apenas um servidor (eles testavam pra ver se aguentava). A Wikipedia precisa de vários servidores de DB, até porque o software é muito ruim, e escala horizontalmente sem problemas, e era um dos 5 sites mais acessados do mundo. Poderia fazer uma lista enorme das maiores big techs que usam relacional em quase tudo, NoSQL em algumas coisas bem específicas.

A pessoas acreditam muito que vão precisar de mais escala do que vão ter. Sabe o que as pessoas acreditam muit também: Que o sistema não vai ficar mais complexo depois e você vai pagar o preço pela escolha pelo simplório.

De qualquer forma a maioria das pessoas não entendem sobre o teorema CAP, então o que um modelo entrega faz perder outra coisa que pode ser aceitável para você ou não. Eu falo sobre isso nos links que passei. Muitas pessoas se ferram muito porque só percebem a besteira que fizeram tarde demais. Tem uma quantidade de anedotas, sobre os problemas de quem fez essa opção sem entender todas as implicações, que assusta.

Se você não precisa de relacionamentos complexos não use em um banco de dados relacional, ele tem várias outras vantagens. Mas se precisar ele tem, o modelo de documento também tem, mas todo mundo recomenda que não deve usar, até porque ele fica uma tragédia, ele não foi feito para trabalhar assim, todo o ganho que a pessoa espera vira problemaço. E no modelo relacional se você adotar uma organiação parecida com o de um documento ele passa ter vantagens que as pessoas não costumam associar a ele porque não usam tanto assim.

Não existe milagre como alguns acham. NoSQL não é mais rápido, ele pode ser mais rápido em certas circunstâncias bem específicas ou quando está comparando NoSQL bom com SQL ruim, o que é o que mais vejo.

Minha experiência chutaria que entre 90 e 99% da adoaçao de NoSQL (especialmente documento) é escolhada errada ou pelo menos desnecessária.

Ouvir influencer, ou o ChatGPT que aprende com esses, só faz tomar a decisão popular (às vezes nem isso), não necessariamente a correta.

O modelo relacional e os produtos que usam SQL costumam atender quase todos os projetos, tem comprovoção e força matemática (talvez seja um dos motivos que alguns não gostem dele, é admissão de incompetência), ainda é mais popular e não está diminuindo de tamanho, é algo bem comprovado, costuma ter produtos mais bem acabados, completos, flexíveis em muitos pontos, em geral possuem recursos para evoluir mais, evita gambiarras (outro motivos que certos tipos de personalidade não gostam), no longo prazo o competente mantém boa produtividade, enquanto que mesmo bom desenvolvedor usando documento começa se perder, mas ele não é tão bom assim porque ele não enxerga o futuro.

Agora vou pedir para confiar em mim. Vai de relacional até que possa provar que um NoSQL vai te beneficiar, é difícil achar quem errou por ter escolhido SQL.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Eu realmente não entendo por que, mas as pessoas tem a mania de responder como se fossem completos maniacos, isso é aterrorizante. Não existe praticamente nenhum tipo de resposta que seja dogmática quando se fala em programação, isso vale pra questão do SQL. Mesmo pra casos extremamente simples pode ser vantajoso usar um banco de dados NoSQL dependendo do que você quiser construir, principalmente se o projeto for seu. Se for do seu contratante você faz o que quiserem, mas essa ladainha de "tem de fazer X, ponto" quando a pergunta é extremamente geral é obnoxia.
Se você usa uma linguagem orientada a objetos, por exemplo, a relational impedance vai te morder mais cedo ou mais tarde na questão de como você modela e traduz os dados, e nesse sentido você ganha velocidade de desenvolvimento em não se preocupar com isso e simplesmente inserir os dados num NoSQL (claro que se usar um postgress tem essas vantagens e mais com as colunas de JSON dele, isso não discordo, mas de novo, extremos). Experimenta usar SQL, experimenta usar NoSQL, veja o que mais lhe diverte e te torna mais produtivo, só não fica nessa de ser um "homem da tecnologia X". Aprende tudo o que puder, isso vai lhe tornar um desenvolvedor melhor.

Primeira coisa que me incomoda nos termos sql e nosql é que ambos falam da linguagem de consulta SQL. O termo deveria ser bancos acid ou não acid.

Segundo:

Você tá viajando para um k7.

Tem outras coisas nesses bancos ACID que você não leva em bancos non-ACID. Como indexação, views materializadas, particionamento nativo. E outros ademais.

Enfim, tinha feito um post sobre o pouchDB que é um banco não-acid. Nesse caso ele foi usado como um orquestrador de sincronização de arquivos entre aparelhos multi-mestre.

Olha, eu estou há uns bons anos no mercado e te direi minha perspectiva.

Eu fui ensinado a usar, desde cedo, bancos NoSQL. Mongo e Dynamo, principalmente. E o motivo era: ah Dynamo é serverless e é barato.

A grande questão é que tudo tem um preço, tanto $$ como do ponto de vista técnico.

Do ponto de vista técnico, é um saco você trabalhar com bancos NoSQL diferentes. Principalmente se sua empresa mudar do banco A para o banco B.

E do ponto de vista do $$, ele é escalável, que significa que sua aplicação vai ficar rodando enquanto seu cartão não estourar.

Outro problema é que: amanhã ou depois sua empresa pode começar a oferecer o seu serviço na versão on-premise. Ou seja, zero cloud. E aí, como que cê vai fazer? O teu cliente não quer pra hoje, ele te pediu hoje pra você ter entregado ontem. Aí voce vai argumentar: não conseguimos te entregar isso para amanhã porque infelizmente temos uma forte dependência de produtos ofertados na Cloud e blá blá blá

No fim, seu cliente não sabe o que é cloud, não sabe o que é SQL ou NoSQL. Ele quer apenas o negócio rodando na salinha dele. Ponto.

Existem bancos NoSQL que você consegue rodar localmente através de um Docker, o MongoDB e o DynamoDB também permitem você fazer isso atualmente.

Agora, vamos para a parte que realmente importa, quase sempre. Você criou um sistema para uma empresa fornecedora de energia elétrica. Eles possuem 40 milhões de clientes espalhados pelo Brasil. Aí chega o João, que é o CEO da empresa e ele quer puxar o consumo total dos últimos 10 anos. Nesse meio tempo, nasceu gente, morreu gente, pessoas se mudaram e, no fim, você tem bilhões e bilhões de registros de consumo.

Como você vai fazer essa conta? Bancos SQL, tais como MySQL, Microsoft SQL Server, Postgre e etc..., possuem o SQL como linguagem em comum. Muda algumas features e talvez sintaxe entre eles, mas, no fim, você consegue executar uma query que o próprio banco faz e calcula tudo isso pra você.

Já nos bancos que eu citei, até onde eu saiba, você não possui essa funcionalidade. Cada banco possui seu set de operações que não são comuns entre si. Aí voce teria que fazer um loop no código pra criar essa soma.

Os bancos SQL, pela vantagem de compartilhar entre si essa linguagem em comum, você consegue trocar de banco. Hospedar um banco localmente, inclusive usando Docker. Fazer queries onde o banco é o responsável pelo cálculo.

Claro que estou tirando alguns fatores como: caching estruturação da aplicação disponibilidade e etc...

Mas no geral, trabalhar com bancos SQL vira a preferência pelas capacidades que ele oferece.

Agora, os bancos NoSQL também possuem seu lugar. Caching, projetos pequenos, projetos grandea com pouco acesso, fácil escalabilidade pra aplicação e etc...

Tudo sempre depende do contexto e do momento.

Eu sempre que tenho um projeto novo, começo no NoSQL e depois, se o projeto ir pra frente, vamos de Postgre.

Cara, acho que pra muitos projetos pra dar o kickstart é uma boa utilizar o NoSql justamente como você falou poupar tempo e trabalho mais se o projeto tem chance de crescer a escalabilidade do SQL e estabilidade(com mais esforço obviamente) é um fator muito importante na descisão, mais particularmente um dockerzin que com um comando tenho um postgreSQL ali me pega na maioria dos projetos que começo.