Multi-node configurations
A multi-node configuration distributes work across more than one engine process. Its behavior depends on the deployed topology and supported APIs. Start with measured workload requirements, not an assumed throughput multiplier.
- Measure the workloadIdentify the capacity or resilience problem to solve.
- Check data placementConfirm how tables and requests are distributed.
- Test representative operationsInclude the exact joins, writes and failure cases you need.
- Compare correctness and recoveryValidate results and behavior before relying on the configuration.
What multi-node gives you.
More nodes can provide additional capacity, but they also introduce routing, replication and recovery work. Confirm which operations your configuration supports. This guide does not promise a fixed speed increase, multiplied request quota or atomic cross-node transaction.
One endpoint, no client changes.
Use the connection address returned by Connect for the selected configuration. Keep it unchanged, including path segments. A single address does not imply identical support for every query method. Test the exact SQL, search and graph operations your application will send.
Current limits - refused honestly, never answered wrong.
Check the instance capabilities and test representative requests. Cross-node SQL, access policies, Ask and transactions can have different restrictions from a single-node deployment.
If an operation returns an unsupported-feature error, use a supported query or configuration. Repeating the request will not enable the feature. See transaction limits and error handling.
How data is distributed.
Confirm how tables and records are assigned to nodes in the proposed configuration. Table placement affects joins, cross-table transactions and recovery. Do not assume that adding nodes automatically spreads one busy table or makes a cross-node operation local.
Choosing a node count.
- Measure query time, write volume and peak concurrency on representative data.
- Check indexes and batch small operations before adding resources.
- Test the proposed configuration with the same workload.
- Compare results, errors and recovery behavior as well as throughput.
See request limits for controlling concurrency.
Growing later.
Ask the team which resizing and migration steps are supported for your deployment. Confirm whether a change needs a maintenance window, data movement or a client reconnect. Keep a recovery plan and verify the workload after the change.