Waarom SQLite overal is: de embedded database die wint

Wat SQLite is (en waarom mensen het blijven kiezen)

SQLite is een kleine database-engine verpakt als een library die je applicatie linkt—zoals een functie die je toevoegt, niet een service die je draait. In plaats van over het netwerk naar een aparte databasemachine te praten, leest en schrijft je app naar één databasebestand (vaak iets als app.db) op schijf.

Dat idee van “het is gewoon een bestand” is een groot deel van de aantrekkingskracht. Het databasebestand bevat tabellen, indexen en data, en SQLite regelt de lastige dingen—queries, constraints en ACID-transacties—achter de schermen.

Embedded vs. “Database Server”

Bij een client-server database (denk aan PostgreSQL of MySQL) doe je meestal:

• een databaseserver installeren en draaien
• gebruikers, poorten, backups en monitoring configureren
• verbinden vanaf je applicatie via TCP

Met SQLite draait de database in je applicatieproces. Er is geen aparte server om te installeren, te starten of gezond te houden. Je app roept de API van SQLite aan, en SQLite leest/schrijft het lokale bestand direct.

Mensen beschrijven SQLite vaak als “serverless.” Dat betekent niet dat het in de cloud draait zonder servers—het betekent dat jij geen apart database-serverproces beheert.

Je hebt waarschijnlijk al onbewust SQLite gebruikt

SQLite duikt stilletjes op in veel alledaagse software omdat het makkelijk te leveren en betrouwbaar is:

• mobiele apps die een lokale database nodig hebben
• desktop-apps die instellingen, caches of gebruikersdata opslaan
• browsers, chatapps en tools die gestructureerde opslag nodig hebben
• local-first apps die offline blijven werken

Veel producten kiezen SQLite omdat het een eenvoudige standaardkeuze is: snel, stabiel en nul-configuratie.

Een uitstekende standaard (met grenzen)

SQLite is een uitstekende keuze voor veel single-user apps, embedded apparaten, prototypes die echte producten worden, en services met matige schrijfconcurrentie. Maar het is niet het antwoord op elk schaalprobleem—vooral wanneer veel machines tegelijkertijd naar dezelfde database moeten schrijven.

De kernboodschap: SQLite is niet “klein” in mogelijkheden—het is klein in operationele last. Daarom blijven mensen het kiezen.

Wat “Embedded” en “Serverless” echt betekenen

SQLite wordt vaak met twee woorden omschreven die als buzzwords klinken: embedded en serverless. Bij SQLite hebben beide woorden specifieke (en praktische) betekenissen.

“Embedded” = een library, geen service

SQLite is niet iets dat je op de achtergrond “draait” zoals PostgreSQL of MySQL. Het is een softwarelibrary die je applicatie linkt en direct gebruikt.

Wanneer je app data moet lezen of schrijven, roept het SQLite-functies aan binnen hetzelfde proces. Er is geen aparte database-daemon om te starten, te monitoren, te patchen of te herstarten. Je app en de database-engine leven samen.

“Serverless” (SQLite-stijl) = geen apart database-serverproces

SQLite’s “serverless” betekent niet hetzelfde als de “serverless databases” die cloud-aanbieders verkopen.

• Cloud-serverless producten hebben nog steeds servers—alleen beheer je ze niet. Je verbindt over een netwerk, betaalt voor capaciteit/gebruik, en de operatie gebeurt op infrastructuur waar je geen controle over hebt.
• SQLite serverless betekent dat er simpelweg geen databaseserver is. De database is meestal een lokaal bestand en je app leest/schrijft het direct.

Hoe apps met SQLite praten

Bij client-server databases stuurt je code SQL over TCP naar een ander proces. Met SQLite geeft je code SQL door via library-aanroepen (vaak via een language binding) en SQLite leest/schrijft het databasebestand op schijf.

Het resultaat: geen netwerkronde, geen connection pool om te tunen en minder faalmodi (zoals “kan de DB-host niet bereiken”).

Wat dit betekent voor operatie

Voor veel producten vertaalt “embedded + serverless” zich naar minder bewegende delen:

• Geen database-installatiestap op ontwikkelaarsmachines
• Simplere deploys (vooral voor desktop, mobiel en edge-apps)
• Gemakkelijker lokaal testen en meer reproduceerbare omgevingen

Die eenvoud is een grote reden dat SQLite overal opduikt—ook wanneer teams zwaarders zouden kunnen kiezen.

Het nul-setup voordeel: lever een bestand, geen service

Het meest ondergewaardeerde voordeel van SQLite is ook het eenvoudigste: je database is een bestand dat met je app meereist. Er is geen aparte server om te provisionen, geen poorten om te openen, geen gebruikersaccounts aan te maken en geen checklist “draait de database?” voordat iets werkt.

Deployments en updates worden veel eenvoudiger

Bij een client-server database betekent het uitrollen van een app vaak het afleveren van infrastructuur: een DB-instance, migraties, monitoring, credentials en een plan om te schalen. Met SQLite package je meestal een initieel .db-bestand (of maak je het bij de eerste run) en je applicatie leest en schrijft er direct naar.

Updates kunnen ook eenvoudiger zijn. Nieuwe tabel of index nodig? Je levert een applicatie-update die migraties tegen het lokale bestand uitvoert. Voor veel producten verandert dat een meerstappen-rollout in één release-artifact.

Perfect voor desktop, mobiel en edge

Dit “lever een bestand”-model blinkt uit wanneer de omgeving beperkt of gedistribueerd is:

• Desktop-apps: eenmaal installeren, offline werken en data lokaal opslaan met minimale rompslomp.
• Mobiele apps: een beproefd patroon voor on-device opslag wanneer netwerktoegang onbetrouwbaar is.
• Edge-apparaten / kiosken / embedded systemen: minder bewegende delen betekent minder foutpunten, vooral waar remote beheer lastig is.

Backups zijn bestand-gebaseerd—maar verdienen nog steeds een plan

Een databasebestand kopiëren klinkt triviaal en dat kan het ook zijn—als je het goed doet. Je kunt niet altijd veilig een live databasebestand kopiëren met een naïeve bestandskopie terwijl de app schrijft. Gebruik SQLite’s backup-mechanismen (of zorg voor een consistente snapshot) en bewaar backups op een duurzame plek.

Minder dedicated DBA-werk

Omdat er geen server is om te tunen en te babysitten, vermijden veel teams een flink deel van de operationele last: het patchen van een DB-service, het beheren van connection pools, het roteren van credentials en het gezond houden van replica’s. Je hebt nog steeds goed schema-ontwerp en migraties nodig—maar de “database operations” footprint is kleiner.

Betrouwbaarheid eerst: transacties en dataintegriteit

De populariteit van SQLite gaat niet alleen over gemak. Een grote reden dat mensen erop vertrouwen is dat het correctheid boven “mooie” features stelt. Voor veel apps is de belangrijkste database-eigenschap simpel: geen data verliezen of corruptie veroorzaken.

ACID, uitgelegd menselijk

SQLite ondersteunt ACID-transacties, wat kortweg betekent dat “je data netjes blijft, zelfs als er iets misgaat.”

• Atomair: een wijziging gebeurt volledig of helemaal niet. Als een bewerking 5 updates bevat en de app crasht na 3, laat SQLite je niet achter met een half afgemaakt resultaat.
• Consistent: regels waarop je vertrouwt blijven waar. Als je verwacht dat saldi nooit negatief worden, helpen transacties om updates ordelijk te houden.
• Geïsoleerd: meerdere bewerkingen lopen elkaar niet in de weg. De ene actie leest niet de halfgeschreven wijzigingen van een andere.
• Duurzaam: zodra SQLite zegt dat een transactie gecommit is, moet die er na een crash of stroomuitval nog steeds zijn.

Journaling-modi (hoog niveau)

SQLite bereikt crashveiligheid met een journal—een veiligheidsnet dat vastlegt wat gaat veranderen zodat het voorspelbaar kan herstellen.

Twee veelvoorkomende modi:

• Rollback journal: de klassieke aanpak. SQLite kan onvoltooide bewerkingen ongeldig maken als er iets een schrijfonderbreking veroorzaakt.
• WAL (Write-Ahead Logging): verbetert vaak de concurrentie door lezen en schrijven te scheiden en maakt herstel snel omdat wijzigingen worden toegevoegd en later samengevoegd.

Je hoeft de interne werking niet te kennen om te profiteren: de kern is dat SQLite is ontworpen om voorspelbaar te herstellen.

Waarom dit belangrijker is dan extra features

Veel toepassingen hebben geen clustering of exotische datatypes nodig. Ze willen accurate records, veilige updates en het vertrouwen dat een crash niet stilletjes gebruikersdata bederft. SQLite’s focus op integriteit is een grote reden waarom het gebruikt wordt in producten waar “saai en correct” wint van “indrukwekkend en complex.”

Prestaties: snel omdat het dicht bij je code zit

SQLite voelt vaak “direct” omdat je app in-process met de database praat. Er is geen aparte databaseserver om mee te verbinden, geen TCP-handshake, geen netwerklatentie en geen wachten op een externe machine. Een query is gewoon een functieaanroep die van een lokaal bestand leest (vaak geholpen door de OS page cache), waardoor de tijd tussen “voer SQL uit” en “krijg rijen terug” verrassend kort kan zijn.

Waar SQLite doorgaans uitblinkt

Voor veel producten betreft de workload vooral lezen met een gestage stroom van schrijfbewerkingen: app-state laden, zoeken, filteren, sorteren en joins op kleine tot middelgrote tabellen. SQLite is hier uitstekend in. Het kan efficiënte geïndexeerde zoekopdrachten doen, snelle range scans en snelle aggregaties wanneer de data comfortabel op lokale opslag past.

Matige schrijfworkloads zijn ook een goede match—denk aan gebruikersvoorkeuren, achtergrondsync-queues, gecachte API-responses, eventlogs of een local-first datastore die later wijzigingen mergeert.

De belangrijkste bottleneck: schrijfconcurrentie

De afweging van SQLite zit in schrijfterugconcurrentie. Het ondersteunt meerdere lezers, maar schrijfbewerkingen vereisen coördinatie zodat de database consistent blijft. Bij zware gelijktijdige schrijfbewerkingen (veel threads/processen die tegelijk updaten) kun je lock-contention tegenkomen en retries of “database is busy”-fouten zien tenzij je het gedrag tunet en je toegangspatronen ontwerpt.

SQL-basics blijven belangrijk

SQLite is niet “snel out-of-the-box” als queries slecht zijn opgebouwd. Indexen, selectieve WHERE-clausules, het vermijden van onnodige full-table scans en het juist afbakenen van transacties maken een groot verschil. Behandel het als een echte database—want dat is het ook.

Portabiliteit en het single-file model

Het meest kenmerkende aan SQLite is ook het eenvoudigste: je hele database is één bestand (plus optionele bijbestanden zoals een WAL-journal). Dat bestand bevat schema, data, indexen—alles wat de app nodig heeft.

Een database die je overal mee naartoe neemt

Omdat het “gewoon een bestand” is, wordt draagbaarheid een standaardfeature. Je kunt het kopiëren, toevoegen aan een bugrapport, delen met een collega (wanneer gepast) of verplaatsen tussen machines zonder een server, gebruikers of netwerktoegang op te zetten.

SQLite draait op vrijwel elk belangrijk platform: Windows, macOS, Linux, iOS, Android en een lange lijst van embedded omgevingen. Die cross-platform ondersteuning gaat samen met lange-termijn stabiliteit: SQLite is bekend conservatief in backwards compatibility, dus een databestand gemaakt jaren geleden is meestal nog te openen met nieuwere versies.

Portable testing en reproduceerbare omgevingen

Het single-file model is ook een test-superkracht. Wil je een bekende dataset voor een unit test-suite? Check een klein SQLite-bestand in (of genereer het tijdens tests) en elke ontwikkelaar en CI-job start vanaf dezelfde basis. Moet je een klantprobleem reproduceren? Vraag om het DB-bestand (met juiste privacyafhandeling) en je kunt het probleem lokaal herhalen—geen “het gebeurt alleen op hun server”-mysterie.

Praktische noot: behandel het DB-bestand als applicatiedata

Die draagbaarheid heeft ook een keerzijde: als het bestand wordt verwijderd of beschadigd, is je data weg. Behandel het SQLite-databestand als elk belangrijk applicatie-asset:

• bewaar het in de juiste OS-beheerde app-datamap
• neem het op in backups waar passend
• bescherm het met bestandspermissies en encryptie indien nodig
• vermijd tijdelijke mappen tenzij de data echt wegwerpbaar is

Ecosysteem en tooling die SQLite makkelijk maakt om te adopteren

SQLite is makkelijk te leren, deels omdat je zelden from-scratch begint. Het zit ingebouwd in veel platforms, wordt meegeleverd met gangbare runtimes en heeft “saaie” compatibiliteit tussen omgevingen—precies wat je wilt voor een ingebedde database.

Integraties die je écht gebruikt

De meeste stacks hebben al een beproefd pad naar SQLite:

• Talen: Python (sqlite3 in de standaardbibliotheek), Go (mattn/go-sqlite3), Java (JDBC-drivers), .NET (Microsoft.Data.Sqlite), PHP (PDO SQLite), Node.js (better-sqlite3, sqlite3).
• Frameworks/ORMs: Rails (Active Record), Django, Laravel, SQLAlchemy, Prisma, Sequelize, Entity Framework.
• Mobiel en desktop: iOS en macOS (SQLite is system-wide beschikbaar), Android (SQLite-API's), plus wrappers zoals Room (Android), GRDB (Swift) en vele React Native/Flutter-plugins.

Die breedte is belangrijk omdat je team vertrouwde patronen kan gebruiken—migraties, query-builders, connection management—zonder eigen plumbing te moeten uitvinden.

Tooling: van “kijk in het bestand” tot echte workflows

SQLite’s tooling is opmerkelijk toegankelijk. De sqlite3 CLI maakt het eenvoudig om tabellen te inspecteren, queries uit te voeren, data te dumpen of CSV te importeren. Voor visuele verkenning helpen browser-based en desktop-viewers (zoals SQLiteStudio of DB Browser for SQLite) niet-technische gebruikers om snel data te valideren.

Aan de delivery-kant ondersteunen mainstream migratietools vaak SQLite out-of-the-box: Rails-migraties, Django-migraties, Flyway/Liquibase, Alembic en Prisma Migrate maken schema-wijzigingen reproduceerbaar.

De “everywhere” feedbackloop

Omdat SQLite zo wijdverbreid is, zijn problemen meestal goed begrepen: libraries worden battle-tested, edge-cases zijn gedocumenteerd en community-voorbeelden zijn overvloedig. Die populariteit voedt meer ondersteuning, wat adoptie nog makkelijker maakt.

Bij het kiezen van een library, geef de voorkeur aan actief onderhouden drivers/ORM-adapters voor je stack en controleer gedrag rond concurrentie, binding-ondersteuning en hoe migraties worden afgehandeld. Een goed ondersteunde integratie maakt vaak het verschil tussen een soepele rollout en een weekend vol verrassingen.

Waar SQLite opduikt: real-world use cases

SQLite is het makkelijkst te begrijpen als je kijkt waar het daadwerkelijk wordt gebruikt: plekken waar een volledige databaseserver kosten, complexiteit en falen kan toevoegen.

Mobiele apps en tablets

Veel mobiele apps hebben een betrouwbare lokale opslag nodig voor sessies, gecachte content, notities of wachtrijen om later te uploaden. SQLite past omdat het één bestand is met ACID-transacties, zodat je data crashes, lege batterij-shutdowns en wankele connectiviteit overleeft.

Dit is vooral sterk in offline-first en local-first apps: schrijf elke wijziging lokaal en sync op de achtergrond wanneer netwerk beschikbaar is. Het voordeel is niet alleen offline-ondersteuning—het is snelle UI en voorspelbaar gedrag omdat lezen en schrijven op het apparaat blijven.

Desktop-apps en installers

Desktop-software heeft vaak een database nodig zonder gebruikers te vragen iets te configureren. Het leveren van één SQLite-bestand (of het aanmaken bij eerste run) houdt installatie eenvoudig en maakt backups begrijpelijk: kopieer één bestand.

Apps zoals boekhoudtools, mediamanagers en lichte CRM-achtige systemen gebruiken SQLite om data dicht bij de app te houden, wat prestaties verhoogt en “draait de databaseserver?”-problemen voorkomt.

Browsers en clienttools

SQLite verschijnt in ontwikkelaarstools en applicaties die gestructureerde opslag voor geschiedenis, indexen en metadata nodig hebben. Het is hier populair omdat het stabiel, draagbaar en procesvrij is.

Embedded apparaten en appliances

Routers, kiosken, kassa’s en IoT-gateways slaan vaak configuratie, logs en kleine datasets lokaal op. SQLite’s kleine footprint en bestand-gebaseerde draagbaarheid maken het praktisch om te deployen en bij te werken.

Developer-workflows: lokaal dev, tests, prototypes

Ontwikkelaars gebruiken SQLite voor snelle prototypes, lokale development databases en testfixtures. Het is nul-setup, makkelijk terug te zetten en deterministisch—voordelen die resulteren in snellere iteratie en betrouwbaardere CI-runs.

Dit is ook een veelgebruikt patroon bij werken met Koder.ai: teams beginnen met SQLite voor snelle lokale iteratie (of een single-tenant deployment), exporteren vervolgens de gegenereerde broncode en schakelen over naar PostgreSQL wanneer het product gedeelde, multi-writer schaal nodig heeft. Die “begin eenvoudig, migreer indien nodig” workflow houdt vroege levering snel zonder je vast te zetten.

Wanneer SQLite niet geschikt is

SQLite is een uitstekende standaard voor lokale opslag, maar het is geen universele oplossing. De sleutel is om te beoordelen op basis van je workload en operationele behoeften—niet op basis van hype.

Je hebt veel gebruikers die tegelijk schrijven

SQLite kan meerdere lezers goed aan, maar schrijfbewerkingen zijn meer beperkt omdat wijzigingen uiteindelijk moeten worden geserialiseerd om het bestand consistent te houden. Als veel gebruikers of processen tegelijkertijd data aanpassen—vooral vanaf verschillende machines—is een client-server database (zoals PostgreSQL of MySQL) vaak een betere match.

Een veelvoorkomend teken is een app die “op een laptop allemaal werkt”, maar in echte gebruikssituaties timeouts, lock-contention of wachtrijen rond schrijfbewerkingen laat zien.

Zware schrijfworkloads en hoge parallelle writes

SQLite kan erg snel zijn, maar het is geoptimaliseerd voor een andere vorm van werk: veel reads en een matige schrijfsnelheid. Als je systeem veelvuldige inserts/updates doet (metrics-ingestie, eventstreams, job-queues, hoge-volumelogging) en veel parallelle schrijvers verwacht, schaalt een server-database meestal voorspelbaarder.

Dit gaat niet alleen over “snelheid”. Het gaat ook over consistente latency: een piek in schrijfbewerkingen kan andere schrijvers blokkeren en soms readers, wat tail-latency oplevert die lastig te verklaren is.

Gecentraliseerde toegangscontrole, auditing en netwerktoegang

Als je een centrale database nodig hebt die gedeeld wordt via het netwerk met role-based permissions, auditlogs, gecentraliseerde backups en governance-features, is SQLite waarschijnlijk de verkeerde keuze. Je kunt een SQLite-bestand op een netwerkschijf zetten, maar dat veroorzaakt vaak betrouwbaarheid- en lock-problemen.

Een server-database blinkt uit wanneer je nodig hebt:

• gecontroleerde, gecentraliseerde authenticatie/authorisatie
• auditing wie wat en wanneer heeft gewijzigd
• beheerde backups, replicatie en point-in-time recovery
• veilige remote toegang voor meerdere services en teams

Een praktische manier om te beslissen

Stel jezelf twee vragen:

1. Hoe ziet concurrentie eruit in productie (hoeveel schrijvers, hoe bursty)?
2. Wie gaat het beheren (heb je centrale controles en gedeelde toegang nodig)?

Als de eerlijke antwoorden neigen naar “veel schrijvers” en “centrale governance”, is kiezen voor een client-server database geen overkill—het is meestal de eenvoudigere, veiligere route.

SQLite vs client-server databases: een praktische vergelijking

SQLite en databases zoals PostgreSQL of MySQL kunnen allebei tabellen opslaan en SQL uitvoeren, maar ze zijn gebouwd voor verschillende vormen van problemen.

Architectuur: in-process bestand vs netwerkservice

SQLite draait in je applicatieproces. Je code roept SQLite aan en SQLite leest/schrijft direct naar een lokaal databasebestand.

Een client-server database draait als een aparte service. Je app maakt verbinding over het netwerk (ook als dat gewoon localhost is), stuurt queries en de server beheert opslag, concurrentie, gebruikers en achtergrondtaken.

Dit ene verschil verklaart de meeste praktische afwegingen.

Operationele afwegingen: eenvoud vs centrale controle

Met SQLite kan deployment zo eenvoudig zijn als het leveren van een binary plus een bestand. Geen poorten, geen credentials, geen server-upgrades—vaak een grote winst voor desktop-, mobiel-, edge-apps en local-first-producten.

Client-server databases schitteren wanneer je gecentraliseerd beheer nodig hebt: veel apps en gebruikers die dezelfde database raken, fijnmazige toegang, online backups, read-replicas en volwassen observability.

Schalen: hoe elk groeit

SQLite schaalt doorgaans door:

• Verticaal schalen: snellere schijf/CPU, betere queries, caching
• Sharding als patroon: één database per gebruiker, apparaat, tenant of project (een gangbaar patroon)
• Uitgroeien: shared, multi-writer workloads migreren naar een server DB zodra coördinatie de bottleneck wordt

Client-server databases schalen makkelijker voor gedeelde workloads via grotere machines, replicatie, partitionering en pooling.

Een korte checklist om te kiezen

Kies SQLite als je lokale data wilt, minimale ops en één app-instance grotendeels de writes bezit.

Kies een client-server DB als je veel gelijktijdige schrijvers, netwerktoegang vanuit meerdere services, centrale governance of ingebouwde hoge beschikbaarheid nodig hebt.

Als je twijfelt, begin met SQLite voor snelheid van levering en houd een duidelijk migratiepad (schema's, migraties, export/import) naar PostgreSQL vrij. (zie /blog/migrating-from-sqlite)

Tips om SQLite veilig in productie te gebruiken

SQLite kan prima in productie draaien—maar behandel het als een echte database, niet als een “tijdelijk bestand dat je overal naar toe kunt kopiëren”. Een paar gewoontes maken het verschil tussen soepele werking en onverwachte downtime.

Concurrency: houd transacties kort

SQLite ondersteunt meerdere lezers en (meestal) één schrijver tegelijk. Dat is prima voor veel apps zolang je er ontwerpen voor volgt.

Houd schrijftransacties kort en gefocust: doe het werk in je app eerst, open dan een transactie, schrijf en commit snel. Vermijd langlopende transacties die locks vasthouden terwijl je wacht op netwerk, gebruikersinput of trage loops. Als je achtergrondjobs hebt, queue writes zodat ze niet opstapelen en interactieve requests blokkeren.

Overweeg WAL voor beter read/write-gedrag

Write-Ahead Logging (WAL) verandert hoe SQLite wijzigingen vastlegt zodat lezers vaak kunnen blijven lezen terwijl een schrijver actief is. Voor veel apps—vooral met veel reads en af en toe writes—vermindert WAL de “database is locked”-frictie en verbetert het throughput.

WAL is geen magie: je hebt nog steeds één schrijver en je moet rekening houden met extra WAL-bestanden op schijf. Maar het is een veelgebruikte, praktische default voor productie.

Backups en migraties: plan ze toch

Ook al is SQLite één bestand, je hebt nog steeds een backup-strategie nodig. Vertrouw niet op het toevallig kopiëren van het bestand; coördineer backups zodat je een consistente staat vastlegt (vooral onder load).

Beheer schemawijzigingen met migraties. Versioneer ze, voer ze automatisch tijdens deploys uit en test rollback/forward paden wanneer mogelijk.

Test zoals in productie

Gebruik hetzelfde schema, indexen en kritieke instellingen (zoals journal-mode) in staging en geautomatiseerde tests. Veel SQLite-“verrassingen” duiken pas op wanneer datasizes groeien of concurrentie toeneemt—load-test daarom met realistische volumes en toegangspatronen voordat je live gaat.

Conclusie: waarom “embedded” vaak een feature is, geen beperking

SQLite is overal omdat het dataopslag laat voelen als het gebruiken van een library, niet het draaien van infrastructuur. Je krijgt een beproefde SQL-engine, ACID-transacties en rijpe tooling—zonder een database-server te provisionen, gebruikers te beheren of een netwerkverbinding te babysitten.

Waarom mensen SQLite blijven kiezen

Op zijn best is SQLite de “werkt gewoon” optie:

• Nul setup: lever één bestand met je app en begin direct met lezen/schrijven.
• Betrouwbaarheid: transacties beschermen je data bij crashes of stroomverlies.
• Snelheid: data ligt naast je code, dus er is meestal geen netwerkrondje voor queries.
• Draagbaarheid: de database is een bestand dat je kunt kopiëren, back-uppen, synchroniseren of bundelen voor tests.
• Ecosysteem: drivers, migraties, admin-tools en deploymentpatronen zijn breed begrepen.

De belangrijkste beperking om te onthouden

SQLite is niet ontworpen voor hoge schrijfconcurrentie of gecentraliseerde, multi-user toegang via een netwerk. Veel lezers kunnen tegelijk queryen, maar zware gelijktijdige schrijfbewerkingen (of veel clients die één databasebestand delen) zijn het domein van een client-server database.

Een eenvoudige volgende stap

Beschrijf je workload—kies vervolgens het simpelste gereedschap dat past. Als je app grotendeels lokaal is, single-user of “local-first”, is SQLite vaak perfect. Als je veel gebruikers tegelijk naar één gedeelde dataset moet laten schrijven, overweeg een server-database zoals PostgreSQL.

Snelle checklist

• Zal de database op het apparaat / op dezelfde machine als de app leven?
• Zijn schrijfbewerkingen relatief laag of makkelijk te serialiseren?
• Heb je offline werking en eenvoudige deployment nodig?
• Kun je een enkel bestand veilig back-uppen / synchroniseren?
• Heb je veel gelijktijdige schrijvers of een gedeelde centrale database voor veel gebruikers nodig?

Als je de eerste vier met “ja” beantwoordt en de laatste met “nee”, is SQLite een sterke standaardkeuze.