A listing of the table/data limits and smart contract deployment locations on supported chains.

Tableland isn't a new database — it’s just web3-native relational tables. For now, each Tableland testnet table is limited to the following constraints:

Table 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 a testnet, row limits have been imposed. When Tableland launches a 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.

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