SQLite vs DuckDB : quelle base locale choisir en 2026 ?

Si vous avez suivi le monde des bases de données ces deux dernières années, vous avez vu un schéma étrange : les deux bases les plus intéressantes des années 2020 sont toutes deux embarquées. Pas de serveur à installer, pas de démon à lancer, pas de chaîne de connexion vers un hôte distant. Ce sont des bibliothèques que vous liez à votre processus, et elles lisent et écrivent un fichier sur votre disque.

SQLite, évidemment — c'est la base embarquée par défaut depuis deux décennies, et elle est sur plus d'appareils que n'importe quelle autre base de l'histoire. Mais le nouveau venu, c'est DuckDB, un moteur analytique embarqué qui a explosé en popularité quand les gens ont réalisé qu'on pouvait faire tourner une base OLAP colonnaire et vectorisée sur un seul fichier, sans aucune infrastructure.

La partie déroutante, c'est qu'elles se ressemblent presque de l'extérieur. Toutes deux sont « un fichier qu'on interroge en SQL ». Toutes deux zéro-installation. Toutes deux utilisées par les data engineers, le monde du ML et les développeurs indie. Et pourtant elles sont optimisées pour des jobs complètement différents — choisir la mauvaise signifie se battre avec sa base plutôt que l'utiliser. Voici un cadre qui est réellement utile.

La différence en une phrase

SQLite est une base OLTP : elle est faite pour les transactions — beaucoup de petites lectures et écritures, des recherches de lignes individuelles, des apps qui ont besoin d'un stockage durable et requêtable sur une seule machine.

DuckDB est une base OLAP : elle est faite pour l'analytique — de gros scans, des agrégations sur des millions de lignes, des jointures entre grandes tables, des requêtes qui calculent des réponses à partir de beaucoup de données d'un coup.

C'est toute la distinction, et presque tout le reste — caractéristiques de performance, cas d'usage, modes de défaillance — en découle.

Là où SQLite gagne

SQLite est un stockage orienté ligne, optimisé pour la charge d'une base applicative : trouver une ligne par clé, insérer une ligne, mettre à jour une ligne, committer. C'est réglé pour ça depuis 25 ans, et ça se voit.

C'est la bonne base pour une app. Si vous construisez une application local-first — un outil de bureau, une app mobile, un plugin, un jeu, une app de notes, tout ce où les données vivent sur la machine de l'utilisateur — SQLite est la réponse. Elle gère les lectures concurrentes et les transactions mono-écrivain avec les garanties ACID, elle est embarquée dans tous les OS, et c'est le code le plus éprouvé du monde des bases. Les données opérationnelles de votre app — les commandes, utilisateurs, réglages et états que votre logique applicative lit et écrit sans cesse — appartiennent à SQLite.

C'est la meilleure écosystème des petites bases. Chaque langage a un driver de premier ordre. Il y a des outils GUI pour chaque plateforme. C'est le défaut d'iOS, Android, des navigateurs (via le moteur d'IndexedDB) et de la plupart des frameworks desktop. On ne choisit pas SQLite parce que c'est chic ; on la choisit parce qu'elle est partout et que ça marche.

Elle est géniale comme source de vérité d'une app. C'est le cas d'usage clé pour moi : SQLite est là où vit l'état courant de votre application — les lignes que votre code lit et écrit chaque jour. C'est la base sur laquelle votre app tourne, pas celle sur laquelle vous faites tourner des rapports.

Là où DuckDB gagne

DuckDB est un moteur colonnaire et vectorisé. Au lieu de stocker les lignes de façon contiguë et de les scanner, elle stocke les colonnes, utilise la vectorisation CPU moderne, et peut traiter des millions de lignes par seconde sur un laptop. Ce design en fait une base OLTP terrible et un moteur analytique phénoménal.

C'est la bonne base pour l'analyse. Si vous faites du travail de données — interroger un gros CSV, explorer un fichier Parquet, agréger des logs, calculer des métriques sur un an d'événements, construire un pipeline local — DuckDB est la réponse. Elle interroge les fichiers en place : vous pouvez exécuter du SQL directement sur un CSV ou un Parquet sans rien importer, ce qui est la fonctionnalité qui en a fait l'outil par défaut pour « j'ai un gros fichier et j'ai besoin de réponses ».

Elle est conçue pour la stack data moderne. Parquet, Arrow, Polars, Pandas — DuckDB s'y insère partout. Vous pouvez charger un Parquet dans une table DuckDB, ou l'interroger directement, ou écrire le résultat d'une requête dans un Parquet. Pour les data engineers, c'est le plus proche d'un couteau suisse qui existe.

C'est du SQL comme calculatrice, pas comme stockage. Le modèle mental est différent : avec DuckDB, vous calculez généralement quelque chose — « quelle est la durée moyenne de session sur ces 40 millions d'événements ? » — plutôt que de stocker quelque chose. C'est pour ça qu'elle est colonnaire : le stockage colonnaire est rapide pour lire beaucoup de valeurs d'une même colonne, ce qui est exactement ce que font les agrégations.

Le milieu déroutant : de la petite analytique sur SQLite, ou des apps sur DuckDB ?

C'est là que les conseils deviennent vaseux, et je veux être précis.

« Je vais juste utiliser SQLite pour mon analytique — c'est plus simple. » Vous pouvez, et pour de petites données ça marche bien. Mais dès que votre analyse touche des centaines de milliers de lignes ou joint quelques tables, le design orienté ligne commence à vous coûter. Un GROUP BY sur un million de lignes dans SQLite est lent non parce que SQLite est mauvais, mais parce qu'elle lit ligne par ligne ce qu'un moteur colonnaire lit colonne par colonne. Si votre habitude de « petite analyse rapide » devient une vraie charge de travail, DuckDB sera un ordre de grandeur plus rapide avec le même SQL.

« DuckDB peut être la base de mon app ? » Techniquement oui — elle supporte les transactions et l'écriture. Pratiquement, non. DuckDB est faite pour les opérations en masse ; les écritures ligne par ligne et les recherches ponctuelles sont exactement ce qu'elle fait le moins bien. Une app qui fait de fréquentes petites lectures/écritures sur DuckDB se sentira lente d'une façon que SQLite ne fait jamais. Utilisez le bon outil : SQLite stocke l'état de votre app, DuckDB l'analyse.

Le schéma qui marche vraiment : les deux

Voici ce que les gens ratent : ce ne sont pas des concurrentes, c'est un pipeline. La configuration la plus courante que je vois bien fonctionner en 2026 est :

1. SQLite est la source de vérité de votre app. L'état courant — commandes, utilisateurs, config — vit dans SQLite, écrit transactionnellement par votre application.
2. DuckDB l'analyse. Vous pointez DuckDB vers le fichier SQLite — elle peut lire les bases SQLite directement via l'extension sqlite — et vous lancez les grosses agrégations, les jointures, les comparaisons d'une année sur l'autre. Des millions de lignes, à la vitesse d'un laptop, zéro infrastructure.

Pas d'étape d'export. Pas d'ETL. Pas de second serveur. Le moteur analytique lit la base applicative en place. C'est, honnêtement, le cas d'usage tueur des deux en un.

Le même schéma se généralise : DuckDB lit aussi Parquet et CSV en place, donc elle devient l'outil unique pour « interroger tout ce que j'ai, où qu'il vive » pendant que SQLite reste l'outil unique pour « stocker l'état dont mon app a besoin ».

Comment décider : trois questions

Posez-vous ces questions dans l'ordre, et vous tomberez sur la bonne à chaque fois.

1. Ces données sont-elles écrites et lues par une application, ligne par ligne, toute la journée ? Oui → SQLite. C'est une charge OLTP et c'est à ça que sert SQLite. Si non — c'est un fichier que vous analysez — passez à la question 2.

2. Vos requêtes sont-elles surtout des agrégations, des scans et des jointures sur beaucoup de lignes ? Oui → DuckDB. C'est une charge OLAP et c'est à ça que sert DuckDB. GROUP BY, fonctions de fenêtre, grosses lectures — DuckDB humiliera un stockage en ligne là-dessus.

3. Les données sont-elles petites et les requêtes simples ? Alors honnêtement, l'une ou l'autre fonctionne — prenez SQLite s'il y a la moindre chance que ça devienne une base applicative, prenez DuckDB si les données sont des fichiers (CSV/Parquet) qui continuent d'arriver. Pour de la vraie petite analyse, la différence est du bruit ; pour tout ce qui grandit, la différence est structurelle.

Ce que ça veut dire pour vos outils locaux

Il y a une conséquence pratique sur la façon dont vous travaillez avec ces fichiers, et c'est la partie qui me concerne comme quelqu'un qui construit Basevolt, un outil de base de données desktop. L'outil compte autant que le moteur. Une GUI SQLite qui vous laisse parcourir, éditer et configurer des relations sur votre fichier .db est essentielle pour la moitié applicative du schéma. Un notebook ou une CLI qui pointe DuckDB vers vos fichiers gère la moitié analytique. Savoir dans quelle moitié vous êtes vous dit quel outil — et quel moteur — prendre.

Si vous stockez de l'état applicatif, arrêtez d'essayer de faire faire du stockage aux outils d'analyse, et gardez-le dans SQLite. Si vous analysez des données, arrêtez d'essayer de faire faire de l'analytique à un stockage en ligne, et laissez DuckDB scanner. Les deux moitiés de votre stack cesseront de vous résister dès que chacune fera le job pour lequel elle a été construite.