What it can actually do

One engine, a surprising number of jobs

Most teams stitch together a pile of separate tools: one for connected data, one for search, one for analytics, one for AI retrieval. xrayGraphDB does these jobs in a single engine, over a single copy of your data.

This chapter is a guided tour of what that single engine can actually do. Each capability comes with a plain "what that means for you" so it's never just a feature name — it's a thing you could build on Monday. Here's the lay of the land before we dive in:

• Query connected data — ask questions about relationships directly, in the language your team already knows.
• Find patterns & paths — surface the shape of your data: rings, routes, hubs, bottlenecks.
• Search by meaning — find things that are similar, not just things that match a keyword.
• GPU-accelerated analytics — run heavy graph algorithms right next to your data.
• Real-time, multi-tenant, and a deep toolbox — live answers, many customers kept cleanly apart, hundreds of built-in functions.
• Self-documenting — the engine carries its own capability catalog; ask it SHOW FUNCTIONS and it tells you exactly what it can do, always current.

Ask questions of your connections — in Cypher or GFQL

The core job: follow relationships directly to answer connection questions. xrayGraphDB speaks two query languages, so your team can use the one it already knows:

• Cypher — the popular, readable graph language. A query tends to look like the question you're asking. For you: a gentle on-ramp; if anyone on your team has touched graphs before, they'll feel at home.
• GFQL — a second, data-frame-style query language for pipeline and analytics-flavored work. For you: a natural fit if your team thinks in data frames rather than graph patterns.

Why does "connected data" even need its own kind of question? Because relationships are the part a normal table is worst at. In a spreadsheet, "who are this person's friends" is easy — but "who are the friends of their friends, three steps out" turns into a tangle of joins that gets slower with every hop. A graph engine is built to follow those hops directly, so the hard relationship questions become the natural ones.

A table is great at "what is this thing." A graph is great at "how is this thing connected to everything else." Most of the interesting questions in fraud, logistics, and social data are the second kind — and that's exactly the kind this engine is built for.

What that means for you: "friends of friends," fraud rings, supply chains, who-influences-whom — asked directly, in a language you choose. See a real query in plain English →

Find hidden patterns and the paths between things

Beyond simple lookups, xrayGraphDB finds structure: the route between two points, the cluster of accounts that quietly work together, the most important hub in a network.

• The path between two things — how are these two connected, and by how many steps? For you: "how does this supplier reach that customer," or "what's the chain linking these two accounts."
• The pattern that repeats — a shape that shows up again and again, like the same handful of accounts moving money in a circle. For you: catch the structure of a scheme, not just one bad transaction.
• The hub that everything leans on — the single node that, if it failed, would break the most connections. For you: find the critical part, the single point of failure, the ringleader.

A table can tell you each transaction is fine on its own. Only looking at the shape reveals that five "fine" accounts form a perfect little loop that moves money in a circle — the fraud ring you'd never spot one row at a time.

What that means for you: surface the shape of your data that you simply can't see in a table — the ring, the bottleneck, the influencer, the shortest route.

Semantic / vector search — find by meaning, not keywords

xrayGraphDB has native vector / embedding search built in. Instead of matching exact words, it finds things that are similar in meaning — the backbone of modern AI retrieval.

Old-style keyword search is literal: search "car" and it misses every document that said "automobile" or "vehicle." Meaning-based search understands that those are the same idea, so it returns the right results even when not a single word matches. That's the leap that makes search feel smart instead of brittle.

• "More like this" — show records similar to one you're looking at, even with zero shared keywords. For you: recommendations, related items, "customers who looked at this also looked at…"
• Context for AI assistants — pull the handful of most-relevant documents to feed an AI so it answers from your real data. For you: the retrieval half of a trustworthy AI assistant — built in, no separate system.

Keyword search is a librarian who only finds books whose titles contain your exact words. Meaning-based search is a librarian who actually understood what you're after and hands you the right book even if it's titled something completely different.

What that means for you: "show me records like this one," even when they don't share a single keyword. This is what powers recommendations and gives AI assistants the right context to answer well — and it's built in, so there's no separate vector database to run.

Heavy graph analytics, harnessing the graphics card

The analytics run inside the engine, right next to your data — no exporting to a separate analytics system first — and can be GPU-accelerated, harnessing your graphics card's massive parallel power to finish big jobs in a flash (with a graceful fallback when no GPU is present). The built-in algorithms include, by name:

• PageRank — ranks the most important or influential nodes in a network. For you: "who or what matters most here?" — the most-cited researcher, the most-relied-on supplier, the account everyone connects through.
• Community detection — finds clusters of closely-connected things. For you: natural groupings, customer segments, departments that really work together, or suspicious clusters that bunch up where they shouldn't.
• Shortest path — the most direct route between two nodes. For you: routing, "how are these two connected," degrees of separation, the fastest way to get from A to B through your network.
• Centrality — measures how central or well-connected each node is. For you: find the hubs, the bottlenecks, and the key connectors — the parts that quietly hold everything together.

"Next to your data" is the unsung hero here. In a typical setup you'd copy your data out to a separate analytics tool, wait, run the job, and copy the answer back — slow, and out of date the moment it finishes. Running the algorithm right where the data already lives means the answer reflects what's true now, with no export-and-wait dance.

It's the difference between shipping all your files to an accountant across town and having the accountant working at the desk next to yours. Same analysis — but no packing, no shipping, no waiting for it to come back.

Live answers, many customers, cleanly apart

• Real-time results — answers come back fast enough to sit in a live request, not just an overnight report. For you: power features that react as users act — a recommendation that updates as someone clicks, a fraud check that runs before a payment goes through, not the morning after.
• Multi-tenant with per-tenant isolation — serve many customers from one system, kept cleanly separate. For you: one system to run, many customers served, each one's data kept apart — the foundation of any product where many businesses share the same software but must never see each other's data.
• Hundreds of built-in functions and a dual protocol — a deep toolbox plus flexible ways to connect. For you: less custom code to write, because the common building blocks are already there, and it's easy to plug into what you already have through more than one standard way to connect.

What "hundreds of built-in functions" saves you

A built-in function is a ready-made tool for a common job — counting, summarizing, reshaping, comparing, working with text and dates and lists. When the database already ships with hundreds of them, the everyday work you'd otherwise hand-code is just… already there. That's less custom code to write, less to test, and less to maintain — your team spends its time on the parts that are actually unique to your product.

It's the difference between a kitchen stocked with every utensil you could need and one where you have to whittle your own spoon before every meal. The deep toolbox is why you get to skip the busywork and go straight to cooking.

It documents itself

Here is something most databases don't do: xrayGraphDB carries its own manual inside the engine. Every built-in function and procedure has its name, category, signature, and a plain-English description baked in from the start — not bolted on later and not kept in a separate file that drifts out of date.

You can ask the database what it can do, live, with two real commands:

• SHOW FUNCTIONS — returns every built-in function with its name, category, and description.
• SHOW PROCEDURES — returns the full catalog of built-in procedures the same way.

Why does this matter? Because in every other system the documentation lives somewhere else — a web page, a PDF, a wiki entry — and the moment a new version ships, some of those pages are already wrong. When the descriptions are inside the engine, they can't get out of sync: whatever the running database says it can do is exactly what it can do, right now, guaranteed. The interactive docs site and this very Learn section are generated directly from the database describing itself — so the docs and the engine always agree by construction.

What that means for you: no hunting for a stale manual. Just ask the database, and it answers. SHOW FUNCTIONS is a real command, available any time you have a connection open.

Want the full reference? Every built-in function and procedure the engine ships is listed — with its signature, category, and examples — in the interactive API documentation →, generated from this same self-describing catalog so it never drifts from the running engine.

Why one engine beats a pile of tools

Any one of these capabilities exists somewhere else. The point of xrayGraphDB is that they live together, over one copy of your data — so you can chain them in a single question instead of bolting separate systems together with glue code.

Imagine asking, in one breath: "find the records most similar to this one, follow their connections two steps out, and tell me which of those is the most important hub." With separate tools that's three systems and a lot of plumbing. Here it's one engine, one copy of the data, one answer.

That's the through-line of this whole guide: fewer moving parts, less to break, and questions you couldn't easily ask before become natural.