SQLite carrega uma fama injusta de "banco de brinquedo", útil só para aprender. Na prática, uso SQLite com frequência — só não para os mesmos problemas que uso MySQL.
Onde SQLite ganha
Testes automatizados são o caso mais claro: rodar a suíte de testes contra um arquivo SQLite em memória é ordens de magnitude mais rápido do que subir um MySQL a cada execução, e a diferença de comportamento entre os dois raramente afeta o que está sendo testado. Scripts internos, ferramentas de linha de comando e protótipos que não vão para produção também se beneficiam da simplicidade de não precisar de um servidor de banco rodando.
Um exemplo do meu próprio fluxo: os scripts de automação que uso com Python e Playwright frequentemente precisam guardar algum estado entre execuções — que teste já rodou, qual foi o resultado. Um arquivo SQLite resolve isso sem exigir configurar credencial de banco, string de conexão ou servidor rodando em background. É a ferramenta que não atrapalha o script de servir ao seu propósito.
Onde eu não uso
Qualquer sistema com múltiplos processos escrevendo ao mesmo tempo, ou que precise de um servidor de banco acessível pela rede, está fora de cogitação para SQLite. Simulado Solidário e qualquer projeto com usuários concorrentes reais rodam em MySQL, sem exceção. A régua não é "SQLite é pior", é reconhecer para qual problema cada ferramenta foi desenhada.
O critério que aplico a qualquer escolha de tecnologia
Essa mesma pergunta — "isso resolve o problema que eu realmente tenho, ou é só o que estou acostumado a usar?" — é o critério que uso para qualquer decisão de stack, incluindo quando decido construir algo do zero ou usar uma solução pronta. Os erros de modelagem que descrevo em MySQL valem igualmente se você optar por SQLite num contexto onde ele é a escolha certa.
