Skip to content

RedDB navigation

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

  • BSL 1.1 · source available
  • SOC 2 in progress · 2026 Q3
  • DPA on request
  • BYOK on Cloud Scale (roadmap)

Last updated · 2026-05-04

Built into the engine

  • Tenant isolation as a CREATE TABLE clause.
  • IAM-style JSON policies with explicit deny + conditions.
  • Row-level security on every model — tables, documents, graphs, vectors, KV, cache, time-series, queues and probabilistic.
  • Six auth methods — API key, session, OAuth/OIDC, mTLS, SCRAM, HMAC.
  • Vault inside the same .rdb file. No detached keystore.
  • TLS 1.3 across HTTP, gRPC and RedWire.

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.

RedDB SQL 
-- 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.

  1. Row-based declarative
    CREATE TABLE ... TENANT BY (col)

    Default SaaS, low overhead, many small tenants.

  2. Schema-based
    CREATE SCHEMA acme; CREATE TABLE acme.users (...)

    Strong isolation, per-tenant migrations.

  3. 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.

JSON policy 
// 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.

RedDB SQL 
-- 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.

  • rdb_k_*

    API key

    Service accounts, CI.

  • rdb_s_*

    Session token

    Interactive logins.

  • JWT

    OAuth / OIDC JWT

    External IdP federation (SAML/OIDC).

  • X.509

    mTLS

    Zero-trust mesh, service-to-service.

  • RFC 5802

    SCRAM-SHA-256

    Drivers wanting challenge/response without TLS.

  • signed

    HMAC

    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.

Source 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.

Talk to security

Direct line

Buyers, auditors and CISOs — if you need a control mapped, a question answered for procurement, or a deeper threat-model walk-through, write us.

security@reddb.io

Prefer asynchronous? Subscribe to security updates — disclosed advisories and compliance milestones, no marketing.

The questions security teams actually ask.

Encryption, BYOK, audit, disclosure.

If your question is not here, email us.