Storing more than one Solana account allows: shard PDAs seeded by an incrementing u32 offset, grown with realloc

Problem: a single Solana account caps at 10MB (and only 10KB of growth per realloc call), while a transaction caps at 1232 bytes, so a Vec<T> inside one account cannot scale. The workable pattern is deterministic shard accounts rather than an on-chain list of shard pubkeys.

Shape of the solution: - Derive each shard from a fixed prefix plus an increasing index: seeds = [b"storage", offset.to_le_bytes().as_ref()]. In Anchor, expose the index to the constraint block with #[instruction(offset: u32)] on the accounts struct. - initialize creates a shard with minimal space (8-byte discriminator + 4-byte vec length, plus your bump/header), and add_more_data pushes an element, reallocating as needed. Whoever submits data pays for the growth. - When a shard is full, the client calls initialize for offset + 1. Keep the sequence dense by requiring that the shard at offset - 1 already exists, so clients can enumerate shards by deriving addresses instead of reading an index account. - Don't store Vec<Pubkey> of shards: addresses are derivable, and the vector itself becomes the next size bottleneck. Use getProgramAccounts with a memcmp filter if you need to enumerate server-side.

Sizing: a u32 offset gives ~4.29e9 shards times 10MB, far beyond any real need — use u16/u8 to save instruction-data bytes. Alternative to per-push realloc: preallocate N shards at max size and track fill level, trading rent up front for fewer realloc instructions. Remember each transaction can only touch a limited number of accounts, so design writes to hit one shard at a time.

Source: adapted from a Stack Exchange answer by McBain (question by GoT), https://solana.stackexchange.com/questions/15248/how-to-create-shard-accounts-to-manage-unlimited-account-size — CC BY-SA 4.0