FlinDB vs SQLite : pourquoi nous avons construit le nôtre

« Pourquoi ne pas simplement utiliser SQLite ? »

Nous avons entendu cette question dès le premier jour. Et c'est une question juste. SQLite est le moteur de base de données le plus déployé au monde. Si vous avez besoin d'une base de données embarquée, SQLite est le choix évident.

Nous avons choisi de construire le nôtre quand même. Cet article explique pourquoi.

Où ils se chevauchent

Le problème du voyage dans le temps

SQLite ne suit pas l'historique. Un UPDATE écrase la valeur précédente. Construire des requêtes temporelles par-dessus SQLite nécessite des centaines de lignes de triggers SQL pour chaque table.

Dans FlinDB :

flinuser_then = User.find(1) @ "2025-06-15"
user_now = User.find(1)

if user_then.email != user_now.email {
    log("Email changed since June 15th")
}

Le problème de la recherche sémantique

SQLite a FTS5 pour la recherche plein texte. Il ne comprend pas le sens. FlinDB a une recherche sémantique intégrée avec des embeddings vectoriels :

flinentity Product {
    name: text
    description: semantic text
}

results = search "comfortable seating for work" in Product by description

Le problème de la sécurité des types

SQLite a un typage notoirement lâche. FlinDB applique les types au niveau du schéma.

Le problème du langage de requête

SQL est une chaîne embarquée dans un autre langage. Les requêtes FlinDB sont des expressions FLIN. Elles sont vérifiées par le compilateur. Elles ne peuvent pas être injectées.

L'évaluation honnête

SQLite est meilleur que FlinDB pour être une base de données SQL embarquée à usage général. Il a 25 ans de tests en conditions réelles et des milliards de déploiements.

FlinDB est meilleur que SQLite pour être le moteur de stockage des applications FLIN. Il parle nativement le langage. Il fournit des fonctionnalités que SQLite n'a pas (versionnage temporel, recherche sémantique, abonnements en temps réel, verrouillage au niveau des lignes). Il élimine des catégories entières de configuration que SQLite nécessite.

Nous n'avons pas construit FlinDB parce que SQLite est mauvais. Nous l'avons construit parce que FLIN a besoin d'une base de données conçue pour FLIN.

Ceci est la partie 14 de la série « How We Built FlinDB ».

Navigation de la série : - [067] Tree Traversal and Integration Testing - [068] FlinDB Hardening for Production - [069] FlinDB vs SQLite: Why We Built Our Own (vous êtes ici) - [070] Persistence in the Browser