What even is a graph database?
Picture a giant whiteboard covered in dots — one for each thing you care about (a person, a product, an account) — with labeled strings tied between them showing how they're related. That's a graph. A graph database is just a place to store that whiteboard and ask questions about it.
A spreadsheet or a filing cabinet is great at lists: "here are all the customers, one per row." But it struggles the moment you ask "who is connected to whom, and how?" — friends of friends, the path money took between two accounts, which products are bought together. A graph database is built for exactly those connection questions, and answers them directly.
Think about how you'd actually map your family if someone handed you a spreadsheet. You'd end up with a "people" sheet, a "marriages" sheet, a "children" sheet, and then you'd spend the afternoon cross-referencing row numbers just to answer "who's my second cousin?" Now picture the same family on a whiteboard — a dot for each person, a line for each relationship. The answer is right there: you just trace the lines. A graph database stores the whiteboard version, so the connections are the data, not something you have to reconstruct every time you ask.
The everyday version of this is already in your pocket. When a social app says "you have 12 mutual friends" or a shopping site says "people who bought this also bought that," it's answering a connection question — following strings between dots. A graph database is simply the tool that makes those answers fast and natural instead of slow and bolted-on.
- The dots are called nodes (the things).
- The strings are called relationships or edges (how things connect).
- Both dots and strings can carry properties — a name, a date, an amount.
Go deeper: a tiny real example
Say Ana KNOWS Ben, Ben KNOWS Cleo, and Ana LIKES Jazz.
In a graph, "Ana" and "Ben" are nodes; "KNOWS" and "LIKES" are relationships
between them; and a property on Ana might be { age: 31 }. Asking
"who does Ana know, two hops out?" simply follows the strings — no
complicated table-joining gymnastics required.
Here's why that matters as things grow. In a spreadsheet world, "two hops out" means matching one big table against itself, and "three hops" means matching it again — the work balloons with every hop. In a graph, each hop is just "follow the strings already tied to this dot," so the work stays close to the number of connections you actually walk, not the size of the whole dataset. That's the difference between an answer that arrives instantly and one that grinds for minutes as your data grows.
A quick way to know you have a graph problem: if the interesting questions contain the words "path," "network," "ring," "chain," "related to," or "reachable from," you're asking about connections — and that's a graph's home turf.
You're probably running 5–6 databases (and it hurts)
A typical modern app for AI and data doesn't run on one database — it runs on a small zoo of them.
Research into how teams build in 2026 keeps finding the same pattern: a relational database for transactions, a cache for speed, a document store for flexible records, a vector database so AI features can "find by meaning," a search engine for text, and an analytics database for crunching numbers — plus a graph database the moment your data is genuinely connected.
Every extra system is one more thing to run, secure, back up, and keep in sync. Worse is the "retrieval gap": when a single real-time answer has to hop across several databases, you pay for it in latency, duplicated copies of the same data, and brittle glue code holding it all together.
Here's a kitchen analogy. Imagine cooking dinner where the flour lives in the garage, the salt is at the neighbor's, the oven is across the street, and the recipe is taped to a window two blocks away. Each ingredient might be fine on its own, but every dish turns into a series of trips — and if one neighbor moves, dinner breaks. A polyglot database stack feels exactly like that to the team running it: each system is reasonable in isolation, but the running back and forth between them is where the time, the bugs, and the 2 a.m. pages come from.
And these copies drift. Because the same customer might live in the relational database, the cache, the search engine, and the vector database at once, "the truth" quietly splinters: an address gets updated in one place but not the others, and now different parts of your app disagree about the same person. Most of the glue code in a modern stack exists purely to paper over that drift — code that does nothing for your users and everything to keep the zoo from contradicting itself.
Go deeper: the cost of the zoo
This isn't a niche worry. Convergence is the headline trend of the moment — even established graph databases have bolted on built-in vector indexes specifically to spare teams from standing up a separate vector database. The vector-database category alone was roughly a $3.2B market in 2025 and growing about 24% a year. The industry is voting with its roadmap: fewer moving parts, not more.
The hidden bill comes in three forms. First, money: every system is its own license, its own servers, and its own specialist to keep it healthy. Second, time: a feature that touches three databases needs someone who understands all three, so simple changes turn into multi-team negotiations. Third, risk: more moving parts means more places to misconfigure a password, more surfaces to attack, and more 2 a.m. failures where the data was fine but the plumbing between the databases broke. Consolidation attacks all three at once.
One server, not N
xrayGraphDB folds the graph, find-by-meaning vector search, analytics, and a dual query language into a single engine — the layer that would otherwise be three or four specialized databases wired together.
Removing the hops between databases isn't just tidier — it's also why xrayGraphDB is fast (more on that next). When the connected data, the meaning-based search, and the analytics all live in one place, an answer doesn't have to travel across a network of systems to get assembled.
Think of it like the difference between a strip mall and a Swiss Army knife. The "before" picture is a strip mall: separate storefronts for the graph, the vector search, the analytics — and you, the shopper, walking your shopping bag from one to the next, every single time you want an answer. The "after" picture folds those tools into one body. You're not visiting four shops and carrying data between them; you ask once, and everything you need is already in the same place.
Crucially, this is one engine, not four programs bundled into one installer. The graph, the meaning-based search, and the analytics share the same data the moment it lands — so a single question can walk relationships and rank by meaning in the same breath, with nothing copied or shipped between subsystems in between.
An honest scope note: xrayGraphDB is the connected-data, AI-retrieval, and analytics layer of your stack. It's not pretending to be a drop-in replacement for the plain relational database that runs your billing — it's the engine that replaces the pile of specialized systems sitting around it.
Go deeper: what "unified" buys you
One engine means one place to secure, one place to back up, one copy of the truth (no nightly jobs copying data from system A into system B), and one query that can walk relationships and rank by meaning at the same time — instead of three round-trips stitched together in application code.
It also collapses the operational checklist. Instead of patching, monitoring, and tuning four different systems — each with its own quirks, its own dashboards, and its own way of failing — your team learns one. Onboarding a new engineer means teaching them one engine, not a guided tour of a zoo. And when something does go wrong, there's one place to look, not a finger-pointing match between four systems that each insist the problem is somewhere else.
Why it's blazing fast
Fast is hard to picture, so let's anchor it to something human: a blink of your eye takes about 100 milliseconds. A warm xrayGraphDB query returns in about 0.2 ms — hundreds of times quicker than you can blink.
Bars are illustrative; the 0.2 ms and blink figures are real reference points.
Where does the speed come from, in plain terms? Three things: a vectorized engine — it processes thousands of records in a single sweep — optional GPU-accelerated analytics that harness your graphics card's massive parallel power for heavy workloads, and — the theme of this whole page — no network hops between separate databases, because there's only one.
"Vectorized" sounds technical, but the idea is an everyday one. Imagine a checkout line where the cashier scans your items one at a time versus one who waves a wand over the whole cart at once. Most databases scan one record at a time; a vectorized engine waves the wand over a whole batch in a single motion. The GPU part is the same trick taken further: a graphics card is built to do thousands of small jobs side by side — the very shape of work a big graph algorithm needs — so heavy analytics that would crawl on an ordinary processor can fly.
But the headline reason ties back to the rest of this page. Even the fastest single system loses if every answer has to leave the building. A "warm" query is one where the data the engine needs is already close at hand — nothing has to be fetched from a separate database across the network first. Because xrayGraphDB is the one engine, more of your queries get to be warm, and "no hops" stops being a slogan and starts being the reason the numbers below are what they are.
- About 0.2 ms for a warm query — hundreds of times faster than an eye-blink.
- 8,927 queries per second when pipelined — thousands of answers every second.
- The 3.6-billion-edge Friendster graph: xrayGraphDB ran every algorithm and finished the full undirected workload — where competing systems could not.
To put that middle number in human terms: 8,927 queries per second is roughly enough to answer one question for every seat in a mid-size concert hall — every single second, without breaking a sweat. And the Friendster result is the kind that's easy to skim past but worth pausing on: 3.6 billion edges is a graph with more connections than there are people on Earth, and xrayGraphDB didn't just go fast on it — it actually finished the full workload where other systems gave up.
Go deeper: how the numbers were measured
These aren't marketing estimates — they come from a benchmark run against a leading GPU-accelerated graph library plus seven other systems, on real datasets up to 3.6 billion edges. The full methodology, hardware, and per-algorithm results live on the benchmarks page.
A word on the word "warm." Just like an oven, an engine is faster once it's up to temperature — the data it's working on is already staged and ready. The honest way to read these figures is "this is what steady-state operation looks like once the system is serving real traffic," which is exactly the state your users actually experience. We publish the full methodology precisely so you can check the figures against your own workload rather than taking ours on faith.
Locked down — at no speed cost
Most databases force a brutal trade-off: strong encryption or speed — not both. Turn encryption on elsewhere and watch performance drop.
xrayGraphDB refuses that trade-off. Encryption isn't a bolt-on you toggle and pay for — it's built into the engine's fast path. Every tenant's data is encrypted at rest with AES-256-GCM — the same algorithm the U.S. National Security Agency approves for information classified up to Top Secret — each tenant with its own independent key, always on, no off switch. It runs on FIPS-validated cryptography and already meets FIPS 140-2, SOC 2, and HIPAA requirements.
Here's the genuinely unheard-of part: all of that protection is included in the speed numbers above. The 0.2-millisecond queries and thousands of requests per second — that's the encrypted engine. You never choose between locked-down and fast. You get both, on the same server.
A plain way to picture "each tenant with its own independent key": imagine an apartment building where every unit has its own lock and its own key, and no master key opens them all. If you rent unit 3, your key opens unit 3 — and only unit 3. Even though everyone shares the same building, no neighbor can wander into your apartment. That's what per-tenant encryption does for the customers who share one xrayGraphDB server: same building, separate locks.
And about that "no speed cost" claim — it's worth sitting with, because it's genuinely unusual. With most systems, turning on strong encryption is like driving with the parking brake half-engaged: everything still works, but you feel the drag every mile. xrayGraphDB was built with the encryption already baked into how it moves, so there's no brake to release and no drag to feel. The locked-down version is the fast version — they're the same engine.
It's built for the highest bar there is: the architecture is designed to meet the requirements of classified, high-assurance (CNSA-grade) environments — with formal accreditation in progress.
Go deeper: security without the speed tax
Per-tenant AES-256-GCM encryption, FIPS-validated crypto, and CNSA-grade architecture are built into the engine's core — not added as optional modules. The full chapter walks through what that means in practice: key isolation, the FIPS boundary, and what "accreditation in progress" actually entails.
Two terms are worth unpacking in plain English. FIPS-validated means the cryptography isn't just claimed to be strong — it runs on components that have been formally tested and validated against the U.S. government's standard, the same bar required to sell into many government and healthcare settings. AES-256-GCM is simply the specific recipe used to scramble the data — the algorithm the U.S. National Security Agency approves for information classified up to Top Secret. To be precise about what that claim is and isn't: that's a statement about the algorithm's approval, while the formal accreditation of this product for such environments is still in progress — which is exactly why we say "accreditation in progress" rather than claiming a certification we haven't yet earned.
What it can actually do
A quick tour, each with a "what that means for you."
It helps to see these as one toolkit rather than a checklist. The reason they belong together is that real questions rarely stay in their lane: a fraud investigator wants to walk the network of accounts and find the ones that "look like" a known bad actor and rank which ring is most central — all in one breath. Because these capabilities live in the same engine, a single question can do all three without handing your data off between systems.
- Ask questions of connected data — walk relationships directly. For you: "friends of friends," fraud rings, supply chains, who-influences-whom.
- Find hidden patterns and paths with built-in graph analytics — importance ranking, community detection, shortest paths, and more. For you: surface the structure you couldn't see in a table.
- Find by meaning, not just keywords — native vector / embedding search. For you: "show me records like this one," the backbone of modern AI retrieval.
- Two query languages — Cypher (the familiar graph language) and GFQL. For you: use the one your team already knows.
- Hundreds of built-in functions and a dual protocol. For you: less custom code, easy to connect.
- Multi-tenant with per-tenant isolation. For you: many customers, one system, kept cleanly apart.
- GPU-accelerated analytics — it harnesses your graphics card's massive parallel power. For you: heavy graph algorithms finish in a flash, with a graceful fallback when no GPU is present.
- It documents itself. Every built-in function and procedure carries its own name, category, and plain-English description inside the engine. Run
SHOW FUNCTIONSorSHOW PROCEDURESand the database returns its complete, current capability catalog — descriptions and all. The documentation can never drift from reality, because it comes straight from the engine itself. For you: no stale manual to chase; ask the database what it can do, live, any time.
Go deeper: the capability menu
From importance ranking and community detection to shortest-path and connectivity analysis, the analytics run inside the engine, right next to your data — no exporting to a separate analytics system first.
Translated into everyday outcomes: importance ranking is the math behind "who are the key players here" — the most influential account, the hub that holds a supply chain together. Community detection finds the natural clusters — the friend groups, the customer segments, the rings that act in concert. Shortest path is the "how is A connected to B, and by what route" question — the same idea a map app uses to route you, applied to people, money, or parts. And find-by-meaning is what lets you ask "show me more like this" even when nothing shares an exact keyword. You don't have to know the names of these tools to benefit from them; you just ask your question, and the right one runs.
See it in plain English
One of the nicest things about a graph query is that it reads almost like the question you're asking. Here's a tiny one:
Don't worry if you've never written a line of code — you don't need to. The
point of looking at this isn't to teach you to write queries; it's to show you that a
graph question is unusually readable. The little -[:KNOWS]->
arrows are just the strings from our whiteboard, drawn in text: "this dot KNOWS that
dot." Once you see that, the query stops looking like code and starts looking like a
sentence with arrows.
The query (Cypher)
MATCH (me)-[:KNOWS]->(friend)-[:KNOWS]->(fof), (fof)-[:LIKES]->(:Genre {name: 'Jazz'}) WHERE me.name = 'Ana' RETURN fof.name
In plain English
"Starting from Ana, follow the people she knows, then the people they know — and of those friends-of-friends, give me the ones who like Jazz."
The shape of the query mirrors the shape of the question. That's the whole appeal.
Now imagine asking that same "friends-of-friends who like jazz" question against an old-fashioned table-based system. You'd be matching a giant list of people against itself once to get friends, again to get friends-of-friends, and a third time to check who likes jazz — a paragraph of bookkeeping that hides the simple question underneath. The graph version keeps the question visible, which is why graph queries are so much easier to write and to trust: you can read one back and check that it's actually asking what you meant.
Go deeper: the same idea in GFQL
The very same "friends-of-friends who like jazz" idea can be expressed in GFQL, the second query language xrayGraphDB speaks — handy for data-frame-style pipelines. Full, runnable examples in both languages are in the docs.
Why offer two languages at all? Because teams arrive with different habits. Some think in Cypher, the familiar graph language whose arrows mirror the question; others think in data-frame "pipelines," where you start with a pile of rows and filter, join, and shape them step by step — and that's the crowd GFQL is for. Speaking both means your team doesn't have to relearn how it thinks just to use the engine; it meets people where they already are.
xrayGraphDB vs. the usual stack
The fair comparison isn't against any one product — it's against the pile of specialized systems a typical stack bolts together.
It's a bit like comparing a single well-equipped kitchen to a meal assembled from four takeout places across town. Any one of those restaurants might make a fine dish — this isn't an argument that they're bad at their jobs. The argument is about the assembly: the driving between them, the food going cold in transit, the order that arrives wrong because three kitchens didn't talk to each other. The table below reads down the column of jobs you actually need done, and shows how many separate "restaurants" each one would normally require.
| The job | What you'd otherwise need | With xrayGraphDB |
|---|---|---|
| Connected-data questions | A graph database | Built in |
| Find by meaning (AI retrieval) | A separate vector database | Built in |
| Crunching the numbers | A separate analytics database | Built in |
| Keeping it all in sync | Custom glue code + sync jobs | Not needed — one copy |
| A real-time answer | Hops across systems | No hops — one engine |
We compare against categories — graph database, vector database, analytics — not head-to-head against named vendors. The point is the shape of the stack, not a brawl.
Go deeper: where each tool still shines
A dedicated transactional relational database is still the right home for, say, your billing ledger. xrayGraphDB earns its place by collapsing the specialized connected-data, AI-retrieval, and analytics systems into one — not by claiming to be everything.
A good rule of thumb: keep the plain, list-shaped, money-moving records — orders, invoices, accounts — in the relational database you already trust, and reach for xrayGraphDB the moment the question becomes a connection question, a find-by-meaning question, or a crunch-the-whole-network question. The honest, durable version of the pitch isn't "throw everything away." It's "stop running three or four specialized systems where one engine does the job — faster, and with one copy of the truth."
Plain-English glossary
Every term on this page in one line each — skim it now, or keep it open in a tab as a cheat-sheet while you read the rest. None of these are as scary as they sound once you have the everyday version.
- Graph — a web of things and the connections between them.
- Node — one "thing" in the graph (a person, account, product).
- Edge / relationship — a labeled link between two nodes.
- Property — a piece of data on a node or edge (a name, a date).
- Hop — one step along a relationship; "two hops out" means friends of friends.
- Vector / embedding — a numeric "fingerprint" of meaning, so similar things sit near each other.
- Semantic search — finding things by meaning rather than exact keywords.
- Cypher — a popular, readable language for asking graph questions.
- GFQL — a second, data-frame-style query language xrayGraphDB also speaks.
- RAG — "retrieval-augmented generation," giving an AI the right facts to answer well.
- Multi-tenant — serving many customers from one system, kept isolated.
- Vectorized — processing many records in a single sweep instead of one at a time, for speed.
- GPU-accelerated — using your graphics card's massive parallel power to finish heavy graph work fast.
- Warm query — a query whose data is already close at hand, so it returns almost instantly.
- Encryption at rest — your data is stored scrambled; only your keys unlock it. xrayGraphDB does this per-tenant with AES-256, always on.
- AES-256-GCM — the specific, widely trusted recipe used to scramble that data.
- FIPS — the U.S. government's standard for validated cryptography; xrayGraphDB's crypto meets it.
- Self-documenting — the database carries its own manual inside it; ask it
SHOW FUNCTIONSand it lists every capability with descriptions, always current.