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:

Table Limits

These are temporary limits.

Max Size

Data 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.

Since the Tableland network is currently in open beta (testnet), row limits have been imposed. When Tableland launches its production network (mainnet), there likely won’t be row limits. This is subject to change based on pending research.

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).

For more details on multi-transactions and Tableland execution, read the overview about Tableland state and how it relates to the EVM. Affecting Tableland State

Table “Lag”

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
13.5 seconds
5 seconds
5 seconds
≤2 seconds

For more information, see


Table Reads

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.

Currently, it is not possible for a smart contract to read data from a table created in contracts. Using an oracle or some offchain logic to write data back on chain (e.g., custom inbox-outbox type of setup) is an alternative.

← Previous