Sui has rolled out an integrated data stack built around a GraphQL RPC, a general-purpose indexer and a dedicated Archival Store, giving developers a more structured way to query both live and historical data across the network. The new architecture marks a significant shift in how applications, infrastructure providers and node operators are expected to access and serve chain data.
The timing is important because Sui has already set a deadline for a major infrastructure transition. With JSON-RPC on full nodes scheduled for deprecation in July 2026, the network is moving operational responsibility for historical access toward archival gRPC endpoints and indexed PostgreSQL-based services.
A New Data Architecture Built Around Sui’s Object Model
The stack is designed around Sui’s object-centric architecture rather than a generic account-based model. At its core, a modular, checkpoint-driven indexer pulls raw data from the remote checkpoint store and full nodes, transforms that data, and writes optimized records into a PostgreSQL-compatible database built for GraphQL query access.
That process is already supporting several specialized pipelines that turn raw chain activity into structured data products. Pipelines such as tx_affected_objects, tx_calls and ev_struct_inst make transaction and event data queryable, while the obj_versions pipeline preserves version-to-checkpoint mappings and remains unprunable in order to maintain full object history.
GraphQL is positioned as the main high-level interface for most developers who need recent and structured on-chain data. The GraphQL server routes requests across multiple backends, using the indexer’s Postgres store for recent and historical structured records, the Consistent Store for live ownership and balance data, and the Archival Store for deeper historical retrievals.
That does not mean retention is uniform across all public services. Some public GraphQL endpoints apply shorter retention windows, including limited lookback periods for owned-object queries and roughly 90-day access for certain address-affecting queries unless the service is backed by an unpruned indexer.
Historical Access Is Moving to the Archival Layer
The Archival Store is intended to solve the historical-data gap created when full nodes prune older checkpoints. It exposes the same LedgerService gRPC API available on full nodes and is meant to serve as the fallback source whenever a full node returns NOT_FOUND for pruned records.
That makes archival infrastructure especially relevant for production-grade services and compliance-sensitive workflows. Operators handling high-volume queries or long historical lookbacks are expected to rely on large-scale storage systems and dedicated archival deployments rather than public endpoints with rate limits and narrower service guarantees.
The shift reduces the need for many teams to build their own bespoke indexing infrastructure from scratch, but it also raises new operational demands. Storage planning, retention management, schema stability, access control and fallback logic now become central requirements for node operators and third-party RPC providers supporting Sui applications.
As of early 2026, those requirements are already substantial. The object-version pipeline alone was consuming roughly 8.2 TB on Mainnet, and the total footprint for unpruned indexers or archival services can expand into much larger multi-terabyte or even petabyte-scale territory depending on deployment choices.
The broader implication is clear ahead of the July 2026 transition. Teams that still depend on JSON-RPC from full nodes will need to migrate monitoring, auditing and reconciliation workflows toward GraphQL and archival gRPC, while also budgeting for the storage and operational costs that come with long-term historical access.