Sui Data Service

ZAN Sui Data Service is a unified data access solution for the Sui ecosystem.

ZAN Sui Data Service Documentation

If you already know which access method you need, continue with the dedicated documentation:


What Is Sui Data Service

Sui Data Service is ZAN’s production-ready data access offering for the Sui ecosystem.

Rather than treating GraphQL, gRPC, and Archival as separate tools, it is better to think of Sui Data Service as one integrated product that supports three common data access needs:

  • GraphQL API for structured queries, aggregation, pagination, and frontend-friendly access
  • gRPC service for low-latency access, streaming, subscriptions, and backend integration
  • Archival capability for long-term historical data retrieval

Together, these capabilities support product queries, real-time system workloads, and historical lookups through the same service layer.


Why Sui Data Service

Teams building on Sui usually face three kinds of data requirements at the same time:

  1. Product-facing queries such as wallet views, asset pages, and transaction details
  2. Real-time backend workloads such as subscriptions, pipelines, monitoring, and sync services
  3. Historical lookups for audits, backfill, compliance, and long-range analysis

Sui Data Service is designed to cover all three within one product.

Core Value

  • One product for multiple data access patterns
  • Lower infrastructure and maintenance cost
  • Easier migration away from JSON-RPC
  • Production-ready global coverage
  • Historical access from genesis onward

How the Product Fits Together

Sui Data Service is a unified access layer in which each capability solves a different part of the same problem.

CapabilityBest Used ForTypical Scenarios
GraphQL APIStructured and flexible query accessWallets, dashboards, asset pages, transaction details, admin tools
gRPC serviceLow-latency and real-time accessSubscriptions, pipelines, monitoring, indexers, backend systems
Archival capabilityLong-range historical lookupOld transactions, historical object versions, checkpoints, epochs, audit analysis

This means developers do not need to choose one separate product over another. Instead, they can use the same service family in different ways depending on the workload.

For example:

  • A wallet app may use GraphQL for user-facing pages
  • A backend worker may use gRPC for checkpoint consumption
  • An audit or analytics workflow may use Archival for historical records

When To Use Each Capability

Use GraphQL When

Choose GraphQL when you need flexible field selection and frontend-friendly query patterns.

Typical use cases include:

  • Wallet home pages and portfolio views
  • Transaction detail pages
  • Activity feeds
  • Cursor-based list queries
  • Dashboard and admin queries

Use gRPC When

Choose gRPC when you need lower latency, stronger typing, streaming, or backend-oriented integration.

Typical use cases include:

  • Real-time subscriptions
  • Incremental sync services
  • Checkpoint consumers
  • Monitoring and alerting systems
  • Backend transaction or object retrieval workflows

Use Archival When

Choose Archival when you need historical data that regular full nodes may already have pruned.

Typical use cases include:

  • Old transaction lookup
  • Historical object version lookup
  • Early checkpoint or epoch lookup
  • Audit, compliance, and retrospective analysis
  • Historical backfill and repair

Common Production Model

In practice, many teams use all three together:

  • GraphQL for product queries
  • gRPC for real-time and backend workloads
  • Archival for long-term historical access

This is why Sui Data Service should be understood as a single product with complementary capabilities, rather than three disconnected features.


Product Advantages

GraphQL API

GraphQL is the most efficient choice for user-facing and operational query experiences.

Key benefits:

  • Fetch only the fields you need
  • Reduce redundant requests
  • Support flexible aggregation and pagination
  • Fit frontend and dashboard scenarios well
  • Simplify migration from fragmented JSON-RPC query patterns

gRPC Service

gRPC is the best fit for real-time and infrastructure-heavy workloads.

Key benefits:

  • Lower latency for backend access
  • Native streaming support
  • Strongly typed APIs through Protobuf
  • Higher efficiency than polling in high-frequency scenarios
  • Strong fit for pipelines, monitoring, and indexers

Archival Capability

Archival completes the product by providing reliable access to historical data.

Key benefits:

  • Support long-range historical lookup from genesis onward
  • Keep old data accessible after full node pruning
  • Support audit, traceability, and backfill scenarios
  • Integrate into the same ZAN service experience instead of requiring a separate infrastructure stack

Supported Networks

NetworkStatusDescription
Sui Mainnet (sui-mainnet)✅ SupportedProduction environment with full chain and historical access
Sui Testnet (sui-testnet)✅ SupportedTesting environment for development and integration

Global Coverage

ZAN Sui Data Service is globally deployed across APAC, the Americas, and Europe.

ServiceCoverage
GraphQL RPC + IndexerGlobal (APAC, Americas, Europe)
gRPC EndpointGlobal (APAC, Americas, Europe)
Archival Store (Bigtable)Global (APAC, Americas, Europe)
Node Service (JSON-RPC)Global (APAC, Americas, Europe)

Infrastructure Highlights

  • Multi-region deployment with smart routing
  • Multi-AZ architecture with failover support
  • 99.9% uptime SLA
  • Low latency in major global regions
  • Lower operational cost than many comparable alternatives

Quick Start

Prerequisites

  1. Register for a ZAN account and sign in to the ZAN Console
  2. Create a project and obtain an API key
  3. Decide which capability your workload needs first: GraphQL, gRPC, or historical access

GraphQL Access

ParameterValue
Mainnet endpointhttps://api.zan.top/node/v1/sui/mainnet/{apiKey}/graphql
Testnet endpointhttps://api.zan.top/node/v1/sui/testnet/{apiKey}/graphql
AuthenticationAPI key embedded in the URL
ProtocolHTTPS

gRPC Access

ParameterValue
gRPC endpointgrpc.zan.top:443
AuthenticationMetadata x-token: {api_key}
Network selectorMetadata x-network: sui-mainnet / sui-testnet
Archival query selectorMetadata x-data-type: archive (optional, when needed)
ProtocolgRPC over HTTP/2 (TLS)

Recommended Starting Point

  • If your primary need is frontend and product queries, start with GraphQL
  • If your primary need is real-time backend consumption, start with gRPC
  • If your primary need is older historical data, use Archival through the same service stack

Historical Data Access: Archival

Archival is the historical data layer within Sui Data Service. Its role is simple but essential: it keeps older on-chain data accessible even after regular full nodes have pruned it.

What Is Archival

To maintain performance, Sui full nodes periodically prune historical data and usually keep only a limited recent window of transaction and object records. Once that data is pruned, a regular node can no longer return it.

Archival Store is Sui’s long-term storage layer for historical blockchain data. Built on Google Cloud Bigtable, it preserves the complete chain history from Genesis Checkpoint 0 onward.

When historical data is no longer available from a regular full node, Archival Store becomes the reliable way to access it.

Why Use ZAN for Archival

ZAN is one of the four Sui Foundation-recognized full-stack data service providers and serves the APAC region. ZAN integrates Archival Store directly into its data access layer, especially through GraphQL.

This means developers do not need to build and maintain their own Bigtable storage, indexers, or gRPC infrastructure in order to work with historical data.

By using ZAN for Archival access, developers can benefit from:

  • Millisecond-level latency in APAC
  • Cost efficiency at roughly one-fifth of comparable alternatives
  • 99.9% SLA-backed availability
  • Query complexity monitoring and rate-limit protection

In short, the value of using ZAN is not just archival access itself, but archival access delivered through a production-ready service experience.


Pricing and Cost Model

GraphQL Pricing

ItemPrice
All GraphQL method calls60 credits / call
Data transfer0.1 credits / byte

gRPC Pricing

ItemPrice
All gRPC method calls50 credits / call

gRPC is charged uniformly per method call, while GraphQL cost is influenced by both request count and response size.

Cost Optimization Tips

  1. Request only the fields you need in GraphQL
  2. Use pagination to control response size
  3. Prefer gRPC streaming over high-frequency polling where possible
  4. Design long-range historical lookups in an archival-friendly way

Migration Guidance from JSON-RPC

A practical migration path is:

Phase 1: Replace Core Read Endpoints

  • Move object, transaction, and checkpoint reads to GraphQL or gRPC
  • Keep legacy paths temporarily if needed

Phase 2: Migrate Real-Time Logic

  • Replace polling-heavy workflows with gRPC subscriptions
  • Use checkpoints as recovery markers

Phase 3: Migrate Historical Access

  • Move historical reads to GraphQL fallback or gRPC archival patterns
  • Redesign long-range history reads into archival-friendly lookups when possible

Phase 4: Remove JSON-RPC Dependency

  • Gradually remove JSON-RPC logic after validation

FAQ

What Is the Relationship Between Sui Data Service and the Separate GraphQL / gRPC Documents?

Sui Data Service is the unified product-level overview. The GraphQL and gRPC documents provide more detailed setup guides and API references.

What Role Does Archival Play in Sui Data Service?

It is the historical data layer within the same product. It restores access to data that full nodes may have pruned.

Do I Have To Choose Only One Capability?

No. Many production systems use GraphQL for structured queries, gRPC for real-time workloads, and Archival for long-range history together.

Do Historical Queries Require a Separate Endpoint?

Usually not for GraphQL. For gRPC, you can explicitly request archival access with x-data-type: archive.

Is It Still Recommended To Build New Features on JSON-RPC?

No. New capabilities should preferably be built on GraphQL or gRPC.


Related Documentation