Sites de uso interno: existe um caso convincente contra o SQLite?

Muitas estruturas da web, como Flask ou Django, usam SQLite como seu banco de dados padrão. O SQLite é atraente porque está incluído no python, e a sobrecarga administrativa é bastante baixa.

No entanto, a maioria dos sites de produção pública de alto tráfego acaba usando um banco de dados mais pesado: mySQL, Oracle ou postgresql.

As perguntas :

Assumir:

• O tráfego do site é moderado e o acesso simultâneo de leitura / gravação ao banco de dados ocorrerá
• Usaremos SQLAlchemy com bloqueios de gravação SQLite (embora esse comentário me deixe um pouco nervoso)
• O banco de dados conterá talvez 60.000 registros
• As estruturas de dados não exigem recursos avançados encontrados em bancos de dados mais pesados

Existe um caso convincente contra a concorrência SQLite para sites que servem como ferramentas corporativas internas de tráfego moderado? Em caso afirmativo, quais condições farão com que o SQLite tenha problemas de simultaneidade?

Estou procurando causas-raiz específicas conhecidas, em vez de medo geral / apontamento sem fundamento dos dedos.

Eu recomendo a leitura da resposta oficial à sua pergunta, Usos apropriados para SQLite . Especificamente, as "Situações em que outro RDBMS pode funcionar melhor" avisa que o SQLite não oferece suporte à gravação simultânea:

O SQLite suporta um número ilimitado de leitores simultâneos, mas permitirá apenas um gravador a qualquer instante no tempo. Para muitas situações, isso não é um problema. Cada aplicativo faz seu trabalho de banco de dados rapidamente e segue em frente, e nenhum bloqueio dura mais do que algumas dezenas de milissegundos. Mas existem alguns aplicativos que exigem mais simultaneidade e esses aplicativos podem precisar procurar uma solução diferente.

Do ponto de vista da adequação, costumo ver o SQLite como um formato de arquivo muito sofisticado que suporta consultas SQL. Eu tenderia a evitar o SQLite se quisesse separar meu banco de dados do meu aplicativo da Web, pois não é otimizado para este caso. Em suma, o SQLite é insuficientemente escalável para uso em alguns cenários; portanto, as pessoas que executam sites que esperam algum dia se tornar populares podem ter uma melhor idéia começando com algo escalável, em vez de usar o SQLite e depois serem forçadas a mudar.

Tudo isso dito, o SQLite provavelmente é bom para a maioria dos sites internos; sites geralmente internos não exigem o mesmo nível de simultaneidade e escalabilidade.

Colocando meu chapéu de diretor de TI, vejo alguns não-gos aqui:

• Risco de corrupção de dados. Talvez seja mais percebido do que real, mas no final do dia esse é um banco de dados não transacional do tipo DB que não tem muito ou nenhum recurso a gravações ruins, além de perguntar se você tem um backup recente. Falando nisso . . .
• Como eu apoio essa coisa? De certo modo, sei que tenho uma boa cópia. De preferência sem colocar o aplicativo offline.
• Como posso proteger o acesso ao banco de dados? Meu entendimento geral é que o SQL Lite não tem nenhum fora do acesso ao sistema de arquivos, que é um começo decente, mas não o princípio final. Especialmente para aplicativos da Web onde você pode querer mais permissões graduadas do que DBA ou nada.

Do ponto de vista do desenvolvedor, acho importante saber por que o SqlLite é o padrão - é por ser fácil e demonstrar bem. Se você está "vendendo" uma plataforma para novos desenvolvedores, é fundamental ativar um aplicativo da web que funcione com o mínimo de esforço. E ter que se levantar e configurar adequadamente um servidor de banco de dados seria um enorme obstáculo a ser evitado.