Vid första åtkomst kommer tiden att visas snabbare i SQLite
Åtkomsttiden för SQLite kommer att visas snabbare i första instans, men detta är med ett litet antal användare online. SQLite använder en mycket förenklad åtkomstalgoritm, den är snabb men hanterar inte samtidighet.
När databasen börjar växa, och mängden samtidig åtkomst kommer den att bli lidande. Sättet som servrar hanterar flera förfrågningar är helt annorlunda och mycket mer komplext och optimerat för hög samtidighet. Till exempel kommer SQLite att låsa hela tabellen om en uppdatering pågår och köa beställningarna.
RDBMS gör mycket extraarbete som gör dem mer skalbara
MySQL till exempel, även med en enskild användare kommer att skapa en åtkomstkö, låsa tabeller delvis istället för att endast tillåta körningar av en användare per gång och andra ganska komplexa uppgifter för att se till att databasen fortfarande är tillgänglig för alla andra samtidiga åtkomster.
Detta kommer att göra en enskild användares anslutning långsammare, men lönar sig i framtiden, när 100-tals användare är online, och i det här fallet kommer den enkla "LÅS HELA TABELLEN OCH UTFÖR EN ENKEL FRÅGA VARJE GÅNG"-proceduren i SQLite att svälja servern .
SQLite är gjord för enkelhet och självständiga databasapplikationer.
Om du förväntar dig att ha 10 samtidiga åtkomstskrivningar i databasen åt gången kan SQLite fungera bra, men du vill inte ha ett 100-användarprogram som konstant skriver och läser data till databasen med SQLite. Det var inte designat för ett sådant scenario, och det kommer att kassera resurser.
Med tanke på ditt TeamSpeak-scenario är du sannolikt ok med SQLite, även för vissa företag är det OK, vissa webbplatser behöver databaser som endast kan läsas om du inte lägger till nytt innehåll.
För denna typ av användning är SQLite en billig, lätt att implementera, fristående, perfekt lösning som kommer att få jobbet gjort.