Ved første adgang vises tid hurtigere i SQLite
Adgangstiden for SQLite vises hurtigere i første omgang, men dette er med et lille antal brugere online. SQLite bruger en meget forenklet adgangsalgoritme, den er hurtig, men håndterer ikke samtidighed.
Efterhånden som databasen begynder at vokse, og mængden af samtidig adgang vil den begynde at lide. Den måde, servere håndterer flere anmodninger på, er helt anderledes og meget mere kompleks og optimeret til høj samtidighed. For eksempel vil SQLite låse hele bordet, hvis der er en opdatering i gang, og sætte ordrerne i kø.
RDBMS'er gør en masse ekstra arbejde, der gør dem mere skalerbare
For eksempel vil MySQL, selv med en enkelt bruger, oprette en adgangskØ, låse tabeller delvist i stedet for kun at tillade enkeltbruger-pr-udførelser og andre ret komplekse opgaver for at sikre, at databasen stadig er tilgængelig for enhver anden samtidig adgang.
Dette vil gøre en enkelt brugerforbindelse langsommere, men betaler sig i fremtiden, når 100-vis af brugere er online, og i dette tilfælde vil den simple "LÅS HELE TABELLEN OG UDFØR EN ENKEL FORESPØRGSEL HVER GANG"-proceduren i SQLite tære på serveren .
SQLite er lavet til enkelhed og selvstændige databaseapplikationer.
Hvis du forventer at have 10 samtidige adgangsskrivninger til databasen ad gangen, kan SQLite fungere godt, men du vil ikke have et 100-brugerprogram, der konstant skriver og læser data til databasen ved hjælp af SQLite. Det var ikke designet til et sådant scenarie, og det vil kassere ressourcer.
I betragtning af dit TeamSpeak-scenarie er du sandsynligvis ok med SQLite, selv for nogle virksomheder er det OK, nogle websteder har brug for databaser, der kun kan læses, medmindre der tilføjes nyt indhold.
Til denne form for brug er SQLite en billig, nem at implementere, selvstændig, perfekt løsning, der vil få arbejdet gjort.