Security & trust

Security in the engine.
Not bolted on.

Multi-tenancy is a clause, not a library. Authorization is JSON policies with explicit deny. Row-level security is PostgreSQL-style boolean predicates. Secrets live in an in-file vault sealed by a certificate you own.

Talk to security

Or read the full threat model in the docs

AGPL-3.0 auditable SOC 2 in progress · 2026 Q3 DPA on request BYOK on Cloud Scale (roadmap)

Last updated · 2026-05-04

Tenant isolation

First-class multi-tenancy.

Most databases leave tenant scoping to the application — one missed WHERE clause and a customer reads another customer's data. RedDB declares it on the table and the engine enforces it.

-- Declarative tenant column. RLS auto-installed.
CREATE TABLE users (
  id INT,
  email TEXT,
  tenant_id TEXT
) TENANT BY (tenant_id);

-- Session handle, set by middleware after auth.
SET TENANT 'acme';

-- Every read and write is now scoped to acme.
SELECT * FROM users;

Three patterns, pick the one that fits your scale and tenant count.

  • Row-based declarative

    CREATE TABLE ... TENANT BY (col)

    Default SaaS, low overhead, many small tenants.

  • Schema-based

    CREATE SCHEMA acme; CREATE TABLE acme.users (...)

    Strong isolation, per-tenant migrations.

  • Collection-per-tenant

    users_acme, users_globex

    Per-tenant scale or retention rules.

Vault

One file. No detached keystore.

Everything an attacker would want on a stolen .rdb — credentials, API key hashes, SCRAM verifiers, OAuth state, application secrets — lives inside the vault, encrypted at rest. No second file to back up. No second filesystem path to protect.

Cipher & KDF

  • cipher AES-256-GCM (AEAD)
  • aad b"reddb-vault"
  • nonce 12 bytes random per write
  • salt 16 bytes, persisted in header
  • kdf Argon2id m=16MB t=3 p=1

Vault occupies reserved pages 2 and 3 of the database file, written under double-write discipline. Pages 2 and 3 are encrypted before they hit the pager.

Sealed by certificate

On first bootstrap you receive a certificate, once. There is no key escrow, no recovery code, no backdoor.

Operators who skip the offline backup of this certificate will, eventually, lose data — we are explicit about this in the docs.

Pager-level encryption is v1.1 roadmap (requires file-format version bump). For at-rest today, use cloud volume encryption or dm-crypt — Cloud volumes are encrypted by default.

Authorization

IAM-style policies. Without the IAM ceremony.

Postgres GRANT is action-on-resource but global, no expiry, no IP gating, no MFA gating. AWS IAM has the gates but takes 80 lines of JSON for "give Alice read-only on this table." RedDB drops the unused ceremony and keeps the model.

// IAM-style JSON policy — version-controllable, simulatable.
{
  "version": 1,
  "id": "analyst",
  "statements": [
    { "sid": "read-public",
      "effect": "allow",
      "actions": ["select"],
      "resources": ["table:public.*"] },
    { "sid": "block-pii",
      "effect": "deny",
      "actions": ["select"],
      "resources": ["column:users.email", "column:users.phone"] }
  ]
}

  • Deny-by-default once policies exist

    The legacy three-role model (read/write/admin) still works for clusters that never created a policy. The moment any policy exists, the engine flips to deny-by-default — only your explicit allow/deny statements are honored.

  • Simulate before you ship

    POST /admin/policies/simulate answers "would Alice be allowed this action on this resource?" — including which policy matched, which sid, and why.

  • Conditions: IP, MFA, time-of-day

    Statements accept condition blocks (ip-prefix, mfa-required, hour range). The vocabulary is shared across SQL, HTTP and the audit log.

Row-level security

PG-style RLS, on every model.

Boolean predicates evaluated per row, AND-folded into the user's WHERE. Same syntax you already know from PostgreSQL — except it also works on vectors, graph nodes/edges, queue messages and document collections.

-- PostgreSQL-style RLS. Predicates evaluated per row.
CREATE POLICY own_rows
  ON documents
  USING (owner_id = CURRENT_USER());

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Combined per-action with OR, AND-folded into the user's WHERE.

Authentication

Six methods. Pick the one that fits.

The RedWire handshake advertises which methods the server has enabled, so drivers pick the strongest one without an extra probe round-trip.

API key

rdb_k_*

Service accounts, CI.

Session token

rdb_s_*

Interactive logins.

OAuth / OIDC JWT

JWT

External IdP federation (SAML/OIDC).

mTLS

X.509

Zero-trust mesh, service-to-service.

SCRAM-SHA-256

RFC 5802

Drivers wanting challenge/response without TLS.

HMAC

signed

Tamper-evident, replay-protected calls.

Compliance

Honest about where we are.

We will not claim a control we have not earned. Below is the current state — we update this page when something moves, not when a marketing cycle does.

SOC 2 Type II

In progress · 2026 Q3 target

Gap assessment complete. Observation period running. Report shipped when signed.

ISO 27001

Scoping in 2026 H2

Sequenced after SOC 2 lands. No earlier date promised.

GDPR / LGPD

DPA on request

Standard DPA available. EU regions on request for Cloud Scale.

PCI / HIPAA

Not in 2026 scope

Talk to us if these are blockers — we will say yes or no honestly.

AGPL audit

Read every line

Same Rust binary in Cloud and self-host. cargo audit on every PR.

BYOK

Roadmap · Cloud Scale

Vault is sealed by a certificate today. BYOK lets Cloud customers hold their own seal.

Vulnerability disclosure

Found something? Tell us privately first.

We take security reports seriously. Email us privately first; we acknowledge within 48 business hours and coordinate disclosure within 90 days for non-critical issues, faster for critical ones.

  • Email: security@reddb.io
  • PGP key: /.well-known/pgp-key.txt
  • Coordinated disclosure: 90-day default window, negotiable for critical.
  • No formal bounty program yet — we credit reporters in CHANGELOG and on this page.

FAQ

The questions security teams actually ask.

Encryption, BYOK, audit, disclosure. If your question is not here, email us.

Where is encryption at rest in v1.0?

Honest answer: pager-level encryption is on the v1.1 roadmap (file-format version bump). v1.0 ships AES-256-GCM for the in-file vault and SCRAM/HMAC primitives. For at-rest protection today we recommend infrastructure encryption — cloud volume encryption, S3/R2/GCS bucket-side encryption, or dm-crypt/LUKS for bare metal. Cloud volumes are encrypted by default.

Is RedDB Cloud SOC 2?

SOC 2 Type II is in progress with a target of 2026 Q3 — gap assessment complete, observation period running. We will publish the report when it lands; we are not claiming compliance until it is signed.

Can I bring my own keys (BYOK)?

BYOK on Cloud Scale is roadmap. The vault is sealed by a certificate you own — there is no key escrow, no recovery code, no backdoor. If a Cloud customer wants to hold their own seal, that is the BYOK story we are building toward.

How do you handle a stolen .rdb file?

Usernames, password hashes, SCRAM verifiers, API key hashes, session tokens, OAuth state and red.secret.* application secrets all live inside the vault — encrypted at rest with AES-256-GCM, sealed by a certificate and Argon2id-derived key. Without the certificate, the vault is opaque.

Can my security team audit the engine?

Yes — that is the AGPL-3.0 deal. The engine is a single Rust binary; the Cloud build is the same binary, just managed. Run cargo audit, run static analysis, rebuild from source. No closed-source feature flags.

How do I report a vulnerability?

Email security@reddb.io. We acknowledge within 48 business hours, coordinate disclosure within 90 days for non-critical issues, faster for critical ones. PGP key at /.well-known/pgp-key.txt. No formal bounty program yet — we credit reporters in CHANGELOG and on this page.