[THREAD] Até que ponto considerar SQLite como um "no-brainer" ?

Essa é uma aplicação simples decks magic (preciso comprar o dominio ainda), que tenho na qual eu uso sqlite.

Porém essa aplicação ela tem apenas leitura, a escrita é feita apenas por mim. Então eu ponderei que faria total sentido usar SQLite, já que é mais simples e rapido.

Obviamente se a aplicação crescer e eu precisar ter que distribuir em varios servidores, terei que mudar, mas sabemos que isso não vai acontecer. O que mais vejo é excesso de engenharia para projetos que vão morrer ou não vai passar de 200 usuarios simultaneos.

Responda as perguntas abaixo e se todas forem NÃO, então talvez possa usar:

• vou ter muitas operações de escrita concorrentes? (ex.: um site com muitos usuários atualizando dados ao mesmo tempo).
• Vou precisar escalar horizontalmente? (replicação nativa, sharding, cluster, etc.).
• Se crashar e corromper é um problema para mim? (pois Bancos como PostgreSQL ou MySQL têm mecanismos mais robustos de journaling e recuperação)
• Preciso de Monitoramento nativo?

No meu caso, o SQLlite atende pois divulguei esse site pouco (por ainda não ter dominio) e tem por volta de apenas 100 acessos diarios. Então funciona bem tranquilo.

Só não use SQLite se for em OLAP ou pra escala horizontal, de resto, será minha escolha em 100% dos casos (Trailbase é melhor que pocketbase). Cheguei a fazer escrita de 3 milhões em menos de 2sec, na época usando pocketbase, e 7 milhões nos mesmos 2sec no Trailbase.

Por enquanto, pra OLAP vou pro DuckDB (um estilo de SQLite só que pra análises).

Eu tenho uma aplicação em django que era planejada usar postgres, mas durante os testes com SQLite eu percebi que a performance era melhor dentro de uma VPS econômica.
Está no ar sem manutenção por 3 anos. Só um cronjob de backup semanal.

Também usei bastante o SQLite em aplicação PAF/ECF com bases de 8GB também sem nenhum episódio de perda ou corrupção de dados.
Claro que sqlite tem que respeitar o acesso de escrita por apenas uma thread. Mas acredito que dá pra usar em muitas aplicações de baixa concorrência.

Se existe apenas um processo (a aplicação backend) conectado ao BD é no-brainer total!

Em ponto nenhum, não existe "no-brainer" em TI

Mas por que não SQLite, na tua experiência, o que já criaste com SQlite e até que escala continuou/continua a ser viável?

O problema de SQLite não é escala, existem soluções que resolvem isso, o problema é o dialeto SQL dele, ele não tem um DISTINCT ON por exemplo

Se o dialeto SQL do SQLite te atende tem como fazer ele bater de frente em termos de pequena escala até mesmo frente ao PostgreSQL com os addons certos

Aqui no Grupo Mateus utilizamos o SQLite, que movimenta literalmente bilhões de reais. Na prática, não encontramos motivos relevantes para não usá-lo. Acredito que existam poucas situações em que ele não seja adequado, especialmente quando se trata de aplicações menores.

uso um projeto de DB chamado pocketbase.
e ele transforma o SQLite em um DB online com api e diversas outras funções como autenticação (com integrações com vários servicos como google, meta, Github), controle de autorização de acesso pra dados por usuário/cargo, realtime db, storage de arquivos integrado com a tabela, e um painel web admin que facilita o gerenciamento e modelagem das tabelas.

inclusive uso ele no meu saas e atende bem, tenho poucos usuários atualmente mas gerencio algumas dezenas de milhares de dados e milhões de requisições por mes com ele sem problemas. é feito em Go e permite personalização como um framework (tanto em Go como em js)

com esse projeto de DB eu entendi que o SQLite é muito versátil e pode se encaixar em muitos cenários web

Eu uso e abuso dele, porém para consultas onde a cláusula WHERE exige dois coringas ( WHERE '%valor%') é preciso alguns artifícios muito complexos de criação de índices e trigger, caso contrário a performance da query fica proibitiva.

Sempre que eu mando essa, me olham como se tivesse crescido uma cabeça nova ou um terceiro olho no meio da testa, mas eu não consigo chegar em outra conclusão:

Pra 90% dos projetos de software que vão ser iniciados, não faz a menor diferença escolher entre MySQL, PostgreSQL ou SQLite, usa um ORM e seja feliz.

Se vc esta se preocupando com Escala e antes de escrever teu MVP, vc está incorrendo em Otimização Prematura

Se funciona pra ti, usa SQLite

Eu construí um webserver completamente em C/C++ (todo o backend) e uso apenas o SQLite como banco de dados.
Já possuo mais de 100 usuários acessando o sistema o dia todo e mais de uma dúzia de sistemas consumindo os dados por API.
A maior tabela de consulta tem mais de 46.500.000 registros com dezenas de colunas e tabelas associadas, só esta tabela está com mais de 35 GB de dados (pesquisas via FTS).
Meu servidor (VPS) tem 4 núcleos e 8 GB de memória e tem dado conta dos acessos sem problemas ou lentidão. =D

Se você vai ter várias instâncias da mesma aplicação OU se você está rodando em uma cloud muito chata que não te permite um uso decente ed disco, afinal SQlite é disco...

O que pode resolver os casos de concorrência é usar um CRUD pro SQlite e criar apps consumidores.

Onde eu trabalhava, tinhamos uma especie um força de vendas. A logica embarcada em uma biblioteca feita com QT C++ e tivemos que criar um serviço para rodar na web. Foi feito em django, rabbitmq e sqlite (tinhamos nossa compilação do mesmo). De inicio funcionava, mas nao escalava e a medida que mais pessoas usavam, mais lento ficava e so rodava direto definindo para rodar com uma thread e um worker. Foi a pior decisão, e até hoje enxugam gelo com aquilo.

Tenho aplicação de 35GB+ que usa SQLite o principal é você testar e ver a performance, se atende, porque não usar 😅
O banco melhorou muito já, muitos dos problemas que o pessoal comenta ou vai comentar já nao é um problema mais.
Mas claro os outros bancos ainda tem seu lugar, por isso a importância de testar e saber a hora certa de usar o SQLite