- Turso relie un frontend compatible Postgres à son cœur de base de données écrit en Rust, et étend ainsi son architecture façon LLVM des bases de données, où un même moteur d’exécution traite plusieurs langages de base de données
- Le SQL Postgres est analysé en un AST commun puis compilé en bytecode VDBE ;
pgmicro, qui a servi à valider la faisabilité, a été fusionné dans la branche principale comme base officielle de développement - Le cœur existant prend déjà en charge la compatibilité avec les fichiers SQLite, l’écriture concurrente via MVCC, l’exécution asynchrone, un système de types riche et des vues matérialisées à mise à jour automatique, avec une fiabilité vérifiée par plusieurs techniques de test
- Il est conçu pour s’exécuter de façon embarquée ou sous forme de fichier unique dans le navigateur, sur mobile et sur divers appareils, tout en permettant aux applications existantes, aux ORM et à
psqlde se connecter via le protocole wire Postgres - Plutôt que de viser une correspondance à 100 %, le projet se concentre sur les fonctionnalités centrales largement utilisées afin d’exécuter la majorité des applications existantes sans modification, tout en étudiant l’usage de WASM et d’une couche de compatibilité pour les extensions et PL/pgSQL, le tout sous licence MIT
Pourquoi construire Postgres sur Turso
- Turso est un cœur de base de données moderne écrit en Rust, sur lequel un moteur compatible Postgres est construit from scratch
- L’objectif à long terme n’est pas de simplement porter Postgres existant en Rust, mais de créer une nouvelle base de données avec une architecture moderne
- pas de processus séparé par connexion
- exécution embarquée possible dans le navigateur
- gestion d’une base de données sous forme de fichier unique
- mise à jour automatique des vues matérialisées sans tâche dédiée
- Le projet vise une architecture de compilation interchangeable reliant plusieurs frontends à un même cœur stable
- SQLite est le premier frontend
- Postgres est le prochain frontend officiel
- d’autres frontends comme MySQL, Redis ou des bases expérimentales pourront être ajoutés plus tard
- Le résultat actuel n’est pas encore un produit fini, mais une base de développement fonctionnelle
D’une réimplémentation de SQLite à un cœur de base de données commun
- Turso était à l’origine un projet de réimplémentation complète de SQLite en Rust avec une architecture moderne, tout en conservant la compatibilité des fichiers pour ouvrir et créer des fichiers SQLite
- Il offre déjà des fonctionnalités qui dépassent le périmètre de SQLite
- prise en charge de l’écriture concurrente via MVCC comme Postgres
- système de types riche comparable à celui de Postgres
- fonctionnement entièrement asynchrone, adapté autant au natif qu’aux environnements contraints comme le navigateur
- mise à jour automatique en temps réel des vues matérialisées, sans
REFRESH MATERIALIZED VIEW, cron ni combinaison de triggers
- L’ajout d’un frontend Postgres ne change pas les objectifs initiaux de Turso et SQLite
- poursuivre la compatibilité complète avec SQLite et l’extension des fonctionnalités pour les charges de travail futures
- accélérer le développement en réutilisant aussi les tests Postgres lors de l’implémentation des fonctions nécessaires
Fiabilité et modèle de contribution ouvert
- Pour reproduire la robustesse de SQLite, la fiabilité est traitée comme une fonctionnalité produit
- usage de tests de simulation déterministes
- exécution de tests Antithesis
- recours également à des tests oracle, au fuzzing et à des méthodes formelles
- Turso compte actuellement plus de 260 contributeurs et adopte un mode de contribution ouverte (Open Contribution) qui permet aux personnes externes de participer à l’orientation du projet
- L’objectif est un environnement de type noyau Linux, centré sur le code et sur des exigences de qualité élevées, où les contributeurs réguliers participent aussi aux décisions du projet
- Les contributions rédigées par IA sont acceptées, mais elles doivent atteindre un niveau de qualité suffisant ; le code doit être examiné attentivement par des humains qui comprennent l’architecture
La machine virtuelle VDBE au cœur de SQLite
- SQLite n’est pas une simple couche exécutant directement le SQL : il compile le SQL de son dialecte en bytecode VDBE, exécuté ensuite par une machine virtuelle
- Le VDBE n’est pas un bytecode générique comme la JVM, .NET ou WASM ; il fournit des opérations de haut niveau spécialisées pour les bases de données, comme
trouver un élément dans un B-tree - Ce langage de bytecode n’a ni spécification publique ni interface modulaire exposée, mais il existe réellement à l’intérieur de SQLite, et Turso reprend cette même conception
- Pour valider la généricité du VDBE de Turso, l’équipe a transformé Doom à l’aide d’un petit compilateur C-vers-VDBE
- le véritable moteur Turso est compilé en WASM et exécute le bytecode VDBE de Doom dans un onglet de navigateur
- Doom s’exécute comme la base de données traite un
SELECT - chaque frame est traitée comme une ligne de résultat
- les zones mémoire sont représentées comme des blobs lisibles et modifiables
- l’implémentation est visible dans le dépôt turso-vdbe-doom-example
L’architecture de compilation du frontend Postgres
- Les tentatives précédentes de combinaison entre SQLite et Postgres reposaient surtout sur une traduction de couche de requêtes, convertissant des requêtes Postgres en requêtes SQLite, en raison de la structure monolithique de SQLite, avec une forte inadéquation entre les comportements externes des deux bases
- En interne, la plupart des bases SQL réalisent des opérations fondamentales similaires autour de B-trees et d’ensembles d’index
- Il existe toutefois des différences nettes entre les structures de stockage de Postgres et de SQLite
- Postgres stocke les lignes dans des fichiers heap avec des index B-tree séparés, des versions de tuples, des TID et du vacuum
- SQLite regroupe les données dans des B-trees
- Ces différences tiennent surtout à la manière dont les octets sont organisés sur disque ; les opérations nécessaires à Postgres peuvent être représentées dans le VDBE existant ou prises en charge en étendant ses instructions
- La nouvelle architecture permet de remplacer le frontend de base de données
- analyser le langage Postgres en un AST commun
- compiler l’AST en bytecode Turso
- exécuter ce bytecode dans le cœur commun de Turso
- L’expérimentation initiale qui a validé la faisabilité a été menée avec pgmicro, puis fusionnée dans la branche principale de Turso pour devenir un projet officiel
Formes d’exécution et cas d’usage
- L’objectif est de proposer le même SQL Postgres et le même comportement de base de données sous plusieurs formes, sans serveur
- exécuter une véritable base compatible Postgres dans un onglet de navigateur
- permettre à des agents de créer une nouvelle base par utilisateur et de la gérer comme un fichier unique
- permettre à des applications local-first de télécharger les données Postgres sous forme de fichier unique puis de les resynchroniser
- fonctionner en mode embarqué sur mobile et sur divers appareils, comme SQLite
- La synchronisation d’une base Turso existante vers un fichier local est également prévue pour Turso/Postgres
- Au-delà du fichier unique et de l’exécution embarquée, le projet inclut aussi le protocole wire et une implémentation serveur, afin que les applications existantes, les ORM et
psqlpuissent s’y connecter - À court terme, les frontends officiellement développés par l’équipe Turso seront SQLite et Postgres ; l’architecture sera ouverte pour permettre à des contributeurs externes de créer les autres
Utilisation actuelle et participation
- Aucun package n’est encore publié, mais il est déjà possible de compiler et d’exécuter le projet depuis les sources
cd postgres/cli && cargo run - Le frontend Postgres n’est pas développé dans un dépôt séparé, mais comme frontend officiel directement dans l’arborescence de code de Turso
- Le développement et les contributions se font dans le dépôt GitHub de Turso
Objectifs et limites de la compatibilité
- Étant donné que Postgres est bien plus complexe que SQLite, la compatibilité à 100 % n’est pas un objectif impératif
- Le projet se concentre sur la prise en charge des fonctions essentielles et largement utilisées, de façon à permettre à la majorité des utilisateurs d’exécuter leurs applications sans modification
- Lorsqu’il y a tension entre des fonctionnalités modernes et une compatibilité 1:1 parfaite, les choix seront faits au cas par cas
- les vues matérialisées de Turso sont mises à jour automatiquement en temps réel
- il n’est pas encore décidé si l’ancien mode sans mise à jour automatique sera aussi implémenté uniquement pour assurer une compatibilité parfaite
- À mesure que le périmètre fonctionnel s’élargit, Turso/Postgres pourrait se rapprocher davantage d’une base de données indépendante que d’une simple réplique de Postgres
Usage de l’IA et rythme de développement
- Les outils d’IA sont utilisés activement, mais sans renoncer à la revue de code ni à la compréhension de l’architecture
- L’équipe estime que, pour un composant critique comme une base de données, les outils d’IA n’ont pas encore atteint un niveau où ils peuvent assumer la responsabilité de la validation
- Le rythme par commit peut être plus lent qu’une approche consistant à faire tourner Fable 24 h/24, mais le projet part d’un cœur de base de données déjà fonctionnel et largement testé
- Plutôt que de modifier rapidement le système au risque de le casser, l’équipe choisit une implémentation plus lente mais correcte
- La finalisation de toutes les fonctionnalités demandera du temps, et certaines nécessiteront un cycle de développement long jusqu’à ce qu’une architecture adaptée soit en place
PL/pgSQL et extensions
- PL/pgSQL n’est pas un élément impossible à implémenter, mais plutôt un langage procédural ; au lieu de le réimplémenter tel quel, il est probable qu’une autre langue procédurale avec une couche de compatibilité soit proposée
- Une preuve de concept existe pour charger certaines extensions Postgres dans un conteneur WASM
- les extensions qui n’utilisent que les symboles fournis par le conteneur WASM peuvent être chargées arbitrairement
- cela entraîne une perte de performances liée à l’exécution WASM
- cette approche n’est pas encore arrêtée comme conception finale
- Un système d’extensions permettant l’exécution sans restriction de code arbitraire n’est pas jugé souhaitable
- Certaines extensions pourraient ne pas être prises en charge, mais beaucoup pourraient l’être si elles sont compilées en WASM
Calendrier estimé et stratégie open source
- Au lieu de créer une nouvelle base de données entièrement from scratch, le projet part d’un cœur déjà fonctionnel, testé, et partageant une large part de sa structure interne avec Postgres
- L’implémentation de l’ensemble des fonctionnalités Postgres peut prendre beaucoup de temps, mais un sous-ensemble fonctionnel suffisamment large pour un usage réel pourrait être livré en quelques mois
- Les deux développeurs principaux ont actuellement environ 44 ans et estiment pouvoir continuer à développer pendant au moins 20 ans, sans chercher à précipiter la complétion totale des fonctionnalités
- La vitesse réelle de développement et le périmètre couvert dépendront fortement des contributions de la communauté
- lors de l’ajout du support multiprocessus pour le dialecte SQLite, l’équipe n’avait pas de machine Windows et a donc laissé de côté l’implémentation Windows
- un développeur externe, qui utilisait beaucoup Turso, s’y est intéressé et a finalisé le support Windows en une semaine
- Les frontends expérimentaux peuvent être développés hors de l’arborescence principale, mais le frontend Postgres officiel utilise la même licence MIT que le reste de Turso
1 commentaires
Réactions sur Lobste.rs
J’ai l’impression que presque toutes les bases de données SQL compilent les requêtes pour une machine virtuelle (VM)
De ce point de vue, il est un peu étrange de citer SQLite comme un cas à part
SQLite, lui, compile les requêtes en bytecode impératif avec des variables et des boucles
En tant que développeur de pgwire, je suis ravi de voir Turso réutiliser pgwire pour une base de données compatible PostgreSQL
Je me demande pourquoi l’entreprise a jugé nécessaire de changer de cap
Je me demande s’ils ont terminé la réimplémentation de SQLite, ou s’ils l’ont abandonnée
https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next
On dirait qu’ils gardent toujours cet objectif tout en ajoutant entre-temps d’autres frontends
C’est un article très intéressant, et c’est honteux qu’il ait été signalé à tort
Ce n’est ni « off-topic » ni du « spam », et je ne comprends absolument pas pourquoi il a été signalé ainsi
Peut-être que quelqu’un a vu un tiret dans le titre et a conclu que c’était un déchet généré par IA ; j’ai vraiment l’impression que les gens perdent la tête
La culture du signalement sur ce site est devenue affreuse, et j’aimerais que la modération intervienne. Si quelques personnes qui signalent de façon malveillante étaient bloquées, les autres se calmeraient peut-être
J’ai toujours été rebuté par l’attitude de Turso, qui se présente comme le successeur de SQLite, et c’est pour ça que je m’étais juré il y a des années de ne jamais utiliser leur logiciel
Mais s’ils proposent des vues matérialisées auto-actualisées rapides et peu coûteuses en dehors de SQL Server, je finirai peut-être quand même par l’utiliser