SQLite, Solid Queue, en de weg naar eenvoud

Als iemand die jarenlang vertrouwde op de robuustheid van MySQL voor elke productieomgeving, voelde de overstap naar SQLite in Rails 8 aanvankelijk merkwaardig. Ik was gewend dat een "echte" database een aparte, krachtige service vereiste en was dan ook behoorlijk sceptisch of een simpel databasebestand wel bestand zou zijn tegen het echte werk.

Maar door de herwaardering van moderne webarchitectuur en technische doorbraken, is SQLite van het 'kleine broertje' getransformeerd tot een volwaardige productie-oplossing. Hierdoor heb je voor veel projecten geen aparte database-servers zoals PostgreSQL (of MySQL) en in-memory stores zoals Redis meer nodig, wat de weg vrijmaakt voor een ongekende eenvoud in je stack.

De grootste drempel voor SQLite in productie was de beperking dat er slechts één proces tegelijkertijd kon schrijven, wat vaak leidde tot "database locked" foutmeldingen. Met de standaard integratie van de Write-Ahead Log (WAL) mode in Rails 8 is dit probleem nagenoeg verleden tijd. In deze modus kunnen leesacties en schrijfacties parallel plaatsvinden. Terwijl de database een schrijfactie verwerkt in een apart logbestand, kunnen andere gebruikers ongestoord data blijven opvragen. Dit maakt SQLite verrassend schaalbaar voor applicaties met duizenden gelijktijdige gebruikers.

Wat SQLite in Rails 8 echt "productie-ready" maakt, is de introductie van Solid Queue en Solid Cache. Voorheen had je voor achtergrondtaken en caching bijna altijd Redis nodig. Dit voegt echter een extra laag complexiteit (en kosten) toe aan je infrastructuur. Rails 8 gebruikt de snelheid van SQLite om deze taken direct in de database af te handelen. Hierdoor verandert je architectuur van een web van servers naar een gestroomlijnde "One Person Framework" stack: één server, één taal, en één bestand voor al je data.

In een traditionele setup met PostgreSQL moet je applicatie over een netwerk praten met de database, wat altijd voor een kleine vertraging zorgt. SQLite is echter een bibliotheek die direct binnen je Ruby-proces draait en data leest van de lokale schijf (vaak snelle NVMe SSD's). De netwerk-latency is dus letterlijk nul. Voor veelvoorkomende leesprocessen is SQLite hierdoor vaak sneller dan een krachtige (extern gehoste) Postgres-cluster.

Er is een argument dat SQLite onveilig zou zijn omdat het "slechts een bestand" is. Dit is achterhaald door tools zoals Litestream. Deze tools zorgen voor real-time, per-seconde replicatie van je SQLite-bestand naar cloudopslag zoals S3 of bijvoorbeeld Google Cloud Storage. Mocht je server crashen, dan herstel je de database in een handomdraai tot op de laatste transactie. Hiermee biedt SQLite nu hetzelfde niveau van databehoud en recovery als grote database-systemen (maar zonder de administratieve rompslomp).

Door deze combinatie van moderne locking-mechanismen (Solid Queue & Solid Cache), het elimineren van extra infrastructuur zoals Redis, en geavanceerde replicatie-tools als Litestream, is de vraag niet langer of SQLite klaar is voor productie, maar of je applicatie de extra complexiteit van PostgreSQL wel echt nodig heeft. Met Rails 8 en Docker kun je een volledige applicatie draaien op een enkele VPS voor een fractie van de kosten van PaaS, zonder dat je inlevert op prestaties. Voor 80% van de MKB-applicaties en SaaS-producten is het een snelle, stabiele en vooral eenvoudige keuze. PostgreSQL blijft echter de koning voor de "high-scale" enterprise wereld.