No primeiro acesso, o tempo de acesso aparecerá mais rápido no SQLite
O tempo de acesso para o SQLite aparecerá mais rápido em primeira instância, mas isso ocorre com um pequeno número de usuários online. SQLite usa um algoritmo de acesso muito simplista, é rápido, mas não lida com simultaneidade.
À medida que o banco de dados começar a crescer, a quantidade de acessos simultâneos começará a sofrer. A maneira como os servidores lidam com várias solicitações é completamente diferente e muito mais complexa e otimizada para alta simultaneidade. Por exemplo, o SQLite bloqueará toda a tabela se uma atualização estiver em andamento e enfileirará os pedidos.
Os RDBMSs fazem muito trabalho extra que os tornam mais escaláveis
O MySQL, por exemplo, mesmo com um único usuário, criará uma FILA de acesso, bloqueará tabelas parcialmente em vez de permitir apenas execuções de um único usuário por tempo e outras tarefas bastante complexas para garantir que o banco de dados ainda esteja acessível para qualquer outro acesso simultâneo.
Isso tornará a conexão de um único usuário mais lenta, mas compensa no futuro, quando 100 usuários estiverem online e, neste caso, o procedimento simples "BLOQUEAR A TABELA INTEIRA E EXECUTAR UMA ÚNICA CONSULTA DE CADA VEZ" do SQLite sobrecarregará o servidor .
SQLite é feito para simplicidade e aplicativos de banco de dados independentes.
Se você espera ter 10 acessos simultâneos de gravação no banco de dados por vez, o SQLite pode ter um bom desempenho, mas você não deseja um aplicativo de 100 usuários que escreve e lê dados constantemente no banco de dados usando o SQLite. Ele não foi projetado para tal cenário e irá destruir recursos.
Considerando o seu cenário do TeamSpeak, é provável que você esteja bem com o SQLite, mesmo para alguns negócios, está tudo bem, alguns sites precisam de bancos de dados que serão somente leitura, a menos que sejam adicionados novos conteúdos.
Para esse tipo de uso, o SQLite é uma solução barata, fácil de implementar, independente e perfeita que fará o trabalho.
