Virtual Graph : Neo4j parie sur la virtualisation des graphes

Un compromis technique pour contourner des limites structurelles

« Dans la conception des bases de données graphes, nous organisons l’architecture de manière à regrouper physiquement les données interconnectées sur les disques », explique Sudhir Hasbe, président et chief product officer chez Neo4j, auprès du MagIT. « Cela optimise considérablement les performances en termes de débit. Cette approche rend les opérations de parcours et le raisonnement multi-sauts particulièrement efficaces », poursuit-il. « Cependant, cette optimisation a un coût : les processus d’ingestion et d’écriture des données sur les disques deviennent plus lents et plus complexes ».

Sudhir Hasbe, Président et CPO, Neo4j

Sans même atteindre l’échelle de la centaine de téraoctets, les coûts associés aux mouvements de données s’avèrent prohibitifs. Surtout, les entreprises ne sont généralement pas enclines à multiplier les copies de données, pour des raisons évidentes de gouvernance.

Virtual Graph se présente donc comme un compromis. Les données restent à leur place : le service y accède en mode « zero-copy », après avoir configuré l’instance Aura Virtual Graph et la connexion au lakehouse sous-jacent. Ensuite, le système convertit automatiquement le schéma de données associé aux tables sources dans un modèle graphe. Ce modèle peut être édité ou créé de toutes pièces, tout comme il est possible d’en sauvegarder plusieurs variantes.

Il s’agit de définir des relations entre des objets – les nœuds et les propriétés-présents dans les tables.

« L’algorithme intégré inspecte votre schéma source, déduit quelles tables doivent devenir des nœuds, quelles clés étrangères (ou colonnes de jointure, même lorsque les clés étrangères ne sont pas déclarées) doivent devenir des relations, et quelles colonnes deviennent des propriétés », relate la documentation de Neo4j.

« Notre démonstration prend l’exemple d’une base de données de patients d’une clinique. On veut pouvoir définir à quoi ressemblent les demandes de remboursement. En quoi consistent ces relations en matière de facturation pour les patients concernant la prise en charge par l’assureur ? », illustre Sudhir Hasbe.

Virtual Graph permet ensuite d’écrire des requêtes Cypher. Ces requêtes sont compilées en SQL avant d’être exécutées par le moteur de traitement du lakehouse. Puis, le service récupère les résultats correspondant au pattern Cypher. Il est possible d’utiliser une partie des outils de Neo4j : Browser, Bolt, les notebooks, la couche de visualisation Bloom, Aura Graph Analytics et les serveurs MCP.

Virtual Graph se connecte pour l’instant à Databricks (SQL Warehouse), à Google Bigquery et à Snowflake. « Nous ajouterons prochainement des intégrations avec Amazon Athena et Microsoft Fabric », précise Sudhir Hasbe. La documentation de l’éditeur évoque un lancement de ces connecteurs au cours du troisième trimestre 2026. À l’avenir, n’importe quel entrepôt ou base accessible à travers un connecteur JDBC ou une interface SQL sera pris en charge, en commençant par les systèmes Oracle.

Virtual Graph, une application concrète du standard GQL

Le système ne couvre pas entièrement la richesse de Cypher. La compatibilité varie suivant l’entrepôt de données qui exécute la requête. Virtual Graph est un système en lecture seule. Exit donc les écritures, les MERGE et les changements de schémas. Des fonctionnalités avancées manquent à l’appel comme la recherche de chemins de complexes illimités, le calcul du chemin le plus court entre deux nœuds, la recherche vectorielle, les procédures de la librairie APOC (Awesome Procedures on Cypher), ainsi que d’autres requêtes complexes. Sans oublier que Cypher refuse de traiter les requêtes contenant des valeurs null, contrairement à TigerGraph 4.3. En revanche, le concurrent de Neo4j ne joue pas la carte de la virtualisation : il dispose en préversion d’un connecteur Apache Iceberg pour charger les données dans sa base. Il peut aussi réécrire les résultats dans un lakehouse ou dans un système compatible S3 (MinIO, Ceph, Wasabi).

Du côté de Neo4j, notons que selon la requête, AuraDB en exécute une partie en Cypher avant que l’autre partie soit transmise aux moteurs du Lakehouse associé.

Neo4j affirme couvrir environ 95 % du standard ISO GQL. « Nous essaierons de porter la compatibilité de Cypher avec 98-99 % de la spécification GQL dans les douze prochains mois », déclare le CPO.

Le standard ISO GQL, poussé par Neo4j et Oracle, définit un langage de requête graphe standardisé. Pensé pour être utilisé au-dessus de bases relationnelles en lecture seule, son adoption par les éditeurs de lakehouse reste limitée, d’où la nécessité pour Neo4j de maintenir une couche de traduction Cypher/GQL vers SQL.

« Lorsque vous exécutez des requêtes avec 8 à 9 niveaux de traversée dans ces systèmes [lakehouse], elles génèrent jusqu’à 20 ou 25 jointures de tables SQL, car chaque saut nécessite de passer par des tables intermédiaires », justifie Sudhir Hasbe. « Cela entraîne des temps de réponse très lents ».

Néanmoins, le dirigeant affirme avoir de bonnes raisons d’espérer des changements.

« Les principales plateformes de données vont progressivement intégrer des capacités graphe, que ce soit via GQL ou des extensions comme celles de PostgreSQL », estime Sudhir Hasbe. « Cette évolution répond à un besoin devenu évident : les systèmes d’IA nécessitent une représentation graphe des données pour effectuer du raisonnement multi-sauts efficace ».

« Les bases de données en colonnes ne définissent pas de contraintes de jointure strictes, ce qui rend impossible pour un LLM de comprendre pleinement la structure des données », poursuit-il. « Le graphe résout ce problème en rendant les relations explicites et navigables ».

Le directeur produit mentionne le récent lancement (en préversion) de Spanner Graph et de BigQuery Graph chez Google Cloud, sur lesquels il a précédemment travaillé en tant que directeur des produits analytiques chez GCP. Microsoft intègre une solution en périphérie de sa plateforme Fabric. « Je m’attends à ce que Snowflake et Databricks emboîtent le pas prochainement ».

Virtual Graph et les autres offres de Neo4j ne perdront pas de leur pertinence, juge-t-il.

« Notre avantage distinctif réside dans notre capacité à opérer de manière transversale sur l’ensemble de ces plateformes, là où les autres proposent des solutions cloisonnées à leur propre écosystème ».

Un pied à l’étrier pour tester les GraphRAG

Malgré tout, Virtual est et restera un produit d’appel vers la base de données Aura et sa déclinaison Self-Managed.

Si l’analyse profonde de données demeure le cas d’usage numéro 1 de Virtual Graph (par exemple pour la lutte contre la fraude chez les banques et les assurances), l’éditeur évoque son utilité pour le déploiement de graphes de connaissances et de GraphRAG. Ici, ce sont des mécanismes de recherche augmentés par l’IA générative propulsés par des graphes.

« Un GraphRAG est bien meilleur qu’un RAG vectoriel standard. Tous nos clients le disent », vante Sudhir Hasbe. Et de citer des déploiements GraphRAG plus ou moins importants chez Pfizer, Adobe, L’Oréal, ou encore Uber.

Néanmoins, le dirigeant oublie de mentionner que cela requiert un plus grand travail de modélisation et d’extraction de données. En ce qui concerne Virtual Graph, le service ne prend pas encore la recherche vectorielle –, la meilleure approche consiste à combiner vecteurs et graphRAG – et il ne sera pas adapté à tous les agents IA.

« Avec Virtual Graph, vous faites un “trade-off” sur la performance, mais vous avez le passage à l’échelle », soupèse Sudhir Hasbe. « Si vos agents ou vos assistants IA s’exécutent pendant plusieurs secondes, minutes ou heures pour des tâches longues (recherche profonde, tâche agentique), ce compromis est acceptable ».

« Mais si vous souhaitez disposer d’un agent en temps réel offrant une latence minimale et un débit élevé, vous pouvez tout à fait stocker les données dans notre base de données native ».

Neo4j estime que sa base native peut offrir des performances « 10 à 100 fois supérieures » à Virtual Graph pour certaines requêtes complexes.

L’éditeur fournit par ailleurs un service (Aura Agents) et des intégrations avec ADK de Google, AWS Strands, ou encore LangChain.

Un autre concurrent de Neo4j, Memgraph, a intégré la notion de vues de graphes dans la version 3.11 de sa plateforme. En revanche, il considère que cette fonctionnalité est utile pour des expérimentations, quand il n’est pas nécessaire d’écrire les résultats lors de tests, d’analyse de sous-graphes spécifiques ou d’investigations qui ne modifient pas les données de production.

Mise en cache adaptative : Neo4j promet des gains de performance

Néanmoins, chez Neo4j, les performances Virtual Graph devraient s’améliorer. L’éditeur développe une fonction de « mise en cache adaptative » spécifique. Elle vise à matérialiser des sous-graphes pour « des charges de travail agentiques répétitives ».

« Ce sont essentiellement des vues matérialisées », résume Sudhir Hasbe. « Grâce à la matérialisation, nous pouvons proposer un modèle de requêtes ultra-rapide, véritablement optimisé, à faible latence et à haut débit, ce que ces lakehouse ne sont en réalité pas en mesure de faire ». Il sera possible d’activer ou de désactiver la fonction de mise en cache.

Avec son SGBD, les pages de cache sont utilisées pour stocker les données graphes et les indexer en mémoire vive, tout comme le plan de requêtes.

L’autre volet en cours de développement dans Neo4j Virtual Graph concerne la capacité de traitement « composite », ce que d’autres appellent la fédération de requêtes.

« Ce que nous pourrons faire, c’est créer un graphe virtuel sur Snowflake, puis un autre, natif, sur notre plateforme et un troisième sur Databricks, puis élaborer une requête qui couvre l’ensemble des bases de données afin qu’un agent puisse les exploiter », décrit le directeur produit.

Cette fonctionnalité existe déjà dans les autres produits de Neo4j. Elle permet d’exécuter des requêtes graphes qui traversent plusieurs sources de données hétérogènes.

Virtual Graph peut être déployé sur AWS, Azure et GCP. Comme AuraDB Pro, le service sera facturé quelques dizaines de centimes de dollar par Go et par heure sous forme de crédits (les tarifs varient suivant la taille de l’instance). Gratuits dans sa phase de préversion, les clients commenceront à payer dès le 1^er septembre. « La disponibilité générale suivra rapidement », promet l’éditeur.

Le portage vers les éditions self-managed du SGBD orienté graphe (Neo4j Enterprise Edition) est également prévu.