Security without the speed tax

Most databases force you to choose

The usual deal is brutal: you can have strong encryption or you can have speed — not both. Turn encryption on elsewhere and watch performance drop.

That's because, in most systems, encryption is a bolt-on — an extra layer you switch on, sitting on top of an engine that wasn't designed for it. So it costs you, every query, and teams end up quietly leaving protections off to keep things fast. xrayGraphDB refuses that trade-off.

Bolt-on encryption is like locking your valuables in a safe that lives in another building. Every time you need something, you go over, unlock it, come back — and every trip costs you. The lock works, but it makes everything slower, so people stop using it. The fix isn't a faster trip; it's a safe built into the room you're already in.

What "encryption at rest" even means

Before the differentiator makes sense, it helps to know the plain-English version of a couple of terms.

• "At rest" means your data while it's stored — sitting on disk, waiting to be used. If someone made off with the physical drive, "encryption at rest" is what makes that drive a brick of meaningless scramble instead of a readable copy of your data.
• "Encrypted" means the stored data is scrambled with a secret, so that without the right key it's just noise. The right key turns it back into real data; the wrong key — or no key — gets you nothing useful.
• "Native" vs. "bolt-on" is the whole story of this chapter. Native means the protection is part of how the engine works in the first place. Bolt-on means it's an afterthought layered on top — which is exactly why it's slow elsewhere.

"At rest" is your data asleep in its bed. The question every security team asks is: if a thief gets into the house, what do they actually find? With encryption at rest, they find a scrambled mess they can't read — not your customers' records.

The reason "secure" usually means "slower" everywhere else

Here's the mechanism, in plain terms. When encryption is bolted on, your data takes a detour on every single read and write: the engine does its normal work, then hands the data off to a separate protection layer to scramble or unscramble it, then takes it back. That extra round-trip happens constantly — on every query — and it adds up fast.

Because the cost is so visible, the predictable thing happens: under deadline pressure, teams quietly switch protections off "just for now" to hit their speed targets. The feature that was supposed to keep data safe becomes the feature nobody dares turn on. xrayGraphDB removes the temptation entirely by removing the detour — and, as you'll see, by removing the off switch.

Encryption is built in, not bolted on

Encryption at rest in xrayGraphDB is native — it's part of the engine's fast path, not a toggle you flip and pay for. Your data is stored scrambled, and here's what that protection looks like at the feature level:

• AES-256-GCM — the algorithm that scrambles your data is the same one the U.S. National Security Agency approves for protecting information classified up to Top Secret. (That's a statement about the strength of the algorithm.)
• Per-tenant key isolation — each tenant's data is protected with its own independent key, kept separate from every other tenant's. One customer's data can't be unlocked with another's.
• Always on, no off switch — you can't accidentally ship with encryption disabled, because there's no way to disable it. Protected is the only mode.
• FIPS-validated cryptography — the cryptography runs on a validated foundation and already meets FIPS 140-2, SOC 2, and HIPAA requirements.

We describe protection at the feature level — what it does for you and your customers — rather than the mechanics under the hood.

What "per-tenant key isolation" buys you

If you run software for many customers at once, this is the line that matters most. Each customer's data is locked with its own separate key. So even in the worst case — a bug, a mistake, an attacker poking around — one customer's data can't be unlocked using a different customer's key. The barriers between customers aren't just a rule the software follows; they're baked into the locks themselves.

It's an apartment building where every unit has its own lock and its own key — not a single master key that opens everything. Your key opens your door and only your door. That's the difference between "we promise to keep tenants apart" and "it is physically not possible to open the wrong door."

FIPS, NSA, CNSA — what they mean for a non-expert

These letters get thrown around in security marketing. Here's what each one actually means in plain English, and exactly how strong a claim we're making with it.

• AES-256-GCM — the specific scrambling method. It's the algorithm the U.S. NSA approves for protecting information classified up to Top Secret. Read that carefully: it's a statement about how strong the algorithm is, the same kind of math trusted at the highest levels. It is not a claim that this product carries a Top Secret clearance.
• FIPS 140-2 — a U.S. government standard for cryptography. "FIPS-validated" means the cryptographic foundation has passed that formal bar — an outside, government-recognized check that the crypto is implemented properly, not just claimed to be.
• SOC 2 / HIPAA — the requirement sets that auditors and healthcare regulators care about. Meeting them is the practical, paperwork-real test of whether your encryption is "good enough" for regulated, sensitive data. xrayGraphDB's cryptography already meets these.
• NSA — the U.S. National Security Agency, the body whose approval of an algorithm is the high-water mark for "this math is trusted to protect serious secrets."
• CNSA-grade — the modern suite of cryptography intended for protecting sensitive and classified national-security information. "Designed to a CNSA-grade bar" means the architecture was built to that high standard from the start.

Think of AES-256-GCM as a particular brand of vault door that banks and governments trust. Saying "we use that vault door" is true and meaningful. It is a different claim from "a government has inspected our whole building and certified it for top-secret storage" — and we are careful never to blur those two.

It's included in the speed

Here's the part that surprises people: all of that protection is included in the speed numbers from the previous chapter.

The roughly 0.2 ms warm queries and the thousands of requests per second — that is the encrypted engine. There's no "fast mode" with the protection turned off and a "secure mode" that crawls. You never choose between locked-down and fast. You get both, on the same server, at the same time.

That's the differentiator in one sentence: where others make you trade security for speed, xrayGraphDB folds the security into the speed.

Most products sell you a fast car and an armored car, and make you pick. xrayGraphDB is the fast car that's already armored — the protection isn't weighing it down, because it was engineered in from the chassis up rather than bolted to the outside afterward.

And because there's no off switch, that protection is always the thing you're actually benchmarking. Nobody can quietly disable it to chase a faster number — the number you see is the protected number, full stop.

Built for high-assurance environments

The architecture is designed to meet the requirements of classified, high-assurance environments — the kind of bar described by CNSA-grade standards (the modern suite of cryptography intended for protecting sensitive and classified national-security information).

One thing we're careful to say plainly: formal accreditation is in progress. Designing to a standard and being formally accredited to it are two different things, and we won't blur them.

Why be this fussy about wording? Because in security, an honest claim is worth more than a flashy one. Plenty of products imply a clearance they don't hold. We'd rather you know exactly where the line is: the algorithm is at the Top-Secret-approved level; the product's formal accreditation is underway, not done. Both of those are true, and we won't round either one up.

Security FAQ

• Does turning on encryption slow my queries down? No — that's the whole point. The protection is part of the fast path, so the speed numbers you see are already the encrypted numbers. There's no separate, slower "secure mode."
• Can someone accidentally ship with encryption off? No. There's no off switch to forget. Protected is the only mode the engine runs in.
• Is xrayGraphDB certified for Top Secret data? No, and we won't say it is. The algorithm it uses (AES-256-GCM) is the one the NSA approves for information classified up to Top Secret — that's a statement about the algorithm's strength. The product's own formal accreditation is in progress, not finished.
• What protects my customers from each other? Per-tenant key isolation: each tenant's data is locked with its own independent key, so one customer's data can't be unlocked with another's.
• Will this satisfy my auditors? The cryptography is FIPS-validated and already meets FIPS 140-2, SOC 2, and HIPAA requirements — the bars regulated and healthcare data are usually held to.