Faster than you can blink
"Fast" is hard to picture, so let's anchor it to your own body: a blink of your eye takes about 100 milliseconds. A warm xrayGraphDB query returns in about 0.2 ms — hundreds of times quicker than a single blink.
Put differently: in the time it takes you to blink once, xrayGraphDB could answer hundreds of separate questions. That's the gap we're talking about — not "a little snappier," but a different category of fast, the kind where the wait simply disappears and an answer feels like it was already sitting there waiting for you.
Bars are illustrative; the 0.2 ms and blink figures are real reference points.
Think of it like the difference between mailing a letter and sending a text. Both deliver the message — but one of them is over before you've finished thinking about it.
"Warm query" and "pipelined," in plain English
Two phrases show up whenever people talk about database speed. They sound technical, but the ideas behind them are everyday-simple.
What a "warm query" means
The very first time you ask a brand-new question, the database has to do a little setup — figure out the best way to find the answer, and pull the relevant data close. That's a cold query. Ask a similar question again and everything's already in place and ready — that's a warm query, and it's the speed you actually live with day to day, because real apps ask the same shapes of questions over and over.
It's the difference between cooking in a kitchen you've never used (where's the salt?) and cooking in your own kitchen, where your hand already knows which drawer to open. The 0.2 ms number is the "your own kitchen" number.
What "pipelined" means
Imagine a coffee shop with one barista. If they make a drink, hand it over, wait for the next customer to step up, take the order, then start the next drink, the line crawls. Now imagine they start the next drink while the last one is still being handed off — orders flowing in a continuous stream, no dead time between them. That's pipelining: keeping the work flowing back-to-back instead of stopping and restarting for each request. It's why a system can answer far more questions per second than its single-question time alone would suggest.
Three reasons, in plain English
You don't need to know the internals to understand why xrayGraphDB is quick. It comes down to three ideas, and each one is something you can picture.
1 · A vectorized engine
Most databases handle data one record at a time, like a cashier scanning items one by one. A vectorized engine processes thousands of records in a single sweep — more like running a whole cartload through at once. Doing the work in big batches instead of one-at-a-time is a huge part of why answers come back so fast.
Picture a tollbooth that can wave through an entire busload of cars in the time an old booth takes for one. Same road, same cars — the bottleneck just stopped being a bottleneck.
There's a hidden bonus, too. When a computer does the same simple operation across a long, neat row of numbers all at once, it does it with far less wasted effort — fewer stops, fewer detours, fewer "wait, where was I?" moments. Doing things in tidy batches isn't just more work per sweep; it's cleaner work, and clean work is fast work.
2 · GPU-accelerated analytics
Your computer's graphics card (its GPU) is built to do an enormous number of small calculations at the same time — that's how it paints millions of pixels every frame in a video game. xrayGraphDB can harness that same massive parallel power for heavy graph analytics, so big algorithms finish in a flash. When no GPU is present, it falls back gracefully and still runs.
A regular processor is a handful of very fast, very clever workers. A GPU is thousands of simpler workers who can all push at once. For a job like "score every single node in a giant network," thousands of hands beat a few brilliant ones — the work is the same on every node, so you just want a lot of help doing it simultaneously.
3 · No cross-database hops
This is the theme of the whole guide. Because the graph, the meaning-based search, and the analytics all live in one engine, an answer never has to travel across a network of separate databases to get assembled. The hops that slow down a typical multi-database stack simply don't exist here — there's only one system to ask.
Every time data has to cross from one system to another, it's like a relay race handoff — and every handoff costs time and is a chance to drop the baton. xrayGraphDB runs the whole race with one runner. There's no handoff to slow down, because there's nobody to hand off to.
This one is sneaky because each hop seems small — a few milliseconds here, a few there. But real questions touch several systems, and those little waits stack up into the ~100 ms (and worse) you feel as "loading." Removing the hops doesn't just shave a slice off; it removes the whole category of delay.
Three numbers, in plain English
You don't need to have read anything else first. Here are the three speed results that matter — and what each one would actually feel like.
- A typical answer in about 0.2 ms (that's two ten-thousandths of a second) — hundreds of times quicker than the blink of an eye. To a person, it's instant: the screen reacts the moment you tap.
- About 8,927 answers every second, from one engine — not nine thousand computers, one. Picture a packed stadium section of nine thousand people and answering a different question for every single one of them, finishing the whole section in one second. That's the pace it keeps up.
- It finished a giant, real-world job that broke every system it was tested against — the headline result. What that job was, and why it's so hard, is worth a minute — it's the next part.
Wait — what's "Friendster," and why is this the real flex?
Friendster was one of the very first social networks — big in the mid-2000s, before Facebook took over. Researchers kept a snapshot of it, and today that snapshot is a kind of torture test for graph systems. It's not made-up data: it's roughly 65 million real people and 3.6 billion friendships between them — more connections than there are people on Earth.
"Traversing" that graph just means following the friendships to answer questions — things like who are the most influential people, how are two strangers connected through mutual friends, which clusters form tight-knit communities. Doing that across 65 million people and 3.6 billion links is genuinely hard: the data is huge and lopsided (some people have a handful of friends, some have tens of thousands), and most systems simply run out of memory and give up partway through.
xrayGraphDB ran every one of those analyses and carried the whole thing to a finished answer — on the same hardware where the systems it was compared against couldn't complete it at all. That's the point: being quick on small, tidy questions is common. Being able to take on a messy, planet-sized problem and actually cross the finish line is the rare part — and it's a good sign your own data won't be the thing that breaks it.
Go deeper: where these numbers come from
They're from a real benchmark run, not marketing estimates — xrayGraphDB measured against a leading GPU-accelerated graph library plus seven other systems (eight comparison points, not one cherry-picked rival), on real datasets up to that 3.6-billion-connection Friendster graph rather than small, clean, made-up data. Real data matters: toy datasets are tidy in ways that flatter a system, and messy real graphs are exactly where many systems stumble.
If you ever want to check the math yourself, the full methodology, the exact hardware, and the per-algorithm results are all published — we'd rather you verify than take our word for it.
Fast-speed FAQ
- Do I need a GPU to get good speed? No. The GPU supercharges heavy analytics, but the engine is fast on its own and falls back gracefully when no GPU is present. The GPU is an accelerator, not a requirement.
- Is the 0.2 ms a best-case stunt? It's the warm query number — the everyday case real apps live in, where the same shapes of questions get asked again and again. It's the realistic day-to-day figure, not a one-off lab record.
- Does speed mean the data is less safe? No — and this is the surprising part. The speed numbers on this page are the encrypted engine. There's no "turn off the protection to go fast" mode. That's the next chapter.
- Will it slow down as my data grows? The Friendster result is the answer to scale: it finished a 3.6-billion-edge workload that broke other systems. Big data is exactly where the design is meant to hold up.
And it's all encrypted at the same speed
Here's the part most people don't expect: those speed numbers are the encrypted engine. xrayGraphDB doesn't make you choose between "secure" and "fast" — the protection is built into the same fast path. That's the next chapter.