Une bonne partie des outils autour de la base de données glisse vers le SaaS. Éditeurs SQL hébergés, dashboards analytiques dans le navigateur, plateformes de collaboration qui promettent de tout centraliser. Le mouvement est logique côté éditeur : abonnement récurrent, télémétrie détaillée, roadmap pilotée par les métriques d'usage. QoreDB prend la direction inverse et l'assume. L'outil est desktop, les données restent sur la machine, il n'y a pas de compte obligatoire, et il n'y en aura pas.
Ce choix n'est pas une posture idéologique. C'est une décision d'architecture qui découle de ce qu'est un client de base de données : un outil qui manipule des credentials sensibles et des données que l'utilisateur n'a souvent pas le droit de faire transiter par un tiers.
La donnée ne quitte pas la machine
Un client de base de données ouvre un accès direct à Postgres, MySQL, MongoDB, Redis ou SQL Server. Les chaînes de connexion contiennent des mots de passe, parfois des tokens d'accès, souvent des clés SSH. Les résultats de requêtes contiennent tout ce qui se trouve dans la base : données personnelles, données financières, secrets techniques.
Dans un modèle SaaS, ces éléments doivent transiter par les serveurs de l'éditeur, ou du moins pouvoir être interceptés par un proxy qu'il contrôle. Ce n'est pas un détail : c'est un déplacement de la frontière de confiance. L'utilisateur doit alors faire confiance à un tiers pour ses credentials, ses requêtes, ses résultats, et pour la conformité de tout ce chemin avec ses obligations réglementaires.
QoreDB supprime cette frontière. Les credentials sont stockés dans le keychain du système via le crate keyring. Les connexions vont directement du binaire à la base, sans intermédiaire. Les résultats de requêtes sont matérialisés en mémoire côté client, écrits sur disque uniquement si l'utilisateur le demande explicitement, via un export local. Il n'y a pas de plan de contrôle central qui verrait passer une requête ou un dump.
Pas de compte, pas de signup, pas de mur d'inscription
L'installation de QoreDB ne demande pas d'email, pas de licence en ligne, pas d'activation. L'utilisateur télécharge le binaire, l'ouvre, crée sa première connexion. La configuration entière tient dans le dossier utilisateur local. C'est un pré-requis évident pour un outil que des équipes air-gapped, des environnements segmentés ou des postes hors ligne doivent pouvoir utiliser.
L'absence de compte a une conséquence directe : il n'y a rien à récupérer sur un serveur central si le poste est perdu. La portabilité passe par un export explicite de la configuration, chiffré, que l'utilisateur transfère lui-même. Ce n'est pas un défaut, c'est un modèle. Il correspond à des développeurs qui veulent maîtriser leur outillage et à des organisations qui interdisent que la configuration de leurs accès de production soit synchronisée dans le cloud d'un éditeur.
La collaboration est optionnelle et sans intermédiaire imposé
Partager une requête, un snapshot de résultat ou un rapport ne nécessite pas de passer par un service centralisé. QoreDB expose un export HTML self-contained qui embarque les données et une interface minimale de filtrage. Ce fichier s'envoie par email, se dépose sur un partage réseau, s'attache à un ticket. Le destinataire l'ouvre dans un navigateur, sans compte et sans dépendance.
Pour les scénarios plus riches, la logique reste la même : la collaboration se branche sur ce que l'équipe utilise déjà. Un dépôt Git pour les requêtes versionnées, un partage de fichiers pour les exports, éventuellement un serveur auto-hébergé pour synchroniser certaines ressources. QoreDB ne cherche pas à devenir la source unique de vérité pour la coordination technique de l'équipe. Ce rôle est déjà tenu par des outils plus adaptés.
Rester desktop, c'est aussi rester libre côté performance
Un client SaaS impose une architecture à trois étages : le navigateur, le backend de l'éditeur, la base cible. Chaque requête traverse deux liens réseau au lieu d'un. Chaque résultat de plusieurs milliers de lignes doit remonter jusqu'au backend avant d'être re-transmis au navigateur, souvent après sérialisation JSON. Les grilles de résultats deviennent lentes dès que la volumétrie augmente, et l'éditeur est incité à limiter artificiellement la taille des jeux de données pour tenir ses coûts.
QoreDB parle directement à la base via des drivers natifs (sqlx pour Postgres, MySQL, SQLite, tiberius pour SQL Server, drivers officiels pour MongoDB et Redis). Les résultats sont streamés depuis la base vers le processus local, sans étage intermédiaire. Le seul plafond utile est la mémoire disponible sur la machine, gérée par des curseurs et une virtualisation côté grille.
Un modèle économique aligné avec l'utilisateur
Le SaaS pousse un modèle par abonnement, avec des paliers d'usage qui incitent l'éditeur à limiter ce que fait la version basse pour rendre la version haute nécessaire. Un client de base de données pris dans cette logique finit par facturer à la connexion, à la requête, au volume de résultats, ou au nombre de collaborateurs.
QoreDB adopte un modèle open-core : le cœur du produit, les drivers, l'exécution des requêtes et l'ensemble des interactions locales sont sous licence Apache 2.0. Certaines fonctionnalités avancées, comme la fédération inter-bases ou l'assistant IA, sont sous licence BUSL 1.1 et incluses dans une édition Premium. Toutes s'exécutent localement. Rien ne se paye à la requête ou à la ligne retournée. L'utilisateur qui achète Premium ne devient pas un utilisateur dépendant d'un serveur central que l'éditeur peut couper.
Ce que ça change en pratique
Concrètement, un développeur qui installe QoreDB peut travailler dans un train sans réseau, brancher un tunnel SSH vers un bastion interne sans exposer ses credentials à un tiers, et faire un audit de conformité en montrant simplement que le binaire ne parle qu'à ses bases et aux mécanismes de mise à jour signés. Une équipe qui adopte QoreDB ne dépend pas d'un opérateur externe pour continuer à utiliser son outil demain. Si l'éditeur disparaît, la version installée continue de fonctionner, et le code source du cœur reste disponible.
La contrepartie est également claire : la synchronisation entre postes reste à la charge de l'utilisateur, via un export de configuration, et les scénarios de collaboration temps réel sur une même requête ne font pas partie du périmètre. Ces choix correspondent au public que QoreDB adresse : développeurs solo, petites équipes techniques, environnements où la maîtrise de la donnée prime sur la centralisation.
Un engagement produit, pas une phase transitoire
Le SaaS n'est pas juste un mode de livraison. C'est une structure qui conditionne l'architecture, le modèle de sécurité, la relation contractuelle, et la roadmap. Un outil pensé SaaS dès le départ n'est pas symétrique à un outil desktop qui accepterait plus tard une variante hébergée. Les décisions faites sur les credentials, sur la manière dont les résultats transitent, sur la gestion de l'identité, ne se rejouent pas.
QoreDB est conçu comme un outil local. C'est ce qui rend possible la garantie qu'aucune donnée ne fuite par défaut, l'absence de compte, la portabilité complète et la simplicité de conformité pour les utilisateurs qui en ont besoin. C'est aussi ce qui permet de tenir un rythme de développement centré sur l'ergonomie du client plutôt que sur l'exploitation d'une infrastructure. Ce cadre ne changera pas.
Restez informé des nouveautés
Rejoignez notre newsletter pour recevoir les mises à jour majeures, les nouveaux drivers et nos coulisses techniques.