Capacity, concurrency and the 3× cap
How execution capacity is defined, what the 3× monthly cap actually bounds, and how to size a plan from change volume instead of guessing at rows.
Docs · Reference · Updated 2026-11-03 · Applies to current Bridge releases
Definition
Execution capacity is the hardware envelope a plan grants: the number of execution nodes, the total vCPU across them, and the number of environments. It is the billing dimension. Rows, gigabytes, connectors and tasks are not.
Plan capacity compared
| Standard | Business | Enterprise | |
|---|---|---|---|
| Price (annual billing) | $499 / month | $1,199 / month | Quoted |
| Execution nodes | 1 | Up to 2 | Custom |
| vCPU total | Up to 4 | 16 | Custom |
| Production environments | 1 | 1 | Custom |
| Non-production environments | — | 1 | Custom |
| DDL sync | — | Included | Included |
| Audit and team permissions | Basic | Detailed | Detailed plus DPA support |
| Support | Weekday email and ticket | Priority with agreed response times | Dedicated SLA and TAM |
What the 3× cap bounds
The engine enforces a hard ceiling of three times the monthly plan price. The cap is a spend guardrail, not an overage meter: it notifies you as you approach it and does not silently bill beyond it.
| Month | Plan price | Ceiling enforced | Typical outcome |
|---|---|---|---|
| Month 1 (ramp) | $1,199 | $3,597 | Within plan; no action |
| Month 2 (spike) | $1,199 | $3,597 | Guardrail notifies before ceiling |
| Month 3 (sustained) | $1,199 | $3,597 | Move tier or add capacity deliberately |
Compare that with a per-row model, where the ceiling is whatever the change volume produces. The difference is not the average invoice; it is that one model has a known maximum and the other does not.
Sizing from change volume
Estimate the sustained change rate rather than total stored data, because capture cost tracks changes:
- Count rows changed per day (inserts + updates + deletes) for the busiest source.
- Divide by 86,400 for an average rows/second figure, then multiply by 3 to allow for peaks.
- Compare with the observed throughput envelope: a single 8-core / 32 GB node sustains 120 MB/s in bulk load and has captured 280k rows/s in a production deployment.
- If the estimate exceeds one node with headroom, start with Business — two nodes and 16 vCPU — rather than discovering the limit in production.
Concurrency and scaling
| Behaviour | How it works | What to watch |
|---|---|---|
| Parallel pipelines | Pipelines share the node's vCPU budget | CPU saturation shows up as rising lag before errors |
| Per-pipeline threads | Configurable read and write parallelism | More threads can reorder keys unless ordering is preserved |
| Cluster mode | Multiple instances, no single point of failure | Cross-node work distribution needs a shared catalogue |
| Checkpoint and resume | Offsets committed per pipeline | Restart resumes rather than re-snapshotting |
| Atomic rollback | Failed batches rolled back as a unit | Target never holds a half-applied batch |
Capacity questions
Is there a hard row limit per month?
No. Rows are not metered. Limits are node count, vCPU and environments, plus the 3× spend ceiling.
What happens at the cap?
The engine notifies you as you approach it and does not bill past it. Sustained growth means moving tier or adding capacity, not an automatic overage charge.
Can I burst above my vCPU budget?
Capacity is provisioned, not elastic across plans. Burst behaviour within a node is bounded by the hardware; if peaks are routine, size up deliberately.
How do I know when to move from Standard to Business?
When peak change rate approaches the single-node envelope, or when you need a second environment or DDL sync. Both are plan features, not add-ons.