Pourquoi QoreDB existe

Les bases de données ont énormément évolué ces dernières années.

Nous travaillons aujourd’hui avec des bases relationnelles, des bases orientées documents, des systèmes clé-valeur, des moteurs analytiques, et de plus en plus de modèles hybrides.
Pourtant, les outils que nous utilisons pour interagir avec ces bases n’ont que très peu changé.

QoreDB existe parce que cet écart est devenu trop important pour être ignoré.

Le problème des outils de bases de données actuels

La majorité des clients de bases de données entrent dans l’une de ces deux catégories :

• Puissants mais lourds
  Des outils riches en fonctionnalités, souvent complexes, lents à utiliser et difficiles à maîtriser au quotidien.
• Simples mais limités
  Des outils agréables au départ, mais qui montrent rapidement leurs limites dès que l’architecture devient un peu plus complexe.

Dans la pratique, les développeurs finissent par multiplier les outils :

• un pour le SQL
• un pour le NoSQL
• un autre pour explorer les données
• parfois un autre pour le monitoring ou les performances

Cette fragmentation augmente la charge mentale et ralentit le travail — exactement l’inverse de ce qu’un bon outil devrait faire.

SQL vs NoSQL : une fausse opposition

Pendant longtemps, le débat a été présenté comme un choix idéologique :

• SQL ou NoSQL
• structuré ou flexible
• relationnel ou document

Mais les applications modernes ne fonctionnent pas de cette manière.

Les développeurs choisissent une base de données en fonction d’un besoin précis, pas d’un dogme.
Et les outils qu’ils utilisent devraient refléter cette réalité.

QoreDB repose sur une idée simple :

Les développeurs ne devraient pas avoir à changer d’outil simplement parce que le modèle de données change.

L’expérience développeur n’est pas un détail

Un client de base de données est un outil utilisé tous les jours, parfois pendant des heures.

Pourtant, l’UX est souvent reléguée au second plan :

• interfaces surchargées
• interactions incohérentes
• complexité exposée trop tôt ou au mauvais moment

Chez QoreDB, l’expérience développeur est considérée comme une problématique technique à part entière, pas comme une couche cosmétique.

La clarté, la rapidité et la prévisibilité ne sont pas des bonus.
Ce sont des prérequis.

Une approche local-first et contrôlée par le développeur

QoreDB est conçu avec un principe fort : le local-first.

Les connexions, les identifiants et les flux de travail doivent rester sous le contrôle du développeur.
Pas enfermés dans des abstractions opaques ou dépendants de services cloud inutiles.

Cette approche améliore :

• la sécurité
• les performances
• la confiance dans l’outil

Et surtout, elle correspond à la façon dont les développeurs travaillent réellement.

Construire un outil pour le long terme

QoreDB n’a pas vocation à remplacer tous les outils existants du jour au lendemain.

Le projet est pensé pour évoluer :

• avec les nouveaux paradigmes de bases de données
• autour d’un modèle open-core soutenable
• en intégrant les retours de la communauté

Ce blog servira à documenter :

• la vision du produit
• les choix techniques
• les compromis assumés

La transparence fait partie intégrante du produit.

Et maintenant

Cet article pose les bases.

Les prochains aborderont plus en détail :

• les limites des clients de bases de données actuels
• la philosophie produit de QoreDB
• les choix d’architecture derrière une expérience unifiée

Si vous vous intéressez aux outils de bases de données modernes, pensés pour les développeurs, vous êtes au bon endroit.