Multi-node configurations
A multi-node configuration runs your instance across more than one node while presenting exactly one endpoint. You get more write throughput and bigger rate budgets; your application code, schemas, and queries stay the same. This page covers what multi-node gives you, how to choose a node count, and how a configuration grows.
What multi-node gives you.
Adding nodes adds write capacity. Measured: a 2-node configuration sustains ~2x the write throughput of a single node on the same workload.
Your application talks to a single URL with a single token, whatever the node count. No client-side routing, no per-node connection strings, no code changes when the configuration grows.
Data is distributed across nodes table by table, automatically. You never assign tables to nodes or manage placement - create tables the way you always have.
A transaction can span tables on different nodes and still commits atomically - all writes land or none do. Same BEGIN / COMMIT / ROLLBACK surface as a single node.
API-key budgets multiply by node count. A 3-node configuration delivers 3x the aggregate request, byte, and query budgets - through the same single endpoint.
Each node can optionally carry its own synchronized standby in a separate zone, selected through the resilience configurations - the same options you know from single-node.
Throughput and budget numbers here are measured, not projected: ~2x write throughput at 2 nodes on our standard workload. Larger node counts add capacity in the same direction; measure against your own workload before sizing for a hard target.
One endpoint, no client changes.
Every request - reads, writes, vector search, full-text, graph, natural language - goes to the same base URL you'd use on a single node. OriginChain routes it to the right node internally. Requests that need data from several nodes are handled for you, and transactions that touch tables on different nodes commit atomically.
The same is true of your API keys and rate budgets: one key, one endpoint, and the budgets you're entitled to across the whole configuration are delivered through that single endpoint. You don't spread traffic across nodes to collect your full budget - it's aggregate by contract.
How data is distributed.
Distribution is by table, and automatic. When you create tables, OriginChain places them across the nodes of your configuration; queries and writes are routed accordingly. There is no placement API to learn and no distribution key to design - the table remains the unit you think in.
Because distribution is table-by-table, workloads with several independently busy tables see the most immediate benefit: their write load spreads naturally across nodes.
Choosing a node count.
| Your situation | Start with |
|---|---|
| Most applications - a single node's throughput covers you, and you can grow later. | 1 node |
| Sustained write volume near a single node's ceiling, or rate budgets that keep hitting 429 despite batching. | 2 nodes |
| High-volume ingest across many busy tables, or aggregate budget requirements a smaller configuration can't meet. | 3+ nodes |
Two sizing notes. First, batch before you scale: batch endpoints are dramatically more efficient than single-row calls (see rate limits → batching) - many workloads that look like they need more nodes actually need batching. Second, node count is a write-throughput and budget decision; if your bottleneck is a single slow query, look at query tuning and indexes first.
Growing later.
Node count is not a one-way door decision. Nodes can be added to a running configuration online, with no downtime - the endpoint stays the same, and data redistributes behind it. The console exposes your configuration's node layout and is where growth happens.
Practical consequence: start with the smallest configuration that covers today's measured load, and grow when your own numbers say so.