Start from the workload
A dedicated node request becomes useful when it specifies what the application needs to read, stream and send. Hardware alone does not describe filters, history, response volume or recovery requirements. A clear workload brief also makes competing proposals easier to compare.
A copyable requirements outline
Network and cluster:
Users/receivers and preferred region:
RPC method mix, sustained RPS and peak burst:
Sending throughput and transaction lifecycle:
gRPC/account/program filters and commitment:
Expected stream traffic and concurrent connections:
History/replay/retention requirements:
Data export and monitoring needs:
Desired trial and acceptance window:Use observed counts where possible. Mark uncertain estimates as estimates, and separate today's workload from a future capacity target. Do not include private keys or access tokens.
Attach an acceptance plan
- Provide a representative sanitized read workload and filter set.
- Specify which old transactions or historical-state queries must work.
- Define stream completeness, recovery and client-side processing checks.
- Agree on support scope, maintenance responsibility and how a trial result will be recorded.
Evaluate the resulting proposal
Check what is actually isolated, which region is provisioned, what software and history are included, and how scaling or failure recovery is handled. Keep performance measurements separate from promised capacity. Supanode's dedicated product and Docs describe the access process; a quote depends on the submitted requirements. Request a quote for that configuration and agree any service commitments explicitly.