user1638: Once the ledger size grows beyond the terabyte magnitude, how will Cardano address this issue?
Storing and querying anything that large seems impractical to me.

user1147: Querying large data sizes doesn't have to be an issue necessarily, because you can create multiple indices for data access, which speeds up the search process by a large factor.For example think about Google that queries essentially the complete web.
It is expected that the transaction volume grows linearly over time while storage capacity grows exponentially. So the storage problem will likely solve itself over large time frames.
Also see this question:
Are there plans to keep the blockchain/node size small enough to maintain decentralisation?

user1714: In the near term, the solution is to keep metadata off chain as much as possible. Proofs/Hashes of the metadata can be used to maintain a reference to the data and guarantee it hasn't changed.
This of course relies on the assumption that said metadata will be available as long as it is needed.
If you look on the IOG GitHub, they have a "testnet" repo for the metadata registry and documentation scattered about in the other repos about this. When the metadata registry format is finalised, documentation should be clearly available. Since these registries are just git repositories, it is trivial to spin one up or mirror one. Additionally, since git is already a decentralised protocol, it will fit in quite well with the existing ecosystem.
With this format it seems the goal will be to have multiple community registries and these community registries will likely have multiple independent mirrors (due to the nature of git). This federated system will allow the community to discard unused data as necessary (and said data can be kept by anyone who needs it).

Other responses have already addressed parts of the long term goal however I would recommend looking through the IOG research catalogue. I believe there are a few papers in there addressing the topic.
Additionally, like other comments have mentioned, side-chains and state channels will allow history to be compressed as much as possible.

user28: The answer to this question is not clear yet, as more research is needed into this problem.
For now, the effort is to prevent the blockchain growing into large sizes with using layer one two solutions such as Hydra and possibly with side-chains, where you won't have just one blockchain but many, so the data might be distributed this way.
Shredding will be used too to provide a light-weight view of the blockchain, but many services such as Blockfrost will still have to run full archived nodes to access all the data on the blockchain.

1638: <p>Once the ledger size grows beyond the terabyte magnitude, how will Cardano address this issue?
Storing and querying anything that large seems impractical to me.</p>
 1147: <p>Querying large data sizes doesn't have to be an issue necessarily, because you can create multiple indices for data access, which speeds up the search process by a large factor.<br>For example think about Google that queries essentially the complete web.</p>
<p>It is expected that the transaction volume grows linearly over time while storage capacity grows exponentially. So the storage problem will likely solve itself over large time frames.<br>
Also see this question:
<a href="https://cardano.stackexchange.com/questions/584/are-there-plans-to-keep-the-blockchain-node-size-small-enough-to-maintain-decent">Are there plans to keep the blockchain/node size small enough to maintain decentralisation?</a></p>
 1714: <p>In the near term, the solution is to keep metadata off chain as much as possible. Proofs/Hashes of the metadata can be used to maintain a reference to the data and guarantee it hasn't changed.</p>
<p>This of course relies on the assumption that said metadata will be available as long as it is needed.</p>
<p>If you look on the IOG GitHub, they have a <a href="https://github.com/input-output-hk/metadata-registry-testnet" rel="nofollow noreferrer">&quot;testnet&quot; repo for the metadata registry</a> and documentation scattered about in the other repos about this. When the metadata registry format is finalised, documentation should be clearly available. Since these registries are just git repositories, it is trivial to spin one up or mirror one. Additionally, since git is already a decentralised protocol, it will fit in quite well with the existing ecosystem.</p>
<p>With this format it seems the goal will be to have multiple community registries and these community registries will likely have multiple independent mirrors (due to the nature of git). This federated system will allow the community to discard unused data as necessary (and said data can be kept by anyone who needs it).</p>
<hr />
<p>Other responses have already addressed parts of the long term goal however I would recommend looking through the <a href="https://iohk.io/en/research/library/" rel="nofollow noreferrer">IOG research catalogue</a>. I believe there are a few papers in there addressing the topic.</p>
<p>Additionally, like other comments have mentioned, side-chains and state channels will allow history to be compressed as much as possible.</p>
 28: <p>The answer to this question is not clear yet, as more research is needed into this problem.</p>
<p>For now, the effort is to prevent the blockchain growing into large sizes with using layer <strike>one</strike> two solutions such as Hydra and possibly with side-chains, where you won't have just one blockchain but many, so the data might be distributed this way.</p>
<p>Shredding will be used too to provide a light-weight view of the blockchain, but many services such as Blockfrost will still have to run full archived nodes to access all the data on the blockchain.</p>
