TypeDB : base de données fortement typée en Rust

Contexte

Les équipes qui conçoivent des systèmes métier complexes hésitent souvent sur le choix de la base de données. Les bases relationnelles offrent une grande expressivité, mais les requêtes s'allongent dès que les données s'imbriquent et que les liens plusieurs-à-plusieurs se multiplient. Les bases documentaires sont souples, mais reportent sur l'application la charge de la cohérence. Les bases graphes expriment bien les connexions, mais leurs contraintes de types restent souvent lâches. TypeDB se place dans cet interstice.

Le projet, écrit en Rust, se présente comme une base conçue « pour les systèmes, pas pour les enregistrements ». Selon lui, les données du monde réel ne sont pas des lignes isolées, mais un réseau de structures dépendantes et héritées. Son but affiché est de rapprocher les bases de données des langages typés modernes, avec un code clair, intuitif et maintenable. Les sujets du dépôt, inference, knowledge-representation, logic, polymorphism et reasoning, confirment cette ambition. Le dépôt GitHub compte 4482 étoiles, un blog officiel et un serveur Discord.

Analyse approfondie

Le cœur de TypeDB est son schéma. Il repose sur un système de types moderne, gère nativement l'héritage et les interfaces, et suit une logique de modélisation conceptuelle. Les types définis par l'utilisateur héritent de trois types racines : les entités, les relations et les attributs. Une entité est un objet qui existe par lui-même. Une relation dépend de « rôles », qui jouent le rôle d'interfaces et que peuvent tenir des entités, voire d'autres relations. Un attribut est une caractéristique porteuse de valeur, qu'une entité ou une relation peut posséder.

L'exemple du README illustre bien l'idée. Il définit d'abord des attributs comme full-name et id. Puis email et employee-id héritent de id. Viennent ensuite deux entités, user et employee, contraintes par des annotations telles que @unique et @key. Enfin, une relation mentorship déclare deux rôles, mentor et trainee, que différentes entités peuvent tenir. Ce style inscrit directement dans les types qui possède quoi et qui joue quel rôle. Il évite de simuler ces liens avec des clés étrangères et des tables de jointure.

En quoi TypeQL diffère-t-il de SQL ? TypeQL, le langage de requête de TypeDB, est déclaratif, fonctionnel et fortement typé. Les requêtes sont soumises au même système de types que le schéma, si bien que les erreurs apparaissent plus tôt. Les données très imbriquées et fortement connectées demandent moins d'efforts. Le projet met aussi l'accent sur l'inférence : la base peut déduire des conclusions implicites à partir de règles logiques au moment de la requête, au lieu de renvoyer seulement ce qui a été stocké. Le prix à payer est réel : TypeQL est un langage neuf, et les équipes doivent passer des réflexes SQL à un raisonnement par types et par rôles.

Impact sur l'industrie

TypeDB propose deux voies d'entrée : un déploiement dans le cloud, ou le téléchargement de l'édition communautaire (Community Edition) pour l'installer soi-même. Pour un essai rapide, le guide Get Started, la documentation des concepts TypeDB et celle des concepts TypeQL forment une progression claire, des bases vers les types et les requêtes. Le projet fournit aussi des pilotes pour plusieurs langages et l'interface graphique TypeDB Studio, ce qui évite de tout faire en ligne de commande.

Le parcours type consiste à dessiner le domaine métier en entités, relations et attributs, à écrire le schéma avec des instructions define, puis à interroger en TypeQL. Les organigrammes, les relations mentor-stagiaire, les droits et ressources, les chaînes d'approvisionnement ou les graphes de connaissances ont des hiérarchies naturelles et des rôles multiples. Ils s'accommodent mieux de ce modèle que de clés étrangères forcées dans des tables.

Pour la communauté des développeurs, cette voie rapproche la conception conceptuelle de la structure de stockage finale. Elle réduit la perte de traduction entre le modèle mental et les tables réelles. Pour les équipes d'ingénierie, le typage et les requêtes déclaratives peuvent abaisser le coût de maintenance des applications de données complexes. Les risques existent toutefois : l'écosystème et la base d'utilisateurs restent petits face aux bases relationnelles matures, le recrutement, l'expérience d'exploitation et l'outillage tiers demandent du temps, et les actifs SQL existants ne se réutilisent pas directement.

Perspectives

L'intérêt d'adopter TypeDB dépend d'une question simple : vos données sont-elles vraiment complexes, interconnectées et polymorphes ? Si oui, un modèle fortement typé avec rôles et héritage peut épargner beaucoup d'efforts. Si vos données tiennent dans des tables ordinaires, le coût d'apprentissage risque de ne pas se justifier.

Trois points méritent d'être suivis. Le premier est le comportement du moteur d'inférence sous charge réelle de production : la source décrit cette capacité sans fournir de chiffres de performance, la question reste donc ouverte. Le deuxième est la frontière fonctionnelle entre le service cloud et l'édition communautaire. Le troisième est la capacité de TypeDB à devenir une base pour la mémoire à long terme et le raisonnement relationnel dans les bases de connaissances et les applications d'agents. Si ces pistes avancent bien, TypeDB pourrait devenir une branche très identifiable de la famille des bases de données.