Security at OriginChainDB.
OriginChainDB is a managed AI-native database, region-isolated by default, encrypted in transit and at rest, with every privileged action audit-logged. On dedicated configurations, compute and database storage are not shared with any other customer; Free and Starter run on shared, scale-to-zero infrastructure. Trading positions, patient vitals, and inventory ledgers run on it today.
Single-tenant on dedicated configurations. Shared, scale-to-zero on Free and Starter.
Dedicated configurations run on virtual machines that serve only that one customer, and their compute and database storage are not shared with any other customer. Free and Starter run on shared, scale-to-zero infrastructure, where many customers' databases share the same servers. On Free, each database has its own storage limit, enforced by the file system, and its own bearer token, and while it is awake it runs in its own engine process with its own data directory.
Dedicated compute
On dedicated configurations, compute runs on virtual machines that serve only that one customer: a single-node configuration is one virtual machine, and a high-availability configuration runs a writer and standby nodes, each on its own virtual machine, spread across zones. Free and Starter do not include dedicated compute.
Dedicated storage
On dedicated configurations, database storage is not shared with any other customer: a single-node configuration has its own encrypted block volume, each high-availability node has its own block volume, and point-in-time archives sit under a per-instance path that only that instance's credentials can access. On Free, each database has its own storage limit, enforced by the file system.
Its own hostname and token
Each database has its own hostname and its own bearer token. On dedicated configurations that token is scoped to that one database. Connections to a Free database are encrypted with TLS up to our shared load balancer, then routed over our private network to the database.
Tenant-scoped at the storage layer
Inside the storage engine, every database's rows and table definitions are keyed by its own tenant id - on every plan, including the shared ones.
Encrypted in transit and at rest.
TLS on every public endpoint. AES-256 on every disk. Customer-managed keys available on Enterprise.
TLS 1.2 minimum, TLS 1.3 preferred, on every external endpoint and every replication hop. Per-region auto-renewing wildcard certificates. New certs are picked up without restart.
All block volumes encrypted with AES-256 by the managed-disk service. Keys rotated automatically by the managed key service on managed configurations.
Bring your own key. Customer-managed keys wrap the data key; revocation severs decrypt instantly. Available on Enterprise.
Backups, replica streams, and OTLP exports all flow over TLS to encrypted storage. The backup channel never leaves your region.
A bearer token per database, constant-time check.
Each database has its own bearer token. Comparison is constant-time. Rate limits are per-key, fairness is enforced inside the commit window, and every write supports idempotency.
On dedicated configurations, long-lived API keys (oc_live_sk_…) and short-lived JWTs both resolve to the same (TenantId, roles) tuple at the ingress, and a mismatch returns 403, never a row from the wrong table. Each Free database has its own hostname and its own bearer token. Token comparison is constant-time.
A four-dimension token bucket per API key - bytes/s, ops/s, ask/s, concurrent_queries - with per-key configurability. Fairness scheduling at the write path ensures a loud key cannot starve quiet ones inside the same tenant.
Every mutating request accepts an Idempotency-Key header. Replays return the original response, so retries are safe across timeouts, network blips, and proxy hiccups.
Mint, list, and revoke bearer tokens directly from the console. Rotation honors the previous key for 60 seconds - long enough for a rolling deploy, short enough to close a leaked token fast.
Every privileged action, append-only.
Console actions and administrative API calls - bearer mint, rotate, revoke, schema register, schema edit, PITR run, failover - land in an append-only events table. Retention follows your configuration; export to your SIEM at any time.
Recorded fields
RFC 3339, microsecond precision, UTC.
Bearer token id, console user id, or system principal.
Resource path: tenant, schema, key, or job id.
Mint, rotate, revoke, register, edit, restore, failover, export.
Source IP of the API or console request, captured at the ingress.
200 / 403 / 409 / 500 with the engine error code, when applicable.
Retention by configuration
90 days
365 days
Custom - contractual
See /pricing for the full pricing breakdown.
Durable on commit. Automatic failover. Snapshot and restore.
A write is acknowledged only after it is flushed to durable storage, so an acked write is on disk before you get the response. On high-availability configurations a standby can be promoted to take writes; automatic promotion is off by default and refuses a standby that is not fully caught up. On dedicated configurations storage is snapshotted daily to an encrypted vault, and off-box archiving with restore-to-timestamp is available in preview. Standby replication is asynchronous, so plan for the most recent writes to be at risk in an abrupt primary loss, and read the recovery caveats in ops → write durability.
A write is acknowledged only after it is flushed to durable storage on the instance. A 2xx means it has left the buffer and is on disk, so it survives the database process being killed. Recovery after an abrupt power loss or a full storage volume carries caveats - see /docs/ops#durability.
Replication does not block the primary's acknowledgement, so an abrupt loss of the primary can cost the most recent writes. How much is at risk depends on how far behind the standby had fallen - make your writes idempotent and retry on failover.
The old primary's claim has to expire and a grace window pass, before the standby is eligible. Automatic promotion is off by default, and when it is enabled it refuses to promote a standby that is not fully caught up. A single-primary claim fences the old primary, so promotion is atomic and split-brain cannot happen.
On dedicated configurations, every instance's storage is snapshotted daily to an encrypted vault, independent of anything running inside the database. This is the floor: on total instance loss, worst-case exposure is the time since the last snapshot.
With off-box archiving enabled, recent changes ship to encrypted object storage and you can restore to a chosen timestamp. Granularity tracks the archive cadence - seconds on a busy instance, up to tens of minutes on a quiet one. It is opt-in and still in preview; ask us before you depend on it.
A scheduled drill re-attaches a recent snapshot on a throwaway host and runs the engine's integrity check end-to-end. It covers the volume-snapshot path; the off-box archive path is drilled by hand, not on a schedule.
Backup retention
Retention is what we hold, and it is also what we delete. The automated snapshot vault expires on a 30-day schedule. Anything longer - and any deletion deadline you need us to meet - is agreed per deployment rather than selected from a menu, so ask us before you rely on a specific window for a compliance obligation. On a deployment spread across more than one node, snapshots are taken per node: a restore is per-node consistent, not coordinated across the whole group, so treat multi-node recovery as an operator-run procedure we scope with you.
Compliance posture.
Certifications in progress, plus the contractual instruments customers ask for first. Need an audit timeline, a letter of intent, or a security questionnaire? Talk to us.
Optimistic CAS - predictable, never silent.
Concurrent edits to the same row are protected by single-row
compare-and-set on a server-managed
_oc_row_version
column. A stale write fails fast with a version mismatch instead of
silently overwriting the other client's edit. Last-writer-wins is
explicit and predictable: the winner is the one who read the latest
version.
Single-row CAS
put_row_cas,
get_row_versioned,
delete_row_cas.
Every row carries a server-managed
_oc_row_version;
stale writes return a version mismatch, never a silent overwrite.
Always-on, minimal overhead, every API surface.
Email security@originchain.ai.
Send a minimal reproduction, the affected version, and your assessment of severity. For an encrypted channel, request our PGP key and we'll respond signed.
Reporters are credited by name in release notes unless they prefer to remain anonymous.
Scope is the OriginChainDB managed cloud, the engine binary, and the customer-facing console. The static marketing site is out of scope.
- 24 hours First human response acknowledging your report.
- 7 days Triage: severity, reproducibility, and a fix plan.
- 30 days Patch released or a public advisory, whichever comes first.
- + Remote code execution in any ingress path (HTTPS, SSE, the bearer-auth layer)
- + Auth or access-control bypass in the engine or the managed platform
- + Tenant-to-tenant crossover on the managed cloud (network, identity, or process boundary)
- + Data exfiltration or corruption via a crafted query or row write
- + LLM prompt-injection that escapes the plan compiler and reaches storage
- + Cryptographic or integrity flaws in the durability, recovery, full-text, vector, or backup subsystems
- + Bypass of per-tenant rate-limit / quota or per-API-key bucket accounting
- + Concurrency hazards that violate single-row CAS or schema-cutover atomicity
- − Denial-of-service from obviously abusive query volume within your configuration's quota
- − Issues requiring a compromised host or physical access to disk
- − Vulnerabilities in third-party dependencies already tracked by their maintainers
- − Social engineering of OriginChainDB staff or support
- − The marketing site (originchaindb.com) - it is a static deployment
Want the technical depth?
The architecture page covers the substrate, key shapes, replication topology, and recovery in detail. For audit timelines, BAA / DPA questions, or a security questionnaire, write security directly.