## SQLite est déjà chez moi
Mon portfolio stocke son contenu dans une base SQLite. Les projets, les articles et les données utilisées par mon panneau d’administration vivent dans un fichier sur mon VPS.
Pour y accéder, je passe par Prisma. C’est une couche supplémentaire entre mon code Next.js et SQLite, mais elle a une fonction claire : mes accès à la base suivent les modèles du projet et restent dans le même environnement TypeScript que le reste de l’application.
Node.js propose maintenant une autre option. Le module `node:sqlite` permet d’ouvrir une base, de préparer des requêtes et d’exécuter directement du SQL sans installer de pilote séparé. Depuis Node.js 25.7, il est classé release candidate. Ce changement a aussi été intégré à la version LTS avec Node.js 24.15.0. (nodejs.org)
Sur le papier, c’est exactement le genre de nouveauté qui m’intéresse. Une dépendance en moins. Une couche en moins. Un accès direct à un format que j’utilise déjà.
Mais retirer une couche n’est utile que si je ne retire pas aussi ce qu’elle faisait pour moi.
## Le module natif remplace le pilote, pas mon modèle
Avec node:sqlite, je peux écrire quelque chose de très court :
import { DatabaseSync } from "node:sqlite";
const db = new DatabaseSync("portfolio.db");
const projects = db.prepare("SELECT * FROM projects").all();C’est lisible. Je sais exactement quelle requête part vers SQLite. Pour un script isolé ou une petite base avec quelques opérations fixes, cette proximité avec le SQL me plaît.
Mon portfolio ne se limite cependant pas à ouvrir un fichier et lire une table. Son panneau d’administration crée et modifie du contenu. Les routes manipulent plusieurs structures. La validation avec Zod protège les entrées, puis Prisma fournit le passage entre ces données et la base.
Le client généré par Prisma est conçu comme un query builder typé à partir du schéma. Les types utilisés par les requêtes suivent donc les modèles déclarés. node:sqlite, lui, exécute le SQL que je lui donne. C’est volontairement plus bas niveau. (docs.prisma.io)
Je pourrais reconstruire la couche manquante avec mes propres fonctions TypeScript. Une fonction pour créer un article. Une autre pour mettre à jour un projet. Des types pour chaque résultat. Du code pour maintenir la correspondance entre les colonnes SQLite et les objets utilisés par Next.js.
Ce serait possible. Ce serait aussi remplacer une dépendance maintenue par une couche maison que je devrais maintenir moi-même.
Je possède déjà le serveur, le déploiement, le panneau d’administration et le CSS. Je n’ai pas besoin de posséder également un mini ORM juste pour pouvoir dire que ma base utilise uniquement les modules natifs de Node.
## Je ne migre pas le portfolio
Je garde donc Prisma sur le portfolio.
Ce choix ne vient pas d’un rejet de node:sqlite. Au contraire, son passage en release candidate le fait entrer dans la liste des outils que je peux réellement envisager. Mais il ne remplace pas la même chose.
Dans mon projet actuel, enlever Prisma toucherait tous les accès aux données pour un bénéfice difficile à mesurer. La base resterait le même fichier SQLite sur le même VPS. Le panneau d’administration ferait les mêmes opérations. Le déploiement conserverait Next.js et pm2. J’aurais surtout déplacé de la complexité depuis une dépendance vers mon propre dépôt.
La situation serait différente pour un nouvel outil Node très petit. Quelques tables. Peu de requêtes. Aucun besoin de générer un client depuis un schéma. Dans ce cas, commencer directement avec node:sqlite éviterait d’installer Prisma par réflexe.
Je ne vais pas utiliser le portfolio comme terrain de migration. Mon prochain test sera séparé : une base temporaire, quelques requêtes préparées et une vérification du comportement avec TypeScript. Si l’API reste suffisante sans que je commence à recréer une couche de modèles, elle aura sa place dans un petit projet. Sinon, Prisma restera la dépendance qui m’évite d’écrire cette couche moi-même.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.