Partitioning Blockchain Tables by Network and Range
Choose table partitions around query and retention boundaries, while keeping stable event keys and avoiding assumptions that partitions enforce completeness.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
Partitioning divides a table physically or logically to improve management and selected queries. It does not establish that the underlying blockchain range is complete or canonical.
Start with actual predicates
Common access patterns include network plus block range, date window or asset identity. Choose partition keys that support those predicates and operational needs. Too many tiny partitions can add planning overhead; overly broad partitions can limit pruning. Keep event identity independent of the partition location so records remain addressable across maintenance changes.
Worked example: one network, one month
A report filters one network and a monthly time range. A matching partition layout may reduce scanned data, but only if the query predicates and engine support pruning. A query on block height alone may need a different access path. Measure the plan instead of assuming the table layout guarantees a faster result.
Test boundaries and revisions
Include records on adjacent partition boundaries, late delivery and changed accepted blocks. Define how corrections reach older partitions. Retention policies should not silently turn a previously complete historical endpoint into a partial one. Publish the available range separately from the storage layout.
A practical acceptance test
Place events on both sides of a partition boundary and issue the actual report predicates. Inspect which partitions are read and compare results with an unpartitioned reference query. Add a late correction to an older partition. The maintenance path must update the affected result without claiming that partition presence itself proves complete historical coverage.
Questions about the topic
Frequently asked questions
Does a populated partition prove full range coverage?
No. Storage presence and validated completeness are different.
Are more partitions always faster?
No. Excess partitioning can add overhead.
Standards & technical documentation
