Sui RPC Providers: How to Choose for Production

Quick recommendation: match provider type to workload

Before comparing vendors, decide which type of Sui RPC access fits your app. The right choice depends on traffic volume, latency sensitivity, and how much operational overhead you want.

• Public endpoints (e.g., https://fullnode.mainnet.sui.io:443) are fine for prototyping and low-traffic tools. They are rate-limited and not meant for production workloads.
• Shared RPC services (like OnFinality's public RPC) give you a managed endpoint with reasonable rate limits and no node maintenance. They suit most dApps, indexers, and wallets that don't need custom node configuration.
• Dedicated nodes provide a private endpoint with dedicated resources, ideal for high-throughput apps, NFT mints, or applications that need consistent performance under load.

If you're building a production app, start with a shared RPC service and plan a migration path to a dedicated node if your traffic grows. For time-sensitive use cases like trading bots or gaming, a dedicated node with low-latency routing is often worth the cost.

What makes Sui RPC different from other chains

Sui is a high-throughput Layer 1 with parallel execution and a Move-based object model. Its RPC interface is JSON-RPC 2.0, but it also supports gRPC for efficient streaming and subscription use cases. Unlike Ethereum-style chains, Sui uses checkpoints and epochs, and its transaction model is object-centric rather than account-based.

This affects how you interact with the chain:

• Object reads are common, so suix_getObject and suix_getDynamicField are frequently used.
• Transaction blocks are referenced by digest, not by hash.
• Subscriptions via WebSocket are supported, but gRPC is the preferred method for high-throughput event streaming.

When evaluating Sui RPC providers, check whether they support both JSON-RPC and gRPC. Some providers only offer JSON-RPC, which can limit your ability to stream data efficiently.

Key evaluation criteria for Sui RPC providers

Use the following table to compare providers systematically. These criteria go beyond basic uptime and pricing.

Criterion	What to check	Why it matters
gRPC support	Does the provider offer a gRPC endpoint?	gRPC is more efficient for streaming and high-volume data; not all providers support it.
Archive data	Can you query historical state and transactions?	Needed for indexers, analytics, and debugging.
WebSocket support	Is there a stable WebSocket endpoint for subscriptions?	Essential for real-time dApps and monitoring.
Rate limits	What are the request limits per second/minute?	Determines if the provider can handle your traffic spikes.
Failover options	Can you easily switch to a backup provider?	Redundancy is critical for production reliability.
Geographic distribution	Are endpoints available in multiple regions?	Reduces latency for global users.
SLA and support	Is there a formal SLA and 24/7 support?	Protects your app in case of issues.

gRPC vs JSON-RPC: which should you use?

Sui supports both protocols, but they serve different purposes.

• JSON-RPC is the standard for simple queries and mutations. It's easy to debug and works with any HTTP client.
• gRPC is better for streaming and high-throughput scenarios. It uses HTTP/2 and protobuf, which reduces overhead and supports bidirectional streaming.

If you're building a real-time indexer or a trading bot that needs to react to events quickly, gRPC is the better choice. However, not all providers offer gRPC, so confirm before committing.

Here's a simple example of a gRPC subscription in Go using the Sui SDK:

package main

import (
    "context"
    "fmt"
    "github.com/MystenLabs/sui-go-sdk/sui"
)

func main() {
    client := sui.NewSuiClient("https://rpc.sui.io")
    // Subscribe to new transactions
    sub, err := client.SubscribeTransaction(context.Background(), sui.TransactionFilter{})
    if err != nil {
        panic(err)
    }
    defer sub.Close()
    for {
        msg, err := sub.Recv()
        if err != nil {
            panic(err)
        }
        fmt.Println(msg)
    }
}

How to test a Sui RPC endpoint before committing

Before you integrate a provider, run a few basic checks to verify the endpoint works and meets your needs.

1. Check the chain ID and latest checkpoint to confirm the endpoint is synced.
2. Send a simple JSON-RPC request to measure latency.
3. Test a WebSocket subscription to ensure real-time data flows.
4. Query historical data to verify archive support if you need it.

Here's a curl example to get the latest checkpoint:

curl -X POST https://rpc.sui.io \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sui_getLatestCheckpointSequenceNumber",
    "params": []
  }'

If the response is slow or times out, that's a red flag. Also, check the provider's status page for any ongoing incidents.

Common pitfalls when using Sui RPC providers

Even with a good provider, you can run into issues. Here are common mistakes and how to avoid them.

• Using public endpoints in production: Public endpoints are rate-limited and can go down. Always use a managed provider for production.
• Ignoring rate limits: Even paid providers have limits. Monitor your usage and set up alerts before you hit the cap.
• Not planning for failover: If your provider has an outage, your app goes down. Use multiple providers or a load balancer.
• Assuming all providers support gRPC: Not all do. Verify before you build your streaming pipeline.
• Overlooking archive data: If you need historical data, make sure your provider offers archive nodes. Some only keep recent state.

How OnFinality fits into your Sui RPC strategy

OnFinality provides managed Sui RPC endpoints and dedicated node infrastructure. You can use OnFinality as your primary provider or as a failover option to add redundancy.

• Shared RPC: OnFinality offers a public RPC endpoint for Sui, suitable for development and moderate production traffic.
• Dedicated nodes: For high-throughput apps, you can spin up a dedicated Sui node with dedicated resources and custom configuration.
• Global network: OnFinality's infrastructure is distributed, which can help reduce latency for users around the world.

Check the Sui network page for the latest endpoint details and supported features. For pricing, see RPC pricing to understand the cost model.

Key Takeaways

• Sui RPC providers differ in gRPC support, archive data, and rate limits—evaluate based on your workload.
• Public endpoints are not for production; use a managed provider or dedicated node.
• Always test an endpoint before committing, and plan for failover with multiple providers.
• OnFinality offers both shared and dedicated Sui RPC options, suitable for a range of use cases.

Frequently Asked Questions

What is the best Sui RPC provider?

The best provider depends on your needs. For high-throughput apps, look for gRPC support and dedicated nodes. OnFinality offers both shared and dedicated options; compare features and pricing to find the right fit.

Does Sui support gRPC?

Yes, Sui supports gRPC, but not all providers have implemented it. If you need streaming, confirm gRPC availability with your provider.

Can I use public Sui endpoints for production?

No, public endpoints are rate-limited and not reliable for production. Use a managed provider or dedicated node.

How do I choose between shared and dedicated Sui RPC?

Shared RPC is cost-effective for moderate traffic. Dedicated nodes are better for high throughput, low latency, and custom needs. Start with shared and scale up as needed.

What should I do if my Sui RPC provider goes down?

Have a failover plan. Use multiple providers or a load balancer. OnFinality can serve as a backup provider to ensure uptime.

For more details on supported networks and endpoints, visit our supported RPC networks page.

Related resources

• Sui network page
• RPC pricing
• Supported RPC networks

Originally published at OnFinality.