Tableland Decentralized Cloud Database

All right, we're live. GM everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute podcast for builders to showcase something they're passionate about or been working on in Web3. This could be an awesome project you've been working on, demonstrating testing best practices, automation tools, smart contracts, how to structure a project, so on and so forth. Basically, if you've got a passion for something, this is your opportunity to share with the community here. And today I am ecstatic to have Dan from Tableland, who will be giving an overview of Tableland. Welcome Dan, pleasure to have you on the show. Do you want to give a brief introduction about yourself just for folks who aren't familiar?

Sure, Dan Buchholz. I am part of the DevRel team at Tableland. We'll dive into the basics of Tableland, what it is, how you can use it, but TL;DR: Web3-native SQL database. So it lets you create a part of your full-stack dapp; Tableland can be that sort of backend to store things from application data to really anything that you would store in a database, which is so much. So I'm excited to show you some of the use cases and exactly how you can use it. In today's workshop, we'll talk about the Tableland Studio, which is a great way to just get started with Tableland. There are a lot of ways you can use it, but it's probably the lowest lift in terms of friction and getting started with things. So excited to dive into that.

Awesome. Yes, and looking forward to hearing what Tableland is all about here. So in the interest of time, let's get right into the content.

Cool. So maybe just a quick background on Tableland, what it is, how it works, use cases. So as I noted, Web3-native SQL database, and it's built on top of EVM chains. We are continuously adding more chains, but today we're live on Filecoin, Ethereum, Polygon, Optimism, Arbitrum. So we typically focus on EVM-compatible chains and really just add more chains as developers want them. But the basic workflow is that all create and write operations for the database are on-chain interactions. There are a lot of benefits to that approach. But basically, to use Tableland, under the hood what's happening is that we have a smart contract on-chain where you go and create tables that will mint them as ERC721 tokens. So every time you create a table in this chain-based database, you actually have ownership of that table itself. And then from there, you can write data to that table. So that could be via things like a direct smart contract call where you're basically writing SQL statements to the smart contract. And that, we'll talk about the architecture in a second, but basically these SQL statements get emitted as events, and then off-chain we have Tableland validator nodes which materialize all those SQL events in a database and make that data available to end users with read queries directly to the validator. So it's like this dual-pronged approach to basically help scale data in the Web3 space. There are a lot of benefits to that approach as well. Another thing that's useful in this sort of setup is that the access controls are all managed through on-chain interactions. So you can set up a smart contract, define exactly how people can mutate data, and it opens up and makes access controls really dynamic in a sense because you can do things like check ownership of an NFT or check a balance or require payment for someone to mutate data in the table. So it's really just the definition of collaborative, open, public data and datasets.

So why would you use Tableland? Maybe to talk about a couple of the benefits and use cases. So one, SQL. If you're a developer, SQL is probably one of the first languages that you learned. Even people who are more focused on the business side of things often learn SQL as part of some business application or understanding analytics, those types of things. So it's pretty low lift when you think about a Web3 developer. You might have to be learning Solidity or these new concepts, so for people that are especially new to the space, SQL is great because it makes it easier just to get into this Web3-native database approach. And then for people that are experienced developers, they definitely know SQL, so it really opens up the door for how people can use it and the types of developers that can use Tableland. But okay, why are we doing this? Why would you use it? If you think about how you store data in Web3, it's basically like three common buckets. And this includes if you're building an application, how do you store data? So one, if you have a smart contract, you could be storing information directly in contract storage, which is great because it's fully decentralized, fully permissionless. But smart contract storage is expensive. It's expensive to mutate that state, and it doesn't have the best query capabilities. So that's why networks like The Graph or indexing services exist, because it's hard to really query that data if it's directly living in a smart contract. And a couple of the other ways that people store data transparently in an application, people still do use centralized databases quite often. If you look at an NFT, for example, almost all that metadata is just stored on someone's server being run by AWS or Google, something like that. So that's another way people store data. And then the third one that we often see is storing it on immutable file storage like IPFS as an example, which we're big fans of Protocol Labs and the IPFS team and everything that they do. Anyways, big fan of IPFS and using it with Tableland, but it's not meant to be a database, it's meant to be a file system to store files and it's not designed for queries and mutable data. So we're focused on bringing more flexibility to that data management flow. And another big benefit of not just making the developer experience better and reducing costs is also it's super flexible in terms of how you can set things up. So it could be at the smart contract level, it could be we have an SDK, we have a CLI, we have APIs, so there are a lot of ways that you can use Tableland. And there's no infrastructure setup required on your end, so it's like this serverless in a sense type of approach, which is familiar for Web3 devs, of course. But in order to create a table, you basically just have to call a smart contract and then that data is made available immediately, or when the transaction is included in a block. So what can you do, what can you build? I mean, it's a database, so anything that comes to mind that needs data storage you could probably use Tableland for. But some common use cases could be application data, you could be storing user information, project information. All data is public, which is one key callout. So if you have private or sensitive data, that data should be encrypted before inserting it into the actual table. Another key use case is public datasets, collaborative data, DataDAOs, because you can have all this data out in the open but make sure only the proper people can write to the database and that can all be gated by on-chain access control. So as I noted, if you had an NFT from this just watching the session, that could be used as a way to gate who can write to some application that you're building. So it just again makes that access control truly dynamic so you don't have to define a specific user ahead of time necessarily, but it's dynamically determined using your underlying smart contract logic if you're developing at the smart contract layer. Another couple common use cases: NFTs, gaming. NFTs are an example; NFT metadata, if you are using a centralized database or IPFS, IPFS is probably the most common way to store just purely metadata. But if you're trying to make that data mutable, it can be a pain to manage the process for making it dynamic because you have to update a file and then that updates the CID and then you have to write that all on-chain and change that on-chain. So Tableland is kind of like one-time setup your endpoint and query to formulate this NFT metadata. So it makes it a way easier from a development aspect once you get that actually deployed. And then anything on the gaming side: inventory management, leaderboards. Data pipelines are another popular use case just because of that open and smart contract-based flow that you can implement there.

And then a brief on how it works. So there's an on-chain and off-chain component. On-chain we have smart contracts, that's where you create tables, you write to the tables, you can grant and revoke access controls. Your smart contract can actually implement the logic for something that's more complex to make sure there's certain assertions before someone can actually insert data. And then when that transaction is included in a block, then an event is emitted from the contract. This is where the cost component comes into play because once you create a table, that token exists on-chain, but the actual data mutations and the materialization of that data are not stored in the contract, but they're written as SQL events that are emitted and then materialized off-chain by Tableland validator nodes who go through like: okay, is this valid SQL? Does this person have the right ownership controls based on the on-chain rules? If everything works, the database is updated and then that data is materialized in that database and then accessible and readable off-chain. So it goes through this on-chain, off-chain flow. So the only callout here is that when you're writing data, it's always dependent on that base chain for how quickly the write transaction actually happens or the create transaction happens. So if you have a chain that's slow versus fast, that'll dictate exactly how fast you can actually write the data. But it gives like a nice ordering of the SQL events there.

Just to help show how you can use it, here's an example of the different ways that you would create a table in the SDK or via a smart contract. The SDK is just an abstraction of all the smart contract interactions. But if you're going straight to smart contract development and interacting with the Tableland registry contract, the bottom example shows you exactly how you would do that. So essentially different ways to do the same thing.

And then today we're going to walk through the Studio app. In terms of these layers of abstraction, the Studio is the entry point for anyone just trying to get started. So we'll walk through how do you create a project, how do you create a team, how do you create an account, how can you write data to these tables with the Studio, how can you inspect it. Just the basics of it. And we have a workshop also on YouTube, I could probably share that link afterwards, but that goes through really all the features that we currently have. And the Studio is in open beta, I'd say, and we're making an official launch in the coming months, so keep an eye out for that. But if you want to follow along today, you can go to studio.tableland.xyz and walk along as I'm demoing things.

And then last but not least, if you are interested in diving into the details, check out our doc site: docs.tableland.xyz. So I will start sharing my screen for the demonstration.

And while you're getting that set up, gang, if you have any questions for Dan, please post them in the comments and I will ask on your behalf.

Cool, thanks. I'll start with just, this is the actual production website. The workshop I'm walking through will be in a dev environment just to make things easier for me, but you can see in this setup I have created a few different projects. As an example, here's what I mentioned: the Studio, this app itself, has a number of tables that is storing application data. So the end result of when you go through this process will look something like this. So you can see all the different tables you deployed, you can click into them, inspect them, understand exactly what the schema looks like, see what deployment information looks like. We deployed all our tables to Arbitrum Nova because it was super fast and low cost, which is a good use case for application data like this. And then you can go through and inspect some of the data. So we're continually building out the features. Right now it's a lot of it is more focused, at least in the UI, more focused on reading and inspecting information, but we're definitely adding more capabilities around that. And then what's cool is maybe to demonstrate exactly how this works and when we say open data, we do mean open data. So you can see this is the official table name. You can actually query this data and we have a gateway, so I can query all the data in this table openly without any API keys or permissions or anything like that, and I can see all the information in that table. So hopefully that gives you an idea of how everything works. You create a table, that data is open once it's materialized, anyone can read it and anyone can consume that in their application.

And that data, just to review the whole flow, the creation of the table and the SQL statements are what live on the smart contract, but the actual data itself is hosted in the SQL database on these validator nodes that uphold the network, correct?

Correct, yeah. So now I'm in this fresh dev environment so we can walk through the different flows. First thing I'll do is sign in. First step is signing just a simple message for the sign-in process. You sign a message and then it prompts you to create a username, so I'll call mine dtb. If you want, you can add an email address but not required. And then go ahead and create an account. By default, when you create an account, it creates a personal team under that account name. And you can also add teams for collaboration purposes. So if I want to create a new team, call it collabs. And then I can add people to this collabs team, invite the various emails of people that I want, and then I can manage. Right now it's more geared towards just inviting people to kind of see the data, but we're also adding access control capabilities over time so then you can better manage that through the UI. But all of the, since this is all using, it's designed for managing teams and projects and tables. So you can also use anything that you create here in the other clients that Tableland has like the SDK, CLI, smart contracts. And if you have, and maybe if you're a developer working on that side of things and you create and deploy a table onto the Tableland network and you're not using the Studio necessarily, you can also import those tables into your project. So it's like a nice approach where maybe you're starting here, you're developing things and you want to bring it into actual application code, or maybe you started with building a React app or smart contract setup and you created tables there and you want to see and inspect the data, you can take those tables and import them into a project that you created here. So it's a good setup from that perspective.

First thing I'll do is create a project and I'll call mine starter. Add a name for the project, add a description: my starter project. So under the hood when you submit this information, it's getting written to a Tableland table. So that data is stored in the Tableland backend in a sense. Once that project is created, then the next step that you want to do is create a new table. And this first step is more like staging the table itself, it's not going to be actually deployed yet. But we'll call this my_table. We'll add a description: my starter table. So this will be the human-friendly name. You'll see what the unique table identifier is once we actually deploy it. But after that, we want to add some information around okay, what does the shape of this data look like? So we'll add a column for ID, integer, primary key. We'll add a column for val, we'll call it text. So pretty simple, pretty basic table. Then we'll submit that. So this stages the table essentially. You can see it's not deployed. If we click into it, we can see some of that information and down here, deployments, it tells you that it hasn't been deployed yet. So the next step what we want to do is actually deploy this table and create it on a chain. If I click deployments, I can see this is the table that I staged but hasn't been deployed. And I want to deploy it. So you click select chain. All the chains that we support, mainnets, testnets, are displayed there so I can click on any of them. I'm running a Hardhat environment in this dev setup, so I will deploy to Hardhat and I will click deploy. It'll prompt me for a MetaMask transaction which you can't see, but since it's an on-chain interaction, you do have to pay gas costs for creates and writes. I'll confirm that transaction. You can see it's been completed. Tableland has seen the transaction and boom, now it's there. So if I were to look at the Tableland registry smart contract, this table was minted to my address right there. And you can see this is the human-readable form and then some appended identifiers for the chain ID and unique table identifier. So this is like the NFT token and address technically, and then this is just a chain ID based on the chain that I'm using. Other information you can see like transaction hash, so you can inspect that data if needed. But to start we don't have any results; there's been no data added.

Now let's open up the Tableland Studio CLI and walk through how you can actually interact with that data in more detail. So first thing you do, make sure you've installed the Studio CLI. We actually do have a Tableland CLI, we'll call it like the more traditional one, not legacy necessarily, but it just has a suite of different features and we will be combining the two in the next couple of months. But right now they're kept separate. So once you install that CLI, the first step would be to run a command like studio init. And this sets up information like your private key, RPC URL. I've already done this so I'm not going to complete the steps. So you initialize your setup and then you do studio login. I've already logged in so it doesn't really matter. Let's logout just to double check. You sign a message and then a session key is created at this location, so that's what the login command does. But now that I've logged in with that account, I can see information that I created in the Studio UI. So you can see that collabs team that we created, you can see the default personal account with the project ID information around that project. And then I can also list the projects that I've created. I'm going to copy this ID real quick. One nice feature is that you can work in different contexts, which is helpful for making the interaction with the CLI easier. So I'm going to say studio use project and input this identifier. So now instead of passing certain flags to commands, I can just ignore those and use the context. And then I'll show how to import data. If I say import data, that table we created was called my_table, data.csv. And that's all that's really required. So I can import that data into the table. It'll tell you how many statements are created from this input. I'll show you the data in a second, but it also tells you the size of those writes because characters are interactions, so the longer your statement, the more expensive a SQL statement is going to be. So it just prompts you for some of that information and then you can see the completed information around what happened. So it mutated this table, here's the transaction hash, prefix, etc. And then I can open up this command, studio query. I can say select * from my_table. And that's the data that I'd written. And for context, data.csv, this was the file data that I wrote and this is the materialized information after it went through that on-chain event emitter and then the off-chain Tableland materialization. So pretty fast obviously in this Hardhat dev setup.

And so that's some of the basics. Maybe one last thing to show is just how you can import tables into your project. So I'll switch back into the Studio application. So here was that table that we just inserted data into. So if I refresh, you'll now see data exists, you can inspect it. And before I started this workshop, let's say I had a table that I created and I want to import that existing table into my project. So we created a new table, deployed it with the Studio, but maybe I want to import something that already exists out there. So the table ID that I was called, the official identifier was other_table, chain ID, table ID. So I'm going to take that, other_table is the table name, I'm going to select the chain. This will basically formulate that string other_table_31337_13, my other table. Now I can import that into my setup and have it accessible and viewable, inspectable in my project. So that was an overview of Tableland, the Studio, how you can get started. If you're interested in learning more, like I said we have a YouTube channel for workshops, you can follow us on Twitter for latest updates, join our Discord. We have developer chats and various channels to help with if you are getting started or if you are familiar with Tableland. Always interested to hear what you're building, especially if you have something built in the Studio you can share these projects with us, share the links. We're also adding features for our community like showcases to show what people are building. So would love to hear if anyone is building anything on Tableland out there. If you do, let us know.

Yeah, certainly. And thank you so much for this comprehensive overview. We have one question from the crowd here from Vlad who asks, how can Tableland be useful to metaverse developers? I guess it's kind of a broad question, but have you seen any applications or use cases that you can think of to apply Tableland to the metaverse?

Metaverse devs, NFTs and gaming are two popularly use cases which I think fit into that metaverse bubble. So from purely just an NFT example, if you're a metaverse dev, you can have this data openly stored in Tableland, so it makes collaboration across different metaverses pretty useful and different chains also useful. So as an example, maybe you have some character that's deployed on Polygon, that metadata exists in Tableland and it's readable at the application layer however you want. And you can also have cross-chain queries as well at the read layer. So maybe you have a metaverse here on this chain, metaverse here on this chain, but Tableland can kind of sit on top of them. So although the creates and writes are happening on those individual chains, the reads can happen between them. So it opens up collaboration opportunities. So in the metaverse you could be reading data from someone that owns something on Polygon, someone that owns something on Ethereum, and then render them in the actual application state. And depending on what the metaverse is actually doing, but some of that application data could even be stored on-chain. I think we actually had a team that built a game in Decentraland and that data was stored on Tableland. So people would come in, play the game, the game state was stored in tables. So then it's permanent, you can always have that data available. So it just brings in a layer of persistence and openness to anything that's happening in that digital world.

Awesome. Great to hear Tableland can expand into the metaverse use cases as well. I had a couple questions myself just before we end off here. You mentioned that the data that you upload isn't encrypted. Do you offer native encryption options for people uploading data through the SDK, or are people expected to encrypt themselves and then pass that information along?

It's something we've considered, but I think our general recommendation is that encryption can be a bit hard. So there are people that or protocols and products that really focus on encryption and that's their specialty. So generally we say you can manage the encryption, you can use whatever library or service that you want to encrypt that data before you insert it into a table. We do have an example, we have a plugin package for our SDK and there's an example encryption one. So technically out of the box you could have some basic encryption capability with the SDK, although it's maybe not the most recommended approach, but at least if you're just getting started it could be useful. Especially if you're storing sensitive data, we'd recommend something that you implement on your own. And then there's also protocols like Threshold Network or Lit Protocol that handle that from a decentralized approach. So you could use that in tandem with Tableland to make sure that data is properly hidden from open reads.

Gotcha, makes sense. And final question, you mentioned tagging you for Tableland for any cool projects. If people do have questions or have a follow-up that they want to ask, what's the best way to get in contact with you and the team?

I'd say join, if you look at our Twitter we should have a link to the Tableland Discord. If you look at our docs there's a link to the Discord. So Discord's usually the best option. We have a developer chat, we have a contact team channel where you can open up a ticket. We also have a Telegram channel if that's your preferred approach. Or if you are a Twitter person, @Tableland on Twitter, I'm @dtbuchholz on Twitter, so I'm open to fielding any questions there, but those are probably the best options.

Beauty. And folks, if you're watching this, all that information will be in the YouTube description after we end the session here. And with that, unfortunately we are at time, but Dan thank you so much for taking the time to come on and giving us that really great comprehensive overview of Tableland. Really excited to see what folks start to build with it. And before everybody leaves, I want to share with you the QR code for you to scan and claim your NFT for being an attendee here today on DevNTell. So what you want to do is grab your regular QR code scanner, scan this code, fill out the form, and you'll be airdropped a DevNTell attendee NFT over the coming days for joining us live here today. And you'll have an hour and a half from now to be able to claim the NFT. So you'll want to get on that. And with that, I just want to wish everybody a very happy Friday, happy weekend, and we will catch you back here next week for another great DevNTell. Cheers!