Storage size and density are both relevant concerns when it comes to the performance of your chain. There are limits and performance implications at many levels so I will break them down:
The Substrate runtime executes within a
wasm32 environment, which means we have the same general limitations as any 32-bit environment, for example the maximum theoretical number of items in a
u32::MAX or 232 or 4,294,967,296. In practice though it will much less because that assumes a vector of bytes and does not account for any other overheads.
Our wasm environment itself is configured with a maximum allocation size which is currently set to 32 MiB. That means trying to access any item in storage which requires more than 32 MiB allocated memory will cause a panic in the runtime.
Merkle Trie Limits
Substrate's generic key-value database can support arbitrary size keys and values.
Merkle Trie Complexity
Substrate uses a base-16 merkle trie as default, and thus we can expect the complexity of accessing item in the trie to grow at log16 of the number of items in the overall state.
Size / Decoding Performance
When reading a raw value from the database, we should expect that larger files are more complex for the database to handle than smaller files.
Additionally, to convert the raw encoded bytes into a Rust type-safe object, Parity SCALE Codec needs to decode those bytes, which increases in complexity based on the number of bytes encoded.
While I cannot speak towards optimization of RocksDB with various filesizes, Parity DB is optimized for certain kinds of key/values. Those optimizations are noted in the project.