Deploy - what the managed configuration gives you.
OriginChainDB is a managed SaaS - you do not run the engine, we do. Below: what a tenant instance is made of, how to pick a region and configuration, which add-ons unlock what, provisioning, DNS and TLS, bearer rotation, replication topology, and migrating existing data.
Tenant architecture
Free and Starter databases run on shared, scale-to-zero infrastructure; this page covers dedicated configurations. Each dedicated configuration is a managed instance for one tenant - primary plus an optional warm standby in the same region - fronted by a per-tenant managed wildcard cert and a single hashed bearer token. No shared disk, no shared memory. Account & billing (signup, console) is global; your data stays in the region you pick.
Sharding, replicas, and high availability are engine-level concerns, not infrastructure tricks. A dedicated configuration runs one managed engine per tenant - nothing extra to schedule.
Choosing a region + configuration
| configuration | use | RAM | topology |
|---|---|---|---|
| Single-zone | First production workload, prototypes, dev environments | 8 GB | No SLA. Single instance. Card required at signup; billed from day 1. |
| HA | Production SaaS with SLA | 16 GB | Warm standby for fault tolerance, 99.9% SLA. |
| HA+ | High-concurrency customer-facing SaaS | 32 GB | Primary + 2 replicas for fault tolerance, 99.95% SLA. |
| Enterprise | Custom - HIPAA BAA, GDPR DPA, dedicated capacity | by spec | Per-contract terms, 99.99% SLA target. |
Pricing multiplier: the home region is the base price; every other region adds 1.15× on compute and storage to cover cross-region operational overhead.
Selecting add-ons
Base configurations ship with the core engine, single-row CAS, boolean FTS, and continuous-archive PITR. Everything else is an opt-in monthly add-on you can add or remove any time. See /pricing for line-item costs.
Add-ons attach to any configuration and bill on the next invoice. Toggle on or off from the console at any time; line items prorate to the day.
Provisioning
Click-to-running takes ~30 seconds. There are no manual steps; the console drives the whole flow.
DNS & TLS
Each tenant gets a DNS record auto-provisioned at
<tenant>.db.originchain.ai
pointing at your instance. The managed wildcard cert under
*.db.originchain.ai
auto-renews; you never see the private key.
When a standby is promoted, the same DNS record is re-pointed at the promoted instance with a 60-second TTL - propagation is typically sub-minute.
Bearer rotation
Rotate from the console at any time. The new token activates immediately and the prior token stays honored for 60 seconds so a rolling deploy can swap without a 401-storm. Every rotation lands an entry in the per-tenant audit log with actor, timestamp, and source IP.
Replication topology
High-availability configurations run a primary plus a standby in the same region, each on its own virtual machine; a single-zone configuration has no standby. A write is
acknowledged once it is flushed to durable storage on the primary - a
2xx means the data is on disk, not buffered in memory, and it
survives the database process being killed. Recovering it afterwards has two
caveats worth reading before you design around this, covering abrupt power
loss and a full storage volume - see
ops → write durability.
Replication to the standby is asynchronous: the primary streams committed
frames continuously but does not block on the standby. An abrupt loss of the
primary can therefore cost the most recent acknowledged writes - the recovery
point is not zero, and how much is at risk depends on how far behind the
standby had fallen. Promotion of the standby is not unattended by default:
an opt-in automatic-promotion path exists, and with it enabled the standby
claims the primary role itself once the old primary's claim has expired,
with an external restart hook bringing it back up as the writer. It refuses
to promote a standby that is not fully caught up. With the option off,
promotion is operator-driven. Either way the old primary's claim has to
expire first, so it is not a failover to hold a time budget against (see
ops → failover). Split-brain is fenced by a single-primary claim, so only one instance ever accepts writes.
Instances configured for synchronous acknowledgement go one step further on the
row-write endpoints: the primary waits up to 500 ms for the standby before it
replies. If the standby does not answer in that window the write still succeeds
and the response carries X-OC-Replication: degraded.
Treat that header, not the status code, as the signal that recent writes are at
risk. The other write surfaces - SQL, Cypher, transaction commit, vector and
full-text index writes - do not wait for the standby at all.
Cross-region active-active replication is in development and is not yet available for provisioning - see active-active. Quorum commit is roadmap and not scheduled: no engine in service commits a write through consensus, every database runs the active-passive path, and a running database cannot today be switched into a multi-node consensus group. Today every byte stays in the single region you picked.
Migration from existing data
Importing from Postgres? See Postgres ingest. For CSV / JSON / NDJSON dumps, see the bulk-load section in Insert → bulk. Connectors for DynamoDB and MongoDB are on the roadmap; in the meantime you can stream your dump through the standard bulk insert.