Summary
Dedicated Sui gRPC nodes give your team an isolated full-node environment for high-throughput Sui data access. Instead of sharing rate-limited public or multi-tenant endpoints, you operate a node sized for your indexers, backend services, and subscription consumers. The gRPC API uses Protocol Buffers over HTTP/2, which makes checkpoint, transaction, and event streams more efficient than polling JSON-RPC. Dedicated capacity helps when you need stable throughput for backfills, multiple concurrent stream consumers, or transaction submission and simulation without noisy neighbours. You still own the operational surface: sync lag, disk growth, upgrades, and monitoring. The Sui gRPC surface includes LedgerService, StateService, TransactionExecutionService, and SubscriptionService. Streaming workflows such as SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents are central to low-latency indexing; ExecuteTransaction and SimulateTransaction support write and simulation paths. A dedicated node is not a managed magic box. Plan for state growth, snapshot recovery, TLS, load testing, and failover before production. This guide covers capacity planning, isolation, replay, monitoring, and full-node lifecycle decisions without vendor rankings or invented performance claims.
Key Takeaways
- Dedicated gRPC capacity suits backends that need consistent checkpoint, transaction, and event streaming throughput.
- Streaming consumers must handle reconnects, backpressure, and checkpoint replay; subscriptions are not fire-and-forget.
- You own the node lifecycle: storage, upgrades, pruning, monitoring, and failover.
- Evaluate isolation, retention, TLS/auth, and operational tooling before choosing a dedicated Sui gRPC plan.
What dedicated Sui gRPC nodes are for
Dedicated Sui gRPC nodes are single-tenant Sui full nodes that expose the Sui gRPC API instead of, or alongside, the legacy JSON-RPC surface. They are designed for backend services that need predictable capacity for checkpoint ingestion, transaction streaming, event processing, and transaction execution workloads.
A dedicated node gives you an isolated state sync and storage footprint, so your indexer or application does not compete with other tenants for CPU, memory, disk I/O, or network headroom. This matters most for high-frequency consumers, parallel backfills, and teams that need stable latency without public endpoint timeouts.
- High-throughput indexers that ingest every checkpoint and transaction
- Event pipelines that subscribe to Sui events and fan out to downstream systems
- Trading bots, wallets, and backends that simulate and execute many transactions
- Analytics and data services that need full state queries and streaming in one place
Sui gRPC service surface and streaming primitives
Sui full nodes expose gRPC services that map to the core node functions. The exact package names and message shapes depend on the Sui proto version you generate against, but the service roles are stable enough to plan around.
Generated clients may wrap these methods with language-specific names or higher-level subscription builders. Verify the workflow against the proto files provided by your node operator. Do not assume method signatures from REST or WebSocket JSON-RPC examples.
- LedgerService: read checkpoints, transactions, and object data for backfills and verification
- StateService: query object state and balances for account/state lookups
- TransactionExecutionService: use ExecuteTransaction for submission and SimulateTransaction for dry-run validation before broadcast
- SubscriptionService: use SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents for real-time server-streaming consumers
| Criterion | What to check | Why it matters |
|---|---|---|
| Ingest finalized checkpoints | SubscriptionService with SubscribeCheckpoints | Server-streaming; persist checkpoint sequence and resume from last processed. |
| Monitor transaction commits | SubscribeTransactions | Volume can be high; plan for client-side filtering if server-side filtering is not supported. |
| Track event logs | SubscribeEvents | Use filters carefully; backpressure and idempotent sinks are required. |
| Submit or simulate execution | TransactionExecutionService.ExecuteTransaction or SimulateTransaction | Simulate first to catch errors; submit with explicit gas and nonce control. |
Capacity planning and isolation
Dedicated capacity is not a single number. Model it from your actual workload: number of concurrent streams, average and peak checkpoint size, transaction per second per consumer, and backfill concurrency. A node that is fine for one polling backend may be overwhelmed by five parallel checkpoint streams.
- Measure sustained stream throughput over hours, not just a short burst
- Plan for peak checkpoint and event volume, not average
- Account for disk write amplification and snapshot/compaction operations
- Separate read-heavy analytics from write-heavy execution if possible
| Criterion | What to check | Why it matters |
|---|---|---|
| Subscription concurrency | Max simultaneous SubscribeCheckpoints/Transactions/Events consumers | Each stream holds buffers and connection state; too many can degrade sync or increase latency. |
| Backfill rate | How fast you can replay historical checkpoints | Backfills compete with live streams for I/O and CPU. |
| Transaction execution | Concurrent SimulateTransaction and ExecuteTransaction calls | Execution and simulation spike CPU and memory; noisy neighbours can cause timeouts. |
| Storage growth | Checkpoint and object DB growth plus pruning intervals | Disk full is a common outage cause; retention and pruning are operational decisions. |
Streaming consumers: backpressure, replay, and recovery
gRPC server-streaming methods such as SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents deliver a sequence of responses over one logical stream. The client must apply backpressure, or it will accumulate an unbounded queue and stall processing.
Replay considerations differ from live streaming. A dedicated node may allow faster backfills, but you should still rate-limit replay jobs so they do not starve live consumers. Schedule large backfills during low-traffic windows and monitor sync lag during the replay.
- Enforce maximum queue depth on the client; block or shed load when the downstream sink falls behind
- Persist a durable cursor for each stream, such as the last checkpoint sequence number or event ID, and resume from that cursor after reconnect
- Treat delivery as at-least-once; make writes idempotent and deduplicate on a stable key
- On disconnect, reconnect with backoff and resume from the persisted cursor, never from the current chain tip
- Use a separate thread or async task for stream reads and downstream writes to avoid deadlocks
Full-node lifecycle and operational ownership
A dedicated Sui gRPC node is still a Sui full node. Whether you self-manage it or buy a managed plan, someone must handle state sync, upgrades, storage, pruning, and recovery. Clarify who owns each task before you rely on the endpoint for production.
- Track Sui node release notes; upgrades may include fullnode.yaml changes, migration steps, or gRPC API changes
- Plan for state growth and configure pruning if you cannot retain full checkpoint history indefinitely
- Use snapshot restore to accelerate catch-up after a fresh start or major fallback
- Lock down the metrics port and admin interface; expose gRPC through TLS termination and token auth
- Keep mainnet and testnet configs separate; testnet faucet is https://faucet.sui.io but verify current policy and limits
- Refer to the Sui network page at /networks/sui and the testnet guide at /rpc-assistant/sui-testnet-rpc for OnFinality network details
Authentication, TLS, and connection testing
Production gRPC endpoints should require TLS and a bearer token or equivalent credential. Never put raw gRPC without auth on a public interface. Use grpcurl against your dedicated endpoint to inspect available services before writing code.
Use grpcurl list and describe to inspect the available services, including LedgerService, StateService, TransactionExecutionService, and SubscriptionService. The full gRPC service name may include a package prefix; use the path from your generated client.
Monitoring and failover
You cannot operate a dedicated gRPC node without observability. At minimum, monitor checkpoint sync lag, disk usage, memory pressure, stream connection churn, and gRPC error rates. Set alerts that wake a human before consumers time out.
- Export Prometheus metrics from the Sui node and scrape from your monitoring stack
- Alert on sync stall, disk above threshold, high connection churn, or repeated UNAVAILABLE / DEADLINE_EXCEEDED errors
- Design failover by configuring a secondary endpoint or region; keep stream cursors in external storage so failover is seamless
- Test failover outside production; do not hardcode one endpoint in client configs
- If you use OnFinality managed gRPC, confirm monitoring, failover, and notification options; see /rpc-assistant/sui-rpc-providers and /networks/sui
Decision framework for dedicated Sui gRPC nodes
Use the checks below to evaluate a dedicated node without relying on vendor rankings or unverified performance claims. The right choice depends on your workload's streaming profile, operational maturity, and data retention needs.
Do not accept latency, uptime, or RPS claims without testing against your own workload. Provision a trial or canary stream, measure sustained throughput, simulate a network partition, and validate failover before committing.
Next steps: Sui gRPC Guide.
| Criterion | What to check | Why it matters |
|---|---|---|
| Capacity isolation | Does the plan provide single-tenant CPU, memory, disk, and network for your subscription load? | Shared endpoints may throttle long-lived streams or bursty backfills. |
| Streaming surface | Are SubscribeCheckpoints, SubscribeTransactions, and SubscribeEvents available? Are there per-stream limits? | Your real-time indexer depends on continuous, resumable streams. |
| Operational access | Can you view logs, metrics, snapshots, and upgrade schedules? | Without access you cannot diagnose sync stalls or plan maintenance. |
| Data retention | How long are checkpoint and state history retained? Is pruning configurable? | Replay and audit requirements differ from live streaming needs. |
| Security | TLS requirement, token rotation, IP allowlisting, and audit logs | A dedicated node with weak auth becomes a public attack surface. |
| Testnet parity | Separate testnet endpoint with realistic streaming configuration | Testnet should mirror production behavior, not a reduced shared endpoint. |
| Migration path | Can you start with JSON-RPC and migrate to gRPC without rework? | gRPC should be the primary surface; legacy JSON-RPC may be limited. |
| Recovery | Snapshot restore, backfill speed, and stream resume semantics | Fast recovery reduces downtime after upgrades or failover. |
Frequently Asked Questions
What makes a dedicated Sui gRPC node different from public or shared Sui RPC?
A dedicated node gives isolated resources and stable streaming capacity for your backend; public/shared endpoints are rate-limited and may impose subscription timeouts. You still manage node lifecycle unless fully managed.
Which gRPC services should I expect on a dedicated Sui node?
LedgerService, StateService, TransactionExecutionService, and SubscriptionService. Confirm generated client stubs and request/response types from the provider's proto files.
How do I handle reconnects and replay for SubscribeCheckpoints?
Persist last processed checkpoint sequence or cursor, resume from that point on reconnect, make downstream writes idempotent, and enforce client-side backpressure.
Can I use a dedicated Sui gRPC node for testnet development?
Yes, but keep testnet separate from mainnet. Use official faucet at https://faucet.sui.io and verify current policy/limits. Testnet data may be reset; do not treat as production.
Do I still need to operate a Sui full node if I buy a dedicated gRPC plan?
A managed dedicated node still has a full node underneath; you may or may not own upgrades, snapshots, and monitoring depending on plan. Clarify operational responsibility and access.
What metrics should I monitor for a dedicated gRPC node?
Checkpoint sync lag, disk usage, CPU/memory, stream connection churn, error rates, and backfill throughput. Alert on stalls and capacity thresholds.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
