From SQL to Graph: 5 Questions to Ask Before You Get Started
Relational databases have powered organizations for decades. They are familiar, stable, and deeply embedded in almost every system.
Yet the moment you try to build a GraphRAG pipeline on top of SQL, the cracks begin to show. Joins lose semantic meaning. Embeddings do not capture relational context. And your LLM ends up working with fragmented information rather than a connected view of your data.
That is why many teams are now looking at graph models as a way to reveal context that SQL simply cannot express. The challenge is not that graphs are better. The challenge is that most of your data already lives in SQL, and redesigning schemas manually is slow, expensive, and error-prone.
Our latest Community Call, From Tables to Knowledge Graphs: SQL2Graph for GraphRAG, surfaced the exact questions engineers ask when they attempt this migration.
These questions highlight the real work behind GraphRAG adoption. Here are the five key things you need to think about before moving from tables to a graph that your LLM can actually reason over.
1. How should you approach SQL-to-Graph schema modeling?
Most engineers assume modeling is a one-time task. In SQL databases, that is usually true. In graphs, it is not. Relationships carry meaning, and the way you model them impacts retrieval quality inside GraphRAG.
This is exactly why HyGM (Hypothetical Graph Modeling) exists. SQL2Graph agentic migration tool uses HyGM, an interactive modeling assistant, to propose an initial graph schema based on your existing tables, relationships, and constraints.
HyGM suggests a hypothetical schema and you guide the refinement step by step. You can accept it, refine it, or iterate through several versions.
Instead of manually rewriting your entire schema, you get a guided loop where the agent proposes nodes and relationships, with their associated properties, and you stay in control. Once you load your graph and begin querying, you can iterate on the model as new patterns and use cases appear.
2. How automated should your migration process be?
SQL2Graph supports two modes of operation: Automatic Mode and Incremental Mode.
In Automatic Mode, the agent handles the full workflow. It generates the hypothetical graph model, validates it, and migrates your SQL data into Memgraph with minimal input. This is ideal for proofs of concept or when you want a quick end-to-end migration.
In Incremental Mode, you guide the process step by step. For each table, the agent proposes node labels, properties, and relationship structures. You review the suggestions, edit them, or introduce new modeling choices. You can rename relationships, drop properties, adjust labels, or restructure parts of the graph.
Incremental mode gives you fine-grained control, making it a good choice for production-grade modeling or complex schemas.
Both modes rely on Memgraph’s Migrate Modules, which support MySQL and PostgresSQL. These modules execute the ETL steps after the model is accepted.
3. How will you keep your SQL and graph data in sync?
A one-time migration is simple. Keeping the systems synchronized is the real challenge.
If your SQL schema rarely changes, SQL2Graph may serve as a migration step that you only run occasionally. But if your SQL database updates constantly, you will want a streaming setup.
Memgraph supports this with Kafka-based change data capture (CDC). You can:
- Run the initial migration through SQL2Graph
- Use a Kafka connector attached to PostgresSQL triggers
- Stream inserts, updates, and deletes into Memgraph
Memgraph becomes the real-time contextual layer for your GraphRAG pipeline while SQL remains your source of truth.
4. What LLM model should you use for generating Cypher or modeling decisions?
If you want to generate Cypher from natural language, the choice of model depends on your GPU. Smaller open source models such as Llama or OpenAI’s OSS models can run locally on a single GPU.
But model size is not the most important factor. What matters is whether the model supports agent mode. An agent-enabled model can:
- Retry failed Cypher attempts
- Use error feedback to correct mistakes
- Plan and execute multi-step reasoning cycles
Agentic loops dramatically improve Cypher quality even with smaller LLMs.
If you run heavier workloads or want more consistent quality, you can use hosted models such as OpenAI or Anthropic.
5. Do you need to change your SQL schema before migrating?
The whole point of SQL2Graph is that you do not need to remodel or preprocess your SQL schema. Use your existing relational structure exactly as it is.
SQL2Graph and HyGM operate on top of your SQL schema. They analyze your tables, constraints, and relationships, then propose a graph model based on that structure. Once the migration is complete, you can query your graph and refine the model. If you discover better modeling decisions, you can rerun the agent with updated instructions.
Your SQL schema stays untouched. All modeling changes happen on the graph side.
Wrapping up
Building a graph from your relational database is not just an exercise in ETL. It is a shift in how you think about structure, context, and retrieval. SQL gives you consistency, but graphs give your LLM the ability to understand how your data fits together.
SQL2Graph powered by HyGM helps you bridge that gap without rewriting your relational schema or guessing your way through graph modeling. You get a clear starting point, an interactive refinement loop, and a migration path that fits the way your data actually evolves.
Start with the schema you already have. Let the agent propose a model. Iterate until your graph reflects the relationships that matter. Once you migrate, you can begin using graph-native retrieval to support your LLM applications.
If you want to explore the full SQL2Graph workflow, watch the community call recording and try the agent in the Memgraph AI Toolkit.
