Intro to NFT Metadata
A listing of the table/data limits and smart contract deployment locations on supported chains.
Since Tableland is still in open beta, each table is limited to the following constraints while the full production network is further clarified:
These are temporary limits.
Each cell limit is 1kb.
Tableland is not a file storage solution. Instead, use pointers to solutions like IPFS, Filecoin, & Arweave to enable large file integrations and store the pointers in table cells.
Smart Contracts & Chains
Query size is limited to a maximum of 35kb.
However, note that on Ethereum, due to the block gas limit (30 million gas), the gas limit is reached when a query is around 14.5kb. In other words, query size is limited to 14.5kb when writing to Ethereum mainnet only; other chains should assume a maximum of 35kb.
Tableland inherits EVM-based constraints, including computational gas exceeding the gas limit. As such, all queries passed in smart contract calls at the Tableland Registry smart contract cannot exceed 35kb. Additionally, note there are not limits when it comes to the number of transactions in a single block; multi-transaction events are fully supported (e.g., mint more than one table and/or immediately insert into it in a constructor).
When a table is created or written to, there will be a “lag” between calling the smart contract and the time at which the event’s SQL instructions are materialized in Tableland. This “lag” is documented below as a chain-driven limitation of block times:
Average Block Finalization Time
For more information, see
Table reads directly access the Tableland network, which is distributed infrastructure that is separate from the chain itself (but still uses the execution and consensus mechanisms of the chain). All SQL instructions (create & write transactions) are stored on-chain in cheap event logs, but this makes the data inaccessible to smart contracts. Namely, smart contracts cannot read the logs, and the Registry smart contract methods are designed to emit events for SQL materialization.
As such, all reads must happen through an offchain interaction, such as REST API calls to the Tableland gateway or validator JSON RPC calls.