Avez-vous déjà pensé au fait que le navigateur que vous ouvrez chaque jour, le logiciel de communication sur votre téléphone et même l’outil de prise de notes sur votre bureau cachent tous cette même base de données légère ?

Elle ne nécessite l’installation d’aucun logiciel serveur, ne requiert aucune configuration de compte ou de mot de passe, et n’a même pas besoin d’une connexion Internet. C’est simplement un fichier, qui repose tranquillement sur votre disque dur, prêt à vous servir à tout moment.

Cette existence discrète, c’est SQLite.

Qu’est-ce que SQLite ? La base de données la plus déployée au monde

SQLite est un moteur de base de données relationnelle embarqué écrit en C.

Il n’a pas de processus serveur indépendant, mais est directement embarqué dans votre application pour s’exécuter.

C’est complètement différent de PostgreSQL ou MySQL avec lesquels vous êtes familier. Les bases de données traditionnelles sont des serveurs indépendants qui s’exécutent séparément, et votre programme doit “communiquer” avec eux via un protocole réseau (TCP/IP).

But SQLite est différent ; c’est simplement un bloc de code, s’exécutant directement au sein de votre application, lisant et écrivant ce fichier .db sur votre disque dur.

C’est précisément en raison de cette caractéristique “plug-and-play” que SQLite est devenu le moteur de base de données le plus déployé au monde.

Des systèmes d’exploitation Android et iOS, aux navigateurs Chrome et Firefox, en passant par Adobe Lightroom, WhatsApp et même le système de vol de l’Airbus A350, il est partout.

Utiliser SQLite dans Node.js

Si vous êtes un développeur Node.js, utiliser SQLite est extrêmement simple. Vous n’avez pas besoin d’installer de logiciel de serveur de base de données sur votre ordinateur, il vous suffit d’installer un paquet npm pour commencer.

Les options les plus couramment utilisées dans l’industrie aujourd’hui :

Créer une base de données et l’interroger avec better-sqlite3 prend moins de cinq minutes :

const Database = require('better-sqlite3');
const db = new Database('my_project.db');

db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();

const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);

const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }

Si le fichier n’existe pas, better-sqlite3 le créera automatiquement pour vous.

SQLite prend en charge une syntaxe SQL plus puissante que vous ne le pensez

Beaucoup de gens pensent que SQLite est très basique, mais il prend en charge la grande majorité de la syntaxe SQL standard, y compris de nombreuses fonctionnalités avancées :

La philosophie centrale de SQLite est “petit et beau”, prenant en charge la plupart des capacités SQL dont vous avez besoin au quotidien tout en restant extrêmement léger.

Où sont les limites de SQLite ?

La légèreté a un prix. Si l’on compare SQLite à une épicerie hipster avec une seule caisse, alors PostgreSQL est un Costco équipé de 50 caisses.

1. Embouteillage d’écriture

Lorsque SQLite écrit des données, il verrouille l’intégralité du fichier de base de données.

Imaginez un restaurant avec une seule toilette : 100 personnes peuvent regarder le menu à l’extérieur (lire) en même temps, mais tant qu’une personne y entre et verrouille la porte (écrire), toutes les autres ne peuvent que faire la queue et attendre.

Bien que l’activation du mode WAL (Write-Ahead Logging) puisse améliorer les performances de lecture/écriture simultanées, il reste fondamentalement impossible d’effectuer des écritures simultanées multi-thread sur différentes lignes de données.

2. Impossible de s’étendre sur plusieurs serveurs

L’essence de SQLite est un fichier physique. Si votre système est déployé sur plusieurs serveurs (mise à l’échelle horizontale), ces serveurs ne peuvent pas partager le même fichier en toute sécurité.

3. Manque de gestion des permissions détaillée

SQLite n’a pas de concept de “comptes d’utilisateurs”. Quiconque peut lire ce fichier .db au niveau du système d’exploitation peut voir et modifier toutes les données.

Pour les systèmes d’entreprise qui nécessitent des audits stricts des données personnelles, c’est inacceptable.

SQLite vs. PostgreSQL : Décisions de sélection technologique

Les outils ne sont ni bons ni mauvais, ils sont seulement adaptés ou non. Voici une liste de contrôle ultime pour vous aider à prendre une décision :

Comparations de scénarios plus spécifiques :

Votre base de données est-elle un bloc-notes de poche ou un standard téléphonique central ?

Si les données sont de type “monoposte, statiques, propriétaire unique”, choisissez SQLite pour profiter d’une légèreté et d’une liberté extrêmes ;

Si les données sont de type “cloud, dynamiques, hautement interactives”, laissez PostgreSQL prendre le relais.

La philosophie centrale de SQLite est “un composant interne de l’application”, tandis que PostgreSQL est positionné comme “un centre indépendant de l’architecture du système”.

La prochaine fois que vous prendrez une décision d’architecture, ne vous précipitez pas pour sortir PostgreSQL. Demandez-vous d’abord :

“Ma base de données est-elle un bloc-notes de poche, ou un standard téléphonique central ?”

Une fois la réponse claire, le choix s’impose naturellement.

Reference

• Query Language Understood by SQLite
• SQLite Documentation
• SQLite Tutorial - An Easy Way to Master SQLite Fast
• SQLite - Wikipedia