Tableland is a serverless & permissionless web3 database. It sits alongside Ethereum and Layer 2 (L2) chains but is purely focused on data storage and retrieval. Namely, Tableland helps scale smart contract storage by offloading data accessibility to a decentralized network that executes database instructions, signaled by on-chain interactions and access policies.
Really, any type of data can be stored in Tableland, such as the following use cases:
- NFT collections store pointers to large media files, along with other NFT attributes, and can have owner-driven actions mutate the metadata.
- Data DAOs can upload large datasets to persisted file storage but store its metadata in Tableland tables—and enable shared access for collaborating (with on-chain accounts / rules).
- Gaming-related data like scoreboards and leaderboards make it easy for chain-driven data to be immediately queried at the application layer, off-chain.
Problem
Web3-native apps are forced to make a choice when storing application data: fit everything into the web3 mould, or use a partial web2 approach. Fitting everything into a web3-native stack often equates to costly or complex designs to store all data on-chain or use decentralized file storage as a pseudo-database. With a partial approach, apps are deployed on web3 (using smart contract backends, frontends deployed on IPFS, etc.), but traditional, centralized web2 databases (AWS, Google Cloud, etc.) are still being used for a subset of structured data.
Let’s expand a bit. IPFS ensures data is openly accessible, but the data itself is stored in a file and makes it immutable. This leads to a limiting experience since this data itself cannot change (“mutate”), and files (and their internal data) are not easily queryable nor composable. Alternatively, a centralized service provide an effective solution for highly dynamic that supports support query capabilities (needed for any application): a database. But, centralized databases are not “open” web3-native solutions; data is kept behind a permissioned wall and is not interoperable nor composable.
Solution
Tableland offers a new approach that enables dapps to store relational data in a web3-native network, without having to make these decision tradeoffs. Traditional relational database capabilities are now possible by leveraging the blockchain layer for access control and database instructions—it’s just web3-native relational tables in a shared and permissionless database. In other words, data can be mutated (if desired, using on-chain access controls), queried (using the familiar SQL), and is composable (with any other tables).
Tableland is the database for fullstack decentralized applications.
In tandem with other distributed work infrastructure, web3 now has a home for structured relational data that is openly stored in a database network. You can imagine the application stack breaking down into a few buckets:
- Users access applications using browsers and wallets—NFTs, DAOs, and dapps sit at this access or coordination layer.
- The underpinning blockchain’s features provide a framework for ownership, access, and compute (e.g., any account can send transactions and own tokens).
- Alongside the host chain, you have web3 infrastructure like databases for “small” data (up to 1kb) and persisted file storage (for large media).
One key callout is that Tableland is always tied to the host chain since table creates and mutations must pass through the host. Not all decentralized infrastructure behaves this way, as some networks may primarily act as a standalone protocol and do not have the required on-chain anchoring like Tableland does.
How does Tableland work?
Tableland decomposes a traditional relational database into two primary components:
- On-chain registry with EVM account-based Access Control Logic (ACL).
- A network of permissionless databases running a web3-limited SQLite.
Each table in Tableland is initially minted as an ERC721 token on the base EVM-compatible layer. Thus, there’s an on-chain table owner that can set ACL privileges for a table, and the off-chain Tableland network manages the creation of and subsequent mutations to the table itself. The link between on-chain and off-chain is all handled at the Tableland gateway—off-chain read queries allow for accessibility of SQL data while the core data availability is all on-chain.
Access control
Only those with the proper on-chain privileges can write to a specific table. Table reads, however, do not have an on-chain operation and use the Tableland gateway. Thus, read queries are open and can come from a simple frontend request or even other non-EVM blockchains. Anyone can read table data.
Conclusion
Don’t settle and store your web3 native data on Tableland! Develop using our SDK, smart contracts, REST API, or CLI—and help build web3 with SQL!