SQLite in Nuxt: genoeg voor de meeste sites

Waarom het genoeg is

Een gewone site leest veel en schrijft weinig. Bezoekers lezen pagina’s. Af en toe komt er een formulier binnen of past iemand een tekst aan. Daar is SQLite goed in. Lezen kan tegelijk, schrijven gaat één voor één. Bij een contactformulier en een beheeromgeving merk je daar niets van.

Het bestand staat op dezelfde server als je site. Een query hoeft dus niet over het netwerk. Dat scheelt tijd bij elke pagina die data ophaalt.

node:sqlite in plaats van better-sqlite3

Lang was better-sqlite3 de standaard. Dat is een native module: hij wordt gebouwd voor één Node-versie en één soort processor. Bouw je de site op de ene machine en draai je hem op een andere, dan moeten die precies overeenkomen. Anders start je site niet.

Node heeft nu een eigen module: node:sqlite. Die zit in Node zelf, dus er is niets te installeren en niets te bouwen. In Node 24 werkt hij zonder vlag. Officieel heet hij nog release candidate, net niet stabiel.

In Nuxt maak je de verbinding één keer, in server/utils. Nitro importeert wat daar staat vanzelf in je API-routes.

// server/utils/db.js
import { DatabaseSync } from 'node:sqlite'

export const db = new DatabaseSync('/var/data/site.db')
db.exec('PRAGMA journal_mode = WAL')

// server/api/posts/[slug].get.js
export default defineEventHandler((event) => {
  const slug = getRouterParam(event, 'slug')
  return db.prepare('SELECT title, body FROM posts WHERE slug = ?').get(slug)
})

Met WAL hoeft lezen niet te wachten tot een schrijfactie klaar is. Je zet het één keer aan, daarna blijft het in het bestand staan.

Zet het bestand buiten je build

Bij een deploy wordt de map met de gebouwde site, .output, vaak in zijn geheel vervangen. Staat je database daarin, dan ben je hem na de volgende deploy kwijt. Zet het bestand daarom in een vaste map buiten je build, zoals /var/data.

Back-ups

Een back-up is een kopie van één bestand. Kopieer het alleen niet zomaar terwijl de site draait. Dan kan de kopie midden in een schrijfactie vallen. Laat SQLite zelf een schone kopie maken:

VACUUM INTO '/var/backups/site-2026-07-03.db'

Het doelbestand mag nog niet bestaan, dus zet de datum in de naam. Ik doe veel met Ploi, ook de back-ups: Ploi zet de kopie op opslag buiten de server.

Waar het ophoudt

SQLite houdt op als je site op meerdere servers moet draaien, met loadbalancing ervoor. Het bestand staat op één server, en een tweede server kan er niet veilig bij. Dan heb je een databaseserver nodig, zoals PostgreSQL of MySQL.