Chaque framework web existant vous oblige à configurer une base de données avant de pouvoir stocker un seul enregistrement. Installer PostgreSQL. Configurer les chaînes de connexion. Écrire des migrations. Configurer un ORM. Gérer les identifiants. C'est un rituel si profondément ancré que la plupart des développeurs ne le remettent jamais en question.
Nous l'avons remis en question.
Quand Thales a posé la vision de FLIN -- un langage de programmation conçu pour éliminer la complexité accidentelle -- la base de données fut la première cible. Pas parce que les bases de données sont mauvaises, mais parce que la cérémonie qui les entoure est absurde. Un développeur qui écrit save user ne devrait pas avoir besoin de passer une heure à configurer de l'infrastructure d'abord. Les données devraient simplement persister.
Voici l'histoire de FlinDB : la base de données embarquée native de FLIN, construite à partir de zéro en Rust, nécessitant zéro configuration, zéro chaîne de connexion et zéro migration.
L'architecture : deux couches, une expérience
FlinDB est divisée en deux couches distinctes. La couche utilisateur parle FLIN. La couche interne est ZeroCore, un moteur de stockage écrit en Rust qui gère la mécanique de la persistance, de l'indexation, du versionnage et de la récupération.
+---------------------------------------------------------+
| FlinDB (Product Layer) |
| |
| What users interact with: |
| - entity definitions |
| - save / delete commands |
| - queries (where, find, all) |
| - temporal queries (@) |
| - semantic search |
+---------------------------------------------------------+
| ZeroCore Engine (Internal) |
| |
| Implementation details: |
| - Storage format |
| - Indexing |
| - Version management |
| - Vector embeddings |
| - Disk persistence |
| |
| File: src/database/zerocore.rs |
+---------------------------------------------------------+Définition d'entité : pas de fichiers de schéma, pas de migrations
Dans FLIN, on définit les structures de données avec le mot-clé entity, directement dans le code applicatif :
flinentity User {
name: text
email: text
age: int
}C'est toute la « configuration de base de données ». Quand ZeroCore rencontre cette définition d'entité, il crée automatiquement le stockage, assigne des identifiants uniques, suit les horodatages de création et mise à jour, maintient un historique complet des versions et indexe la clé primaire.
Chaque entité reçoit automatiquement quatre champs système :
flinuser = User.find(1)
user.id // 1 (auto-generated)
user.created_at // 2026-01-13T10:00:00Z
user.updated_at // 2026-01-13T14:30:00Z
user.version // 3Le moteur ZeroCore
ZeroCore est le moteur Rust qui fait tout fonctionner :
rustpub struct ZeroCore {
schemas: HashMap<String, EntitySchema>,
data: HashMap<String, HashMap<EntityId, Vec<VersionedEntity>>>,
indexes: HashMap<String, Index>,
vectors: VectorStore,
storage: Storage,
}Cinq champs. Schémas, données, index, vecteurs et stockage. Chaque opération est une méthode sur ce struct.
Stockage sur disque
FlinDB stocke tout dans un répertoire .flindb/ à côté de l'application FLIN :
.flindb/
+-- wal.log # Write-ahead log
+-- lock # Process lock file
+-- meta.json # Database metadata
+-- data/
| +-- Todo.flindb # All Todo records
| +-- User.flindb # All User records
+-- schema.flindb # Persisted entity schemas
+-- semantic/ # Vector embeddingsLe journal d'écriture anticipée (WAL) est la source de vérité entre les points de contrôle. C'est la même architecture utilisée par PostgreSQL et SQLite.
L'expérience développeur
flinentity Todo {
title: text
done: bool = false
created: time = now
priority: int = 1
}
// Create
todo = Todo { title: "Ship FlinDB article", priority: 3 }
save todo
// Read
all_todos = Todo.all
urgent = Todo.where(priority > 2)
first_todo = Todo.find(1)
// Update
first_todo.done = true
save first_todo
// Delete
delete first_todoPas d'installation. Pas de configuration. Pas de chaîne de connexion. Pas de migration. Pas d'import. La base de données est simplement là, intégrée au langage.
Pourquoi ne pas simplement utiliser SQLite ?
La réponse courte : SQLite est une base de données relationnelle avec SQL comme interface. FlinDB est une base de données temporelle, orientée entités, avec FLIN comme interface. Elles résolvent des problèmes différents.
Pas de versionnage temporel. SQLite ne suit pas l'historique des entités.
Pas de recherche sémantique. SQLite a FTS5 pour la recherche plein texte, mais pas d'embeddings vectoriels.
Pas d'abonnements en temps réel. FlinDB supporte la syntaxe watch.
SQL est la mauvaise interface pour FLIN. Faire écrire des chaînes SQL aux développeurs FLIN serait une contradiction.
Nous couvrons la comparaison complète dans l'article 069 de cette série.
Ce qui a rendu la configuration zéro possible
Convention plutôt que configuration. La base de données vit toujours à .flindb/. Les schémas d'entités sont dérivés du code.
Évolution automatique des schémas. Quand un développeur ajoute un champ à une entité, ZeroCore détecte le changement et le gère. Pas de fichier de migration.
Des valeurs par défaut raisonnables. Le mode WAL est activé. Les points de contrôle automatiques se déclenchent à 1 000 entrées ou 10 Mo. La suppression douce est le défaut.
Ceci est la partie 1 de la série « How We Built FlinDB », documentant comment nous avons construit un moteur de base de données embarqué complet pour le langage de programmation FLIN.
Navigation de la série : - [056] FlinDB: Zero-Configuration Embedded Database (vous êtes ici) - [057] Entities, Not Tables: How FlinDB Thinks About Data - [058] CRUD Without SQL - [059] Constraints and Validation in FlinDB - [060] Aggregations and Analytics