Picture this: you’re building a fraud detection system, and you need to trace connections between suspicious accounts, shared devices, and merchant networks. Or maybe you’re mapping Active Directory attack paths to find the shortest route to Domain Admin. The question isn’t whether you need graph capabilities—it’s how to get them without breaking your existing workflow.
This is where the modern database landscape gets interesting. You have two paths: embrace a native graph database like Neo4j or TigerGraph, or stick with SQL and add graph capabilities through emerging standards like SQL/PGQ. Both approaches have passionate advocates, but the reality is more nuanced than the marketing suggests.
The Core Question: How Do You Think About Data?
Before diving into benchmarks and feature comparisons, let’s start with something more fundamental: how does your team think about the problems they’re solving?
If your mental model is “follow the connections until the story emerges,” you’re thinking like a graph. Fraud investigators tracing money flows, security analysts mapping privilege escalation paths, or recommendation engines finding similar users—these all follow relationship-centric thinking patterns.
If your mental model is “join these sets of data and apply business rules,” you’re thinking relationally. Most OLTP applications, BI dashboards, and compliance reporting fall into this category.
The key insight? Technology should amplify how people naturally think, not force them to think differently.
What We’re Actually Comparing
Let’s clarify what we mean by “SQL with graph schema”:
Native Graph Database:
- Purpose-built for storing and querying connected data
- Uses specialized query languages (Cypher, Gremlin, SPARQL)
- Optimized storage for nodes and relationships
- Examples: Neo4j, Amazon Neptune, TigerGraph
SQL with Graph Schema (SQL/PGQ):
- Traditional relational database with graph query extensions
- Maps existing tables to property graphs
- Uses familiar SQL with graph pattern matching syntax
- Examples: Oracle 23ai, emerging PostgreSQL support, Google Cloud Spanner
The Performance Reality
Here’s where it gets interesting. Recent research shows that the choice of query language can significantly impact performance, even when querying the same underlying data model.
For bounded queries (fixed-length paths), SQL often performs better due to mature join optimization. For unbounded queries (variable-length paths), graph-specific optimizations typically win. But these patterns aren’t universal—they depend heavily on the specific implementation and optimization strategies.
The takeaway? Don’t assume native graphs are always faster for graph queries, or that SQL is always better for analytical workloads. The reality is more sophisticated.
When Graph Databases Shine
Real-World Success Stories
Fraud Detection at Scale:
Major banks use graph databases to model customers, accounts, devices, and merchants. When a suspicious transaction appears, investigators can instantly traverse relationships to find patterns that rule-based systems miss. The graph approach reduces investigation time from hours to minutes while improving detection rates.
Active Directory Security with BloodHound:
Security teams worldwide use BloodHound, which ingests Active Directory data into Neo4j, to visualize attack paths. Instead of manually auditing thousands of permissions, defenders can query “show me all paths to Domain Admin in 3 steps or less” and prioritize the fixes that break the most dangerous routes.
Recommendation Engines:
Netflix, Amazon, and LinkedIn all leverage graph databases for recommendations. The key advantage isn’t just finding similar users—it’s being able to explain recommendations through relationship paths and adapt quickly as user behavior changes.
Technical Sweet Spots
Graph databases excel when:
- Multi-hop traversals are frequent (3+ relationship jumps)
- Path length varies (sometimes 2 hops, sometimes 10)
- Relationship types matter (friend vs colleague vs family)
- Graph algorithms are needed (PageRank, community detection, centrality)
- Schema evolves quickly (adding new node/edge types regularly)
When SQL/PGQ Makes Sense
The Integration Advantage
Customer 360 in the Data Warehouse:
A telecommunications company wants to understand household relationships for churn prediction. Instead of moving customer data to a graph database, they use SQL/PGQ to define a property graph over existing Customer, Account, and Service tables. Now they can run graph pattern queries alongside traditional BI reporting.
Supply Chain in ERP:
A manufacturing company tracks bill-of-materials hierarchies in their ERP system. When a critical component has quality issues, they use SQL/PGQ path queries to find all affected products while maintaining transactional consistency and existing governance controls.
Technical Sweet Spots
SQL/PGQ excels when:
- Graph queries are occasional (20% graph, 80% relational)
- Data governance is critical (single source of truth, audit trails)
- Team expertise is SQL-focused (existing skills, tools, processes)
- Operational simplicity matters (fewer platforms to manage)
- Shallow patterns dominate (1-3 hop traversals)
The Architecture Patterns
Pattern 1: Graph Sidecar
Keep your OLTP system in SQL for transactions and consistency. Stream relationship events to a graph database optimized for traversals and analytics. Feed insights back to applications and dashboards.
[OLTP Database] → [Event Stream] → [Graph Database]
↓
[Applications] ← [Insights & Scores] ←
When to use: High-volume graph queries, complex algorithms, real-time recommendations.
Pattern 2: In-Database Graph
Define property graphs over existing tables using SQL/PGQ. Run graph pattern queries in the same system that handles your OLTP and analytics workloads.
text[SQL Database]
↓
[Property Graph View] → [Pattern Matching Queries]
↓
[Standard SQL Queries]
When to use: Moderate graph needs, strong governance requirements, SQL-centric teams.
Pattern 3: Hybrid Approach
Use SQL for set-based operations and aggregations. Use graph queries for relationship traversals. Combine results at the application layer.
When to use: Complex analytical workloads that benefit from both paradigms.
Making the Decision
Start with Your Use Cases
High-frequency traversal scenarios:
- “Find all accounts within 3 hops of this suspicious device”
- “What’s the shortest path to Domain Admin from this compromised user?”
- “Show me users similar to this one through 4 degrees of connection”
If these sound like your daily queries, lean toward a graph database.
Augmented analytical scenarios:
- “Show quarterly revenue by customer segment, plus household relationships”
- “Generate compliance reports with data lineage paths”
- “Find product impact from supplier issues via bill-of-materials”
If these sound familiar, SQL/PGQ might be the better fit.
Evaluate Your Constraints
Team and Skills:
- Graph expertise available? → Graph database
- SQL-centric culture? → SQL/PGQ
- Mixed team? → Prototype both
Operational Requirements:
- Minimize platforms? → SQL/PGQ
- Need specialized algorithms? → Graph database
- Strict governance? → Consider SQL/PGQ
Performance Requirements:
- Millisecond traversals? → Graph database
- Second-level acceptable? → Either approach
- Mixed workloads? → Benchmark both
The Standards Landscape
Two major standards are shaping this space:
GQL (Graph Query Language):
The first new ISO database language since SQL standardizes how we query property graphs. Think of it as “SQL for graphs.”
SQL/PGQ (Property Graph Queries):
An extension to SQL:2023 that adds graph pattern matching to traditional SQL databases. Lets you query graphs and relations in the same system.
Both standards are driving convergence in the market. Native graph databases are adding GQL support, while SQL databases are implementing PGQ. This reduces vendor lock-in and improves portability.
Practical Next Steps
1. Identify Your Graph Questions
Write down 3-5 questions your team regularly asks that involve relationships. Be specific about hop counts and patterns.
2. Model a Subset
Pick one important question and model just the entities and relationships needed to answer it. Keep it small initially.
3. Prototype Both Approaches
Implement your question in both a graph database and SQL/PGQ. Measure:
- Query development time
- Query performance
- Query maintainability
4. Consider the Ecosystem
Think beyond the database:
- Visualization tools
- Monitoring and ops
- Team training needs
- Integration complexity
5. Start Small, Learn Fast
Don’t try to solve every graph problem at once. Pick one use case, implement it well, and expand based on what you learn.
The Verdict
There’s no universal winner in the graph database vs SQL/PGQ debate. The right choice depends on your team’s mental models, existing infrastructure, and specific use cases.
Choose a graph database when:
- Relationship traversal is core to your value proposition
- You need specialized graph algorithms
- Your team thinks in terms of connected data
- Performance on deep traversals is critical
Choose SQL/PGQ when:
- Graph capabilities enhance primarily relational workflows
- You want to minimize operational complexity
- Your team’s expertise and tooling center on SQL
- Governance and integration requirements favor fewer platforms
Consider a hybrid approach when:
- You have distinct workloads that favor different paradigms
- You need both high-performance traversals and traditional analytics
- You’re willing to manage the complexity for optimal performance
The database landscape is evolving rapidly, with convergence happening on multiple fronts. Whatever you choose today doesn’t have to be your choice forever. Focus on solving real problems for real users, and let the technology serve that goal.
The future likely involves both approaches coexisting and complementing each other. The question isn’t whether you’ll need graph capabilities—it’s how you’ll add them to your toolkit without disrupting what already works.
