Transcript

Dave Rupert: Oh, it's going, right? It counted down already?

Chris Coyier: [Laughter] It counted down. You're... You missed it.

Dave: Oh, it counted down. Crap!

[Banjo music]

MANTRA: Just Build Websites!

[Laughter]

Dave: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I was totally tapped out for the intro there. Hey... I'm Dave. With me is Chris. Chris, who do we got in the studio today?

Chris: Oh, a friend of the show, Mr. Fred Schott, Captain, Leader. Probably has a cool, official title over at the Astro company.

Fred Schott: Steward, yeah. You're right. How'd you know? It's steward.

Chris: It's steward? Oh, cool. I like steward. That's a great word. It's close to Stewart, which I don't like. Sorry, all the Stewarts out there. Just kidding. I probably do like you.

It's a big week. As we're recording... Your podcatchers are giving you this on a Monday. We typically record on Thursdays. Did you know that, everybody? That's just a "Dave and I" thing from way back. I don't even remember how we got into it. It's locked in now.

What was it, Tuesday, Monday, Tuesday? When did you launch it, Fred? There's a big release that you're going to tell us all about at Astro, and we have questions.

00:01:24

Fred: Big 'ol Astro release. Can we spend some more time with that character at the start of the show that Dave was doing, like stoned cowboy?

Chris: Hmm...

Dave: Oh, does any of your Michael McConaughey--

Fred: [Laughter] Yeah. Yeah. When's coming back on the pod?

Dave: Matthew McConaughey.

Fred: Yeah.

Dave: Yeah.

Fred: Bring him back in here.

Dave: Alright, alright, alright. We are here, man. We are talking about it, man. Alright.

[Laughter]

Dave: Yeah, so anything new?

[Laughter]

Fred: Yes. It's been a busy week. We just launched Astro DB, which is a hosted database platform for Astro, designed for the framework, designed for people building Astro sites. It's a really unique take on what a database looks like and, tying it so close to the framework, there's a lot of interesting stuff going on. Yeah, we just launched it on Tuesday.

Chris: Oh, my God! Data and Astro together?! Crazy!

Fred: Whoa, Chris.

Chris: And there's a lot to talk about there.

Fred: Is content just data? Is data content? Is content data?

Chris: That's my favorite thing because, since you launched this thing -- and you meaning you plus the whole team of people that you work with, right? We'll give credit where credit is due. Whatever. That Astro is great for content sites. It's kind of rare, actually, for site builders like that to be like... to call out what they're good at because everybody wants to tell you that they're good at everything because they want everybody to try it.

Sometimes they are more right about that than wrong. There are niches. Any developer will know there are niches for certain types of tools.

It's like, "God, if a tool would just tell you that, that'd be fricken' nice, wouldn't it?" Astro did. They're for content sites. But sometimes content is wonderful in just a Markdown file sitting in a repo. I don't think that's going anywhere, right? That's great for blogging. It's particularly great for PRs and stuff against those repos.

But not all data is particularly good in a Markdown file. You can't write a hit counter in a Markdown file. And at some point, data just gets too much for flat files. It just isn't appropriate. Even comments, which I think it was smart that you made that kind of a first-class citizen of the documentation and stuff, like what if comments.

Perfect use case for data storage of some kind, so what were people doing before on Astro? Like it or not, it was probably nothing (to some degree). People were just like, "Eh, I don't like any of the options," or they wire up their own kind of something-something-something.

Now you've said, "I have the perfect answer for you. Here it is on a silver platter." There's your intro. I want to know how it works. What does Astro DB mean to you, Fred?

00:04:07

Fred: I mean that common example is the perfect... I think it's perfect. It encapsulates so much because you asked what do people do before. Yeah, it was probably nothing or they set up a full database on AWS or maybe a modern provider. Maybe they used a headless CMS for this and were kind of hacking their headless CMS for this sort of use case.

Yeah, there are a million different things, but all of them were pretty "go out in the woods and figure it out and come back with something kind of thrown together with duct tape and super glue." This is a perfect example of where a lightweight database can come up in where you can keep your content on whatever platform.

Maybe it's still Markdown. Maybe it's a CMS. What if you just added a comment system that's run out of your own database, so you own the data? It's not a third-party system or a SaaS product that you're paying for. It's a database. It's running. You own the SQL, and it's connected to your content wherever that still lives.

Yeah, I love that. Sorry. I love the common examples so much that I just get excited when anyone brings it up. [Laughter]

Chris: It's a perfect one. It really is good.

Dave: Yeah. I could maybe find a third-party comment system, Disqus or whatever.

Chris: Yeah. Sure. There you go.

Dave: Puts a few viruses on the page, but whatever.

Chris: [Laughter]

Dave: It's fine. But if I wanted to be like, "No, I want an emoji reaction machine or the hand claps from Medium - or whatever," now I'm in - uh, oh - roll my own tech situation. But not with Astro. Now you have first-party tech, kind of.

Fred: Yeah.

Dave: Would you consider it first party tech? Is it third-party tech?

00:05:35

Fred: Yeah. Sorry. I got so excited, I didn't even talk about what it is. So, Astro DB is a couple of things. When you start it up, it's a local database, so it's powered by LibSQL, which is this modern fork of SQLite. And the big thing about that is that when you're doing local development, you're not spinning up Docker. You're not spinning up PostgreSQL or MySQL. It's a literal database file for local development.

Dave: I'm sold.

Fred: So, you have a driver. It can run in the browser, like if you open up in Stacklets. There's a WASM build of the driver. It's so cool, super lightweight, and basically instant database.

Chris: It's light, but it's still MySQL, essentially, right? It's still... It's basically a SQL database. It just happens to be a file, too.

Fred: We have a lot of traffic. It's one of the reasons we've been so excited. LibSQL, if people don't know, it's the Turso team essentially went and forked SQLite and said, "We want to add a bunch of modern stuff to it. We don't think it should be this, like, dinky, light database. We want to prove out that the tech is solid enough and can stand on its own."

Global replication, scaling, all this cool stuff is built in. Yeah, we've been pretty shocked. Yeah, it's reputation as a simple database is not, I think, with a ton of merit. If you're building the next Facebook, maybe you'd consider other options. But for everything I've ever built in my entire career--

Chris: You can still have multiple tables and it's still a relational database.

Fred: Yeah. It's everything that MySQL can do. Yeah, exactly. It's a relational database. It's got all the perks.

Chris: Right, and if you really want to write select star from posts where post... where ID is greater than 100, you can do that. Right?

Fred: Yeah.

Chris: Yeah.

Fred: Yeah, exactly.

Chris: You don't have to because you didn't get to it yet, but you include it in the ORM, which is a nicer way to query for stuff, right? [Laughter] Basically.

00:07:16

Fred: This all came out of... So, we still have the same content collections. If you work from Markdown, you're loading Markdown from a file system--

Chris: Okay.

Fred: --we're basically giving you a type-safe schema API over that. But this all actually started from a place of, like, as we started to add more filtering and sorting and ... was like, "Oh, God. We're just building a database." Everything that SQL gives you for free, we're actually having to build as JavaScript, and it's slower. It's loading all of the memory.

Chris: Hmm...

Fred: We actually came to the idea of, like, what if there was a database built for Astro from a content-first perspective? They kind of sit next to each other now. They're kind of doing different jobs. But it's very much coming from that use case of, like, "Yeah, this should do all the things that I need to work with data." It's just, essentially, how do I access that data?

Why reinvent the wheel? We have 20 years... 30 years? There's so much experience built up with SQL, tooling built around it, it's a pretty great tech.

Chris: Yeah. Okay, and it's first part is a cool way to put it (right) because it's super tied at the hip, too, Astro itself. You didn't launch a data service that just anything can use, right? It's really customized to just Astro.

Fred: Right now, technically, there's nothing stopping anyone from self-hosting it. But we're building this to be essentially a fully kind of integrated experience, which means there's the local development. There's a schema API. There's the ORM. Then there's the hosted database.

All of these things are designed to work well together. There's opinions. There's whole workflows that are designed by us because we think they make the most sense. They're simple. It's better than any database I've ever thrown together myself because it's gotten so much thought and care put into it of these workflows.

Chris: Right. In your launch post, you even called out, like, "Hey, maybe we could have made this work with D1," or whatever was Cloudflare's thing, which is designed to be generic, right?

Fred: Right.

Chris: Cloudflare is a different world. They don't have a CMS - or whatever - a site builder tool they're trying to build. They're trying to build infrastructure that anybody can use, which is nice. Maybe you could have made that work. But you intentionally were like, "Eh... You know there's some extra crap we don't want here." That's okay.

You made opinionated choices to ship a product that's just smooth as butter, right? There's nothing weird about it.

00:09:23

Fred: I don't know if anyone knows there's a Hacker News comment that lives in my brain rent-free of when Dropbox announced on Hacker News, like, ages ago now. The top comment was, "This is ridiculous. I could do this all myself. I'd set up an FTP server, and I'd download the client on all my devices. And I would run that out of my basement. Why does anyone need Dropbox?"

Chris: [Laughter]

Fred: It's like, "I think there's something here about that," where it's like, if anyone asks why don't I just use SQL myself, you absolutely should. It's great. But it's a lot you have to do yourself that we're going to basically streamline for you into a full workflow.

Chris: Yeah.

Fred: Yeah. You can do all these things yourself. It's nothing being reinvented here. But that's kind of its power as well is if you don't want to do that.

Chris: Then the connection to WordPress is so interesting, too, is that that's what they're doing. They have both. They have this data layer and then they have this templating front-end layer, and nobody thinks that's weird. A lot of people think that's pretty darn good, actually.

Then they have APIs that are, like, "Query posts," and then you say what you want, and then you get that data, and then you use it in the template.

A lot of people are like, "Yeah, computers," or whatever. [Laughter] That's how it's supposed to work.

Fred: [Laughter]

Chris: But somehow in the world of this... Maybe the Jamstack era or whatever, maybe that's ended or that word got weird - or whatever. But the site-building tools left that behind. They did not... Homey didn't play that with the static site generators. They're like, "I don't know. Just get your data from somewhere or something." Now it's changing again.

Dave: Why did you kill Jamstack, Fred?

[Laughter]

Dave: Why did you kill Jamstack?

Fred: Personally with a knife.

Dave: Yeah.

[Laughter]

Fred: In the reading room. Yeah.

Dave: I do think... Do you--? I don't know. Astro was kind of the Jamstack or 11ty and Astro, the Jamstack tool. This changes it, but still, it feels Jamstack. It's like I have my database here. It could be a file on my server or in the production one. But it's not a full MySQL running, too. You know? It's different to me.

Fred: Yeah.

Dave: It's a very simple... It has the ethos of Jamstack, I feel like, still.

Fred: Yeah, I mean we came in too late. We were late-stage Jamstack, if that's--

Dave: Sure. Yeah, yeah.

Fred: I might be the first person who has ever said that.

Dave: Late stage Jamstack.

[Laughter]

Fred: We're trying to, I think, figure out what were the good parts of it if we're going to kill the term, which it seems like everyone is okay with, which is kind of wild.

Chris: It's a little wild.

00:11:57

Fred: But what were the good parts of it? I think it's still reliance on front-end tech. It's the most important part of this story. The APIs are powering the website. It's not like the website is in service of some database. Yeah.

Maybe you could say Vercel's front-end cloud is kind of this. There's a real importance on having a great front-end experience, and then I think it's about how can you empower that developer to do more. Yeah. Giving them a database, there's all of a sudden infinite kind of creativity, options.

Dave: Yeah.

Fred: I think it's all coming from the same ethos, I guess, even if the words and marketing are all changing around.

Chris: Hmm...

Dave: Even a choice elimination thing. I still want to get into some of the limitations of SQLite, but from a choice elimination standpoint, I don't need to think about what database.

"Oh, no SQL? Oh... Cassandra?" No, I just use this SQLite, or I don't have to provision a PostgreSQL on AWS or hook it all up. It's here.

But, I guess, kind of getting... Everything is a tradeoff, right? What are the tradeoffs with choosing or going with SQLite? What am I not getting?

00:13:06

Fred: Yeah, so I'd say there's what it's known for and then, I'd say, the reality that we've been experiencing, which we're still early. We need benchmarks and all this stuff. We've got to be able to backup our work.

Anecdotally, just from our own experience, really trying to break this thing. It's handling, yeah, thousands of concurrent requests. I think people have gotten it scaling up to like tens of thousands, maybe. I'm kicking myself because I don't remember the actual scale, but it's some factor of thousands (many, many thousands, possibly).

Dave: That's like Hacker News concurrency, right?

Fred: Right.

Dave: Right? Yeah.

Fred: This is serious tech. You can build something very scalable on this. Like anything, it depends on what you're doing and how complex is the query and all that. But at the end of the day, we haven't seen this to be super-limiting for Web traffic. I'd say a lot of database conversations and Web developer tech conversations kind of get messy a little bit.

Is this database scalable to a database back in architect means like how many millions of queries are we talking per second. I want to build a login system on this. Is that possible?

For the Web, that's usually not what we're talking about. The performance profile is SQLite and LibSQL, which we're using. It's really read optimized, so you're getting really great read performance and writes are the thing that are less of the priority. So, you still get those, yeah, many thousands of writes per second.

But for most websites, it's read-heavy. You're loading a lot of pages. Then some number of users are interacting. But read-optimized is what I describe as the Web. It's much more about read. So, for our use case, content-focused especially, it's really the perfect kind of fit. We haven't seen any use case that hasn't been able to handle even a future, like 10x growth of your site with SQLite.

Dave: Yeah. All the interview questions, like, "What's the O of N of this?" It's like, "Well, if N is only ever going to be 100, does it matter?"

[Laughter]

Dave: I know it does, but it's just like, if it's 10 or 100, what is the penalty? Yeah.

Fred: Yeah. There's a snarky answer to that question, which is, "You don't have any users. Don't worry about it."

Dave: Yeah, right? Yeah.

Fred: "When you have to refactor your database because SQLite, the promise is that that's a champaign problem and you have a team of people who can help you." That's not my answer, but I feel like that's the meme, like, you have no users.

Dave: Sure. Yeah. Yeah. Just use this until it literally explodes.

[Laughter]

Fred: Yeah, and our take is that it can get you pretty far into being many millions of users - all that stuff.

Dave: I mean I remember early days of Rails or Sinatra. You would use SQLite locally. That was the development database. Then you'd go to production and they'd try to hot-swap you to MySQL. It was just different enough.

For some reason, you hated SQLite because of that. It got a bad rap because of that experience. But I think it was just SQLite was not secure enough or mature enough to run in the cloud - or something. That was sort of the idea, I think.

00:16:08

Fred: There's a big part here, which is just that computers have gotten so much faster that SQLite and LibSQL are scaling faster, I'd say. I mean I guess everyone is benefiting from that, but there's a world where these limitations were probably a killer and you couldn't build on it. But now the sacrifices that were made for this lightweight model actually don't really end up... They end up speeding up in other ways because the hardware is much faster. The network is much faster - all these things.

The world has changed from, I think, when a lot of these kind of "SQLite isn't for production" memes started. That's what I love about this, yeah, what the Turso team is doing with LibSQL is they're trying to, like, "No, we can tell this story, believe it, and kind of walk the walk, not just talk it."

Dave: Yeah. That's really cool. It's Turso under the hood, but you give a little admin on the studio site, right? There's a little more to it than just a SQL database.

Fred: Yeah. Chris mentioned WordPress, and I think that's... My take on WordPress -- I don't know how much anyone else agrees with this -- I think people think of it as a CMS. But really, it's a database that comes with it that is empowering all the cool stuff: the apps, the ecosystem. That's the power of it.

There's a lot of inspiration from that of, like, there is this Web portal that feels a lot like the WordPress console. It's still new. It's early. But what you see there are the bones of a database viewer.

We shipped a Stacklets integration, so you can actually open up your repo in Stacklets, go into the admin portal, make a code change through Stacklets, come back, and it's all up to date. There's some really cool stuff you can do with this model that we're just kind of scratching the surface of. But essentially, a place where you can go to browse your data, interact with it, and hopefully extend that for rich text editors, for different use cases like a comment system. What if there was an app for your comments? That sort of thing, it's really a Web portal for your data.

Chris: Hmm... So, what about patterns? It's a way that I think about it. There's always... Jamstack taught us this. "Here's a way you can produce a site in this world. You have data wherever it is (static files or a database), and then you run a build. You get this static set of files. Then you deploy it and it's done."

Then the opposite of that is that every time a page is hit, it goes and builds that page, which is kind of how WordPress does it out of the box, right? It makes the queries that it needs. It gets the data. It pieces it all together, and then it returns that.

Then things got complicated in the Jamstack world because they could say, "Oh, we can do that too, though. You can have a page that's not prebuilt. You can have it built by a server on demand, as you need it to."

You might choose that path for something like a page that has comments on it because, eh, we want up-to-date comments. I don't want to have to run a site build just so somebody can see a new comment on a post. Or maybe I do want to run a site build, but that site build is so efficient that it knows that the only thing that's changed on the site is there's a new comment, so it just rebuilds that one page - or something. or it's a mixture of that and the homepage is statically rendered and never hits a server that's generating that page. But this page over here is.

It's kind of where we got with Jamstack, and it just feels like it got weird that each different page has a different pattern of sorts. Is this database kind of adaptable to all of it? Or if I opt into the database, am I opted into a world in which every page is build on demand?

00:19:42

Fred: Yeah. No, it's a good question. It's something that we have to deal with. Yeah, WordPress is like, "We're a server. You're shipping a server. Good luck." [Laughter]

Chris: Mm-hmm. [Laughter]

Fred: What we're trying to build for is a world where there is, yeah, static sites, dynamic sites, hybrid sites, serverless runtimes, worker runtimes (like Cloudflare that are even more limited). That's our audience and we're trying to build for them, so it means we have to play with more limitations.

Yeah. Ultimately, what we shipped, Astro's static site builds by default. And so, what this is, it's a local database by default. If you're building your site with Astro and you add the database, you're getting a local database, so a seed file. You're seeding with stuff. It's all local. It's using that SQLite file.

And you go to build it. You're getting a static build that use that local database to build the HTML, the CSS, and the JavaScript. Then kills the database at the end because you don't need it. It's a static site. There's your HTML. Have fun.

Chris: Hmm... What if I like that? Is that cool? Can I use the database in that way and then ship it? It's kind of like the database doesn't even exist on production.

Fred: Yeah. It's like the database of the whole hosted story doesn't exist, and that's totally fine. A big part of this was making sure if you never want to talk to our servers or host a database.

That's why people like static sites. I find it's way less complex. Your operational complexity, your hosting is just static assets. Yeah, people love that, and I love that. I don't want to kill that so, yeah, totally possible.

Chris: Oh, cool. Yeah, that's good. But there is also a world, I assume, where every blog post on this site is going to -- I don't know. What's the right word? Dynamically build itself on demand every time it's hit. That's a pattern I can opt into, right?

Fred: Yep. Yeah, it's kind of up to you. So, start static. Then when you want to go turn your thing that you're deploying into an actual server, make it some level of dynamic. We offer a bunch of different settings for that. But yeah, that's the day when you say, "Okay, this is actually a live site with a live database. Where does that database run?"

Chris: Mm-hmm.

Fred: That's where we would hook into the hosted platform to basically run a command. The database gets spun up, and now you're talking to it. It takes less than a minute for most people.

Chris: Oh, to provision the real cloud one and all that?

Fred: Yeah.

Chris: Yeah. Right on.

Fred: And that's in production. That's what you're using.

Chris: Yeah. Then is there a story of, like, "Okay, I started out with a blog post, which has an author, which has a title, which has comments, which is a relational thing"? That's probably a whole different table. But then Dave says, "I want emoji reactions, too. But I'm adding that a year down the road," which represents, of course, a migration of sorts. There was no way around that, I assume, right? How do you... What's the migration story?

00:20:48

Fred: Yeah, I feel like everyone just takes for granted that databases are easy, like, "Oh, yeah. This will all be fine." Yeah, okay, I have data here, and now I'm making a change to it. How do I make the change and then make sure the data that already exists is taken care of?

Yeah. Basically, when people ask, "What is this on top of, these technologies that you've chosen to build on? I could do this all myself," one of the things that we've done is built a really simple migration story where you're essentially synchronizing.

If anyone in the audience has listened to or has worked with, okay, "I create a new migration every time, and I edit it or hand roll it or maybe it gets auto-generated and I make some tweaks."

Chris: Yeah. Right.

Fred: We went the much more simple route of you run this kind of sync command and it's going to synchronize your database, push up any changes. If there's anything that's not backwards compatible that would result in data loss, it tells you to stop and manually kind of resolve that. But otherwise, it's a fully automated process.

Chris: Oh, that's neat. Yeah, so adding is always simpler than changing or removing, right?

Fred: It's renaming that always gets people. If I rename a column--

Chris: Is it?

Fred: --no schema has figured out, is that actually a new? Have you deleted a column and added a new one at the same time?

Chris: I see. I see.

Fred: Or have you renamed one? There's no way. Maybe you could ask an AI to kind of infer it, but there's no really good way to do that.

Chris: Yeah.

Dave: Yeah. It wants to -- at least I've seen -- clone that whole column into a temp and then it deletes the old column. It creates a new one and then pulls temp back over. It's just like, "Is that the best way?" [Laughter] That's the best way we came up with?

Chris: I just never do it all at once. I always just add it first and get it all working with the new data and then, later, worry about deleting the old.

00:24:13

Fred: That's actually really... Yeah, that's actually the model that we push people into. It's called expand and contract, and the idea of, like, add it first. Make sure all the code is working. Then delete the data. If you're trying to do it all at once, you're just asking for data loss and bugs.

Dave: Yeah.

Fred: It's way better. There are ways to work around it if you're just like, "I don't care. I'm hacking. Leave me alone." We'll just let you force push to the database if that's what you want to do. But for most sites, that's actually a best practice and what we try and do is make that really easy to work with versus feeling like a ten-step process, which is how it can feel in a lot of databases.

Dave: It can be bad, but you don't want to lose data either.

Fred: Yeah.

Dave: So, I like that you at least set up the old fence, like, "Hey, what you're doing is about to--"

Chris: Is destructive. Yeah. Pretty clutch.

Dave: Prisma, I use Prisma quite a bit, but that one is always awesome when it was just like, "Hey, hey, hey. Whoa, whoa." [Laughter]

Fred: Yeah. They're actually kind of best in class at this. The things that they catch and how well they present them back to you is something that we took a lot of inspiration from.

Dave: They actually run it in a shadow database, which I ran into some problems because only certain hosts support that - or whatever. They basically just try to run it in a cloned version of your database, and then they detect errors. I think that's... I hadn't seen that. That's pretty smart. Yeah.

Chris: I like the seeding story. That's pretty neat. This is all kind of useless locally if there's no local data to work with. It looks like you have a pretty neat story for that where you just kind of make a seed file.

Fred: Yeah.

Chris: It just puts crap in there. [Laughter]

Fred: Something I'm so excited about, which is it's so funny watching other players in the database space writing branching and merge requests for database and forking, like, I want a different database for every PR. That's really difficult when you have servers. Each of those PRs is spinning up a new server.

But if you're asking what are the tradeoffs for SQLite, for our model, that's actually just a new file, essentially. It's like S3 level of complexity for managing some of these things at a certain point where spinning up a new database, forking a database, branching, that's all actually... We already have that for files. We already have stuff that can handle that. There's some really cool stuff that we're going to be able to do over the next couple of months.

Chris: That's wild. Yeah. A database as a file is just a crazy concept that unlocks some stuff.

Fred: It's so cool. It's so cool. Yeah.

Dave: Yeah.

Fred: Every PR gets its own database, its own seed data that spins up.

Chris: Yeah.

Fred: Tears down. It costs you next to nothing. It's a really, really cool model.

Dave: There's no Docker, no VPN.

Fred: Yeah.

Chris: Mm-hmm.

Dave: [Indiscernible]

Fred: Feel like the slap chop.

[Laughter]

Dave: Yeah, slap chop. You want a database? Here you go.

Chris: I've got a database. Hell yeah. That feels very delicious, in a way. Speaking of WordPress, though, I'll tell you something I do all the time. This is just one guy, but there is a very popular plugin that makes this all work is that you're like, "I want my development to pull from production. I just want to click a button. It can take a few minutes if it needs to - or whatever. But I need to be working with what I'm seeing on production. I want to look at my blog with all my blog posts, with all my comments, with all my everything." But I wonder if that's like, "Eh... Not really the spirit of this," because then if you do that, now your seeding isn't this minimal set.

I always think of seeding as just like a little bit. You know? We have seeding for our Jest test at CodePen that seeds a little baby database so it can pull one little Pen and then do some stuff against it. It's trying to be minimal for efficiency. I wonder what the... I don't have any advice or anything. I'm just kind of curious.

00:27:57

Fred: No, it's like you're replaying the last month of our life. What are the boundaries between these things? We have the --remote tag, so as soon as you want to talk production data, whether you're building your site and you want to be talking to production or you're local.

Chris: Oh, that would do it. That's... You already kind of got it right there then.

Fred: But the seeding thing, that means seeding is a dev-only concept. Yeah, we're never really seeding your production database. You can write your own scripts, and you can seed it yourself. We give you a scripting API for that. But it's not seeding. It's like a different kind of concept, if that makes sense.

Chris: So, there is no story for, like... [Laughter] I'll tell you; this very popular plugin I'm talking about is happy to go both ways. It's like, "What are you trying to do? Are you trying to pull from production or are you trying to push to production?" Sometimes--

This would be wild to me. I've never worked this way. But some people work with their WordPress locally, get it how they want (including their database), and then they push the database live. [Laughter] I'm like, "Who are you?" But that's a thing.

Fred: [Laughter] Fearless. Exactly.

Chris: That's nuts. Yeah.

Dave: Hey, man. Real cowboys, man. They're brave.

[Laughter]

Fred: Oh, he's back. He's back.

Dave: Ain't scared. Ain't scared.

[Laughter]

Fred: He was here the whole time.

Dave: Yeah.

Chris: All right, so it's LibSQL. A lot of people are going to just think SQLite because that just has better brand recognition at the moment. Maybe that will change over time. [Laughter] Probably a heck of a lot of people hearing about this for the first time. Although, Dave, you seem to have heard of Turso before. I hadn't. Sorry, Turso.

Dave: Turso, but I think I'd been kind of following this whole, like, somebody put SQLite in WASM, and that was maybe Turso. I'm not sure. But it was just like... People were like, "Oops." [Laughter] Almost like I did something awful, but it's kind of cool.

That's where I remember the story was like I committed a database crime, a SQL crime, but it's kind of cool. I think that was maybe the sort of the beginning of this sort of experiment, just this idea, like, we can just compile SQLite out and it's cool. [Laughter] But no, it seems like they also made a C-binary, right? And so, it's super-fast and stuff like that - or Rust. It's got to be in Rust, right? Or Zig, Bun?

Chris: [Laughter]

Dave: I think Bun is ... Zig. Go?

Fred: [Laughter] Just going to start naming, yeah, Zig, Go, Rust.

Dave: The fast one, the blazing fast one, so it's blazing fast.

00:30:30

Chris: Well, I'll tell you another thing you don't get in WordPress, really. I mean maybe there's stuff I don't know about like editor integrations and stuff that somehow know about it, but there's not really a schema, really, in WordPress. Maybe you could generate one from SQL. I've seen that done plenty.

Dave: Here's the schema, Chris. It's WP_Posts.

[Laughter]

Chris: Yeah.

Dave: And everything just goes in there.

Chris: There's not like a schema file, you know? So, your editor knows about it. So, yeah, maybe there's some fancy editor integrations that just kind of know about stuff but probably not.

Fred: I think it's interesting using them as inspiration. I think it's been a big... Like if you look at headless SMSs. There's so much. Everything is a schema. Everything is... It's friction, and it's friction to a benefit of having really consistent types and explicit things happening.

Chris: Yeah.

Fred: Yeah, WordPress is like the Wild West. You can do anything. Here's a database. You figure it out.

There's so much power that comes from that. Then that ecosystem can kind of build-up to create some structure for those who want it and ignore it for those who don't.

Chris: Yeah. Yeah. I guess that is what they're doing. Because all sites are the same, in a way, you're not really generally structuring the database however you want. When you do something, you're limited to what they offer.

You're like, get author avatar. Yeah, you can do that. It's going to perform whatever database stuff it needs to do to get that. But on an Astro site or the database, unless you're using some kind of template that gets super ultra popular or something, every site is going to have a totally different database structure than the next. Right?

Fred: Yeah. That's good. I love that. I think that's how it should be. Yeah, I think there's an ecosystem story. It's day three now. I think we will really, over time, see are people turning database tables into packages, like, I want to install the blog package for Astro? Is it a theme that comes with a database table?

Chris: Hmm...

Fred: Are there integrations that have tooling tables, UI components, all built together? I can't tell you what that's going to look like. We have some ideas that we're excited to explore.

Chris: Yeah. It would be tempting for me to be like, "Oh, I need some kind of docks-ish site kind of thing." I don't want to think about the data structure all by myself. Give me a good one to start with. [Laughter]

Dave: There's a cool site. I think it's for Prisma. It's like recipes. It's like these little, like, "Here's a block of schema block," and then you just hit play. Then it seeds your database. Scaffolds it out.

Chris: Hmm...

00:33:04

Fred: Early on, we were looking at schema.org, which has anything in the world is a type.

Dave: Yeah.

Fred: It's a wild project. We were thinking, "Can we build on top of this?" Tony, who is a core maintainer, was really excited about that. But one of the problems we ran into is because everything is documented, it's the worst starter schema in the world. A blog post doesn't have an author that's just Fred. It's actually the entire type and that author has name, which is actually an object, his first name, his last name. Yeah.

Chris: Oh, it's just super verbose?

Fred: By thinking of everything, you have to think of everything, and it becomes really heavy.

Dave: Yeah.

Fred: Versus there's something about, "I want my author to be the word Fred, and I don't want to think about the right structure. I just want a string," at the end of the day.

Chris: Yeah.

Dave: It would be kind of cool to be like, "Open up." Just say, "I want a recipe site, and I want authors." Bing-boom. Send. That would be kind of--

Chris: It won't be too long until Copilot is helping you puke that crap out anyway.

Dave: Yeah.

Fred: [Laughter]

Dave: Devon.

Fred: Devon.

Chris: You do that. There's some kind of schema involved in this, right? It's been a minute since I've seen it, so sorry. It just came out, people! It just came out.

But you can say, "Oh, I want, literally, a recipe site," and you put... I don't know. I've seen videos. Ben did a great Twitter video of all this, too, where he scoped out an idea real quickly. It was like, "Oh, that's nice."

But by virtue of you doing that, and whatever other technology -- I forget all the different stuff you tuck into Astro -- then you get all this fancy crap while you're authoring your templates, right? If you try to ask for a piece of data that isn't there, it's red squiggles all day, baby. That doesn't exist.

Fred: Yeah.

Chris: Which is so nice.

Fred: Yeah.

Chris: That's the kind of ... that is starting to be almost more expected in the world. Probably thanks to products like Astro and TypeScript, for example, and type-safe languages and stuff.

You get the red squiggles when you're wrong, but you also get auto-complete when you're looking for stuff, right? You're like, "Oh, here's a blog post," dot! Then it gives me this list of data that I have access to. That kicks ass, you know? That's real nice.

00:35:13

Fred: My favorite type of TypeScript is when you actually don't write any TypeScript yourself and everything is fully typed. That's kind of the experience we're trying to hit here, which is you define a schema. It's not a TypeScript schema. It's a database schema. But from that, we set up the types for you. Yeah. Auto-complete, red squiggles when you're wrong, and you never had to write a line of TypeScript to get it.

Chris: Do you even see the types? Does it generate? Are they in a secret Astro folder or something?

Fred: [Laughter] There's a secret Astro folder that they get written to, but a lot of it is also inferred at runtime. Yeah.

Chris: Right on. Yeah, when we change data on CodePen (because we're a GraphQL-based site) it's like stuff just cascades. There are fricken' types everywhere. GraphQL needs special types. Yeah.

I call it a mess, but it's a very beautiful mess, to me. I don't mind seeing a PR that has some data change where you see a bunch of types changed, too. You're like, "Well, that's good. That means when I pull this, it's going to all work for me, too."

Fred: You can see the matrix. You see the types, the data. It's all one thing.

Chris: Yeah. I was pretty hesitant on all this type crap forever. Just kept spending so long of my career just not really worried in thinking about that kind of thing. But you know. When the DX story gets so much better because of it, it can wear you down. You're like, "Okay. Fine. Crap. It's maybe better." [Laughter]

Fred: I mean the smartest thing they ever did -- and maybe it's just a Microsoft monopoly play, but I love it, so I guess take that for what it is -- is VS Code. Even if you are writing JavaScript, you're getting the TypeScript. Everyone is better for a library or something to be TypeScript because, whether you write in it or not, your tooling, your editor, people who are writing in TypeScript, everyone has more information to work with. It's really cool when it's all kind of working together.

Chris: Yeah. I saw that in there. They had a little documentary. It was either about TypeScript or VS Code. There was a little bit in there. They're like, "Don't like TypeScript? Too bad. You're getting it in VS Code." You know?

[Laughter]

Chris: It's happening. That's what powers it. There's no alternate path. You're getting it, which is fine. It's good. Not true in not VS Code, though. You know? Just one thing. It's a little bit of lock-in, maybe, for that particular piece of software. [Laughter]

00:37:33

Dave: I was going to say, I did some digging. LibSQL is a fork of SQLite because SQLite is not open to contributions.

Chris: Oh...

Dave: They're going to keep a lot of the C and then they're going to put some Rust extensions in there. I just wanted to do some journalistic integrity there. It's Rust because Rust is fast. Or it's C plus Rust, which that suddenly sounds less secure. Good luck, Fred, on your business.

[[Laughter]

Fred: No! Yeah.

Dave: But no, I think it's great. I think anyone who works in data knows what's going on.

Chris: This should be a pretty easy upgrade. Is the DB release part of 4.0 - or whatever? Is it kind of a separate release?

Fred: Yeah. we'll see where it ends up landing. But as of right now, it's an add-on. You say Astro add DB on your command line, and then we take care of the configuration. We set up--

Chris: Yeah. You don't have to care about this at all--

Fred: Yeah, exactly.

Chris: --if you're like, "I don't care about data. It doesn't matter."

Fred: In the future, maybe it ends up inside of Astro itself. I don't actually know, to be honest. I think we're waiting to see what feedback is.

Chris: Right.

Fred: It works really well as an add-on because it's just out of the way for people who don't care.

Dave: Yeah.

Fred: Maybe it'll stay that way.

Dave: I love it. I have my big dumb bookshelf on my website. We're probably coming up on 1,000 books - or something.

Fred: Wow!

Dave: It's at least 300. But you know.

Fred: [Laughter]

Dave: There's a delta there. I'm not sure.

Chris: Yeah. Yeah.

Fred: Just a 3x delta. Yeah.

Dave: Yeah.

[Laughter]

Dave: Who knows? I'm no statistician.

Fred: Yeah. I read ten books, a million books, I don't know. I could never keep track.

Dave: Okay, it's ten books. It's ten books I read over and over.

[Laughter]

Fred: Dave can read, just to be clear.

[Laughter]

Dave: It's my children's books. So, it's 300. It is like a 50,000-line YAML file. It is not the best thing. I split up the YAML file. That feels pretty good. But what would maybe be cooler is just hitting a database. Even paginating the database, like progressively loading, doing some intersection observer, infinite scroll. Not that infinite, but I could load year by year, just kind of have maybe even a more intelligent version of it where I time stamp the date created. It's sort of by data created, not just order in file.

You could then play with stuff through filtering, like you're saying, and it's actual database filtering, not CSS filtering. I think that would be a pretty cool upgrade.

I had this idea for this podcast site, and it's like I started down the YAML file thing just to prototype it. But I'm 50 podcasts in, and I'm like, "God, it would be nice to have a database." So, already I'm like, "Ooh, Astro has a database, so that's probably where--" That's what I'm reaching for.

Chris: Isn't the seeding such a cool part of that story, too, if you wanted to show that or give it to somebody? You give it to them not just with the schema but with some data, too. So, if you're going to try it, you could be like, "Oh..." there's immediately some books in your book database. There's some podcasts in your podcast database to use and see.

Dave: Yeah. You run it, you get it. Yeah. Yeah.

Chris: Pretty cool.

Dave: So, I could just share it, and I think the idea (in my head) was like, "Oh, I'll build a whole entire app like letterbox for a podcast." That's fine, but maybe I don't build that. Maybe I do like what you were saying, Chris. Build something that other people can build. Build something to where somebody can just clone a repo and have their own podcast shelf or bookshelf.

Chris: Sell it for $100, man.

Fred: [Laughter]

Chris: What's the scene on that like?

Dave: Oh, I need money. That's great.

00:41:21

Chris: I'm sure there are plenty of little kinds of open-source free ones. But man, there was some empires built on WordPress themes, not to say that word too much. Have you seen the paid theme thing happen?

Fred: Oh, my God. Yeah. It feels like an entire industry. There's a class of industry, and the IRS is a code system of WordPress themes.

Dave: Yeah, wow.

Chris: I mean are you seeing it in Astro land? Is there a paid Astro theme yet? Yeah, some? Cool.

Fred: Yeah, we have a couple. Actually, there's a couple of pretty prominent. There's the shops that do themes, and they've been building for Astro. But there are a couple of people who are now dedicated Astro theme builders. If you go to astro.build website, there's a theme catalog.

One of the cool things we shipped this week was also a portal for theme authors, so you can actually log in and manage your theme submissions. This was all done out of a GitHub repo and literally raw JSON. It was a mess. But now there's an actual Web portal, so the idea is that this can be a place where, yeah, we really care about themes.

Chris: You auth with GitHub, and you say that repo, that's a theme for Astro.

Fred: Yeah, exactly.

Chris: Yeah.

Fred: Here's the information. Here are the four beautiful screenshots. Come back a week later. If you want to change stuff up, you can.

Chris: Okay. That's cool.

Fred: It's a thing that we care a lot about. I think, in the future, if we wanted to add paid themes, now we have a place for you to actually get paid. I think there's a really cool story there that we want to explore.

Chris: It does seem like a big deal. There's a whole class of user that's not interested in building a site absolutely totally from scratch. Right?

Fred: And Tailwind, I feel like everyone has been... There seem to be UI kits from Framer. People seem to be really appreciating that more now than I think they did. Up until a couple of years ago, I was probably just like, "Themes, yeah, okay. That's kind of nice." But then secretly, I would go and try and find a theme any time I built a site, like, "I don't want to set up the bare bones. I just want something out of the box that's close to what I want. But I want to be able to hack it."

Chris: Yeah.

Fred: Yeah, themes are super-cool.

Chris: This also seems... The data thing, I mean, seems like a natural progression. I think you've called that out specifically in some of the writings around it. But it was 2.0 that had content collections. This is a really tight integration with that, right? I don't know. It seems like that, right?

If you're going to make a podcast app - or something - that has this podcast type that it should be a content collection, probably.

00:43:38

Fred: We've moved past... Yeah, Dave was talking about how, yeah, 300 YAML files, you mentioned, I think, in a repo. At a certain point, the scale is going to be tough or you're going to want to do something with that that's a bit more dynamic than just throwing it all in a query and CSS filtering. Yeah, I think that's where we're really.... Start with local Markdown. Start with local.

If you just want to import a JSON file from your file system, Astro is a Web framework. It can do that. I think what we're trying to do is basically have all these different kind of moments, like the super-simple one file, the several files but I don't really care that much, and then, okay, that was thousands of books in a file system. Making it really easy to jump from point to point and having an option for all those things.

I think what's best for managing 10,000 books is not going to be the best for managing 3. And it's not smart to try to think that that's all one system.

Dave: Yeah. For sure.

Chris: Hmm... So interesting.

Dave: Can I do protected routes? I want to add books to my bookshelf or my podcast shelf, and I want only me can do that from the production. Is that something I can do, like, easily just chuck some auth?

Fred: Yep.

Dave: Am I in clerk.dev territory? What's going on there?

Fred: No. Yeah, we're days away, I think, from someone publishing the canonical user auth in Astro DB. But our own theme portal has that, so we as admins can log in to manage themes.

Dave: Oh, okay.

Fred: But most people in the community are logging into submit themes, all powered by Astro. It's Astro DB all the way down.

Dave: Oh, wow!

Fred: User auth, image uploads, form submissions, yeah, it can do it all and, yeah, protected routes. Again, it's where you're kind of hitting the limits of what a static site can do than what Astro can do.

Dave: Mm-hmm.

Fred: That's where you kind of have to make that move into a server-rendered site. But we try to make that as seamless as possible.

Dave: Sure. Yeah.

Chris: That does seem like it would be coming, right? You could imagine, "Yeah, fine. You can leave comments on my blog, but I'm not even going to let you do it unless you auth somehow."

Fred: Yeah.

Chris: Then once you're auth'd, then some of that data comes along with the comment.

Fred: The thing about Clerk, which I love -- their DX is kind of unmatched.

00:45:43

Chris: What is Clerk?

Fred: Clerk is like, "What if I don't want to think about this? What if I just want to drop in...?"

Dave: Auth zero, work OS - sort of situation. Yeah.

Chris: Oh, I see.

Fred: But they've done a great job of, like, it feels like you're using React components. You're not setting up this enterprise tech. It's a really great DX.

Chris: Hmm...

Fred: But my big question, I think....

Chris: I really doubted myself not knowing about all these tools. Then I go to their landing page, and it's like all these people I know with great quotes. I'm like, "Oh, god-dang, man!"

Fred: It just means you have a life, Chris. It means you... [Laughter]

Dave: Or it's like your face on it is like, "Chris Coyier says, 'This is the best!'"

Chris: [Laughter]

Dave: You're like, "What?!" [Laughter]

Fred: "I love Clerk. I've been using it for years." What?!

Dave: "I depend on Clerk." What?!

Chris: Yeah, it looks amazing. God-dang it.

Fred: Clerk is cool.

Chris: I need to get around.

Fred: I think it's one of those things where it's like Clerk is a great DX. The way that they accomplish that is by hosting your auth tables, essentially, like your user table for you. I think one thing I'm curious to see if this works is, with Astro DB, can we give the same DX of a Clerk but it's a community project. We're not building it ourselves.

There's already this project called Lucia, which is a great auth library. It can be leveraged, the open-source ecosystem stuff, and then just provide the database. But at the end of the day, it's your database table. You can export it whenever you want.

Chris: Yeah.

Fred: We're hosting it for you but go do ... prefer directly or your own SQLite server. And it's the same DX but without the external host.

Dave: Yeah, like the recipe for passkeys or something because I don't want your password.

Fred: Yeah.

Dave: Especially on DaveRupert.com. I literally don't want that liability. So, if you can just passkey in, and then your phone says, "Yep, that's Dave Rupert," I'm stoked.

Chris: I mean Firebase did this like ten years ago, right? That's why social auth, baby.

Fred: Yeah.

00:47:33

Chris: But passkeys now is the answer, probably.

Fred: Yeah, thank God. It couldn't have come soon enough. Although, it's so funny. As a user, I'm like, "Oh, this stupid passkey thing." [Laughter]

Dave: Yeah. I don't have a single one set up, but I want it. I don't know.

Fred: I know. I know.

Chris: Oh, you don't? Really?

Fred: As a site ... "Oh, thank God. The savior." As a user, I'm like, "This sucks. I hate this." [Laughter]

Dave: My hiccup is 1Password always asks me first. They're like, "Do you want to use a passkey, dude?" I'm like, "I don't know if I want you to have it. Maybe if my phone asked me, I'd say maybe."

Chris: I think you do.

Dave: I think I want?

Chris: But I'm not....

Dave: I don't... I need to watch... I need a video of somebody who, like--

Fred: Well, 1Password already has all your passwords. I feel like they're already... You're in too deep to be worried now.

Dave: Yeah, but it's the strategy to get out or marry them? I don't know. [Laughter]

Fred: [Laughter]

Chris: Oh...

Fred: DB export, export 1Password. Yeah, I have no idea what that looks like, to be honest.

Chris: It is far, kind of. You forget about which things sync to what, kind of. If you set up your passkey for Google on your laptop but you have other laptops and phones and stuff, what's syncing it? Is it nothing? Is it the iCloud Keychain? Is it Google themselves somehow? [Laughter]

Dave: I have 1Password, and I set up all my kid passwords with 1Password, and it's the bane of my existence because I am now the bottleneck for every login situation in the house. Oops, I was just trying to not get us hacked. But now I'm like, "Hey, dad. I want to be inside Roblox."

Chris: Post-it Notes, Dave. You put a Post-it Note inside your cabinet.

Fred: [Laughter] We had it right all along.

Dave: Well, yeah. I mean that is a tried and true method, and maybe some family members do use that.

[Laughter]

Dave: But I think, for me, I'm like, "Oh, if I just put all this on Apple and not done the whole Windows thing, maybe that...." No. [Laughter]

But if I just put all these passwords on Apple, then I would have no problem. But then I think, also, my kid could log into my bank, and that seems like a problem, too. [Laughter] So, I don't know.

Chris: [Laughter]

Dave: I don't know.

Chris: Clerk is the answer, Dave.

Dave: I need a fricken'... I need a computer scientist to manage my passwords. That's what I... A secretary who has a degree in computer science.

Chris: My mom has got this big, giant manilla folder where you can put stuff inside from the top.

Dave: Yeah.

Chris: The front of it is just 20 years of chicken scratches.

Fred: [Laughter]

Chris: "Oh, no! It's not that anymore! It's my old dog 1984."

Fred: Every time they forgot it and then had to reset it and then rewritten it. Yeah.

Dave: Yeah.

Chris: Yeah, that's great.

Dave: Yeah. Yeah, "I'll send you the spreadsheet." "No, no, no. Please don't! Please stop!"

[Laughter]

Dave: That violates my own corporate policy.

Chris: Don't do it!

[Laughter]

00:50:31

Chris: All right. Well, hey. Congrats on the big launch of this. It feels a little new to the world to me. It feels like a fresh take on this sort of thing that I have not seen before.

Fred: That's what we're all about. That's the highest form of praise for what we're trying to do. Yeah, we'll see.

Chris: It also seems very not like, "How does this work?!" Which apparently we're getting to that age, which, ugh, don't love it. But this is not in that category.

I'm like, "Oh, I get it." [Laughter] You know?

Dave: Yeah. Yeah, you avoided the Homer car, which is really good.

[laughter]

Dave: You avoided a Homer car situation.

Fred: You should have seen the conversations over the last couple of weeks of, like, "Have we built the Homer?" Yeah, it's like... It's always tough when you're doing this, like, where are the lines? But yeah. Look, we'll see how people use it. I think it's the fun part about Astro is we definitely are building it alongside.

Chris: How does that kind of feel like you want to think of a reason to use it? You know? You're like, "Ooh... That looks fun. I want to put something in that."

Dave: Well, if you get tired of it, you kill the free plan, Fred, and just... You know? Walk away.

Chris: Ah! We forgot to talk about that.

Fred: We got there. We got there eventually.

[Laughter]

Chris: That was killer timing.

Fred: He has been holding that in his pocket the whole time.

Chris: [Laughter]

Dave: I'm just impressed. How did you time your release with their implosion? That is just incredible. [Laughter]

Fred: No....

Chris: What's the news, for real? Just do it for the people listening so they know what we're talking about.

Dave: PlanetScale, who we had PlanetScale on. They're great. They offer a really awesome, super scalable MySQL product. But they did kind of a "layoffs plus we're killing the free plan" blog post, and that was not well received in the community, I believe. I feel like that's... I don't know.

Fred: Yeah.

Dave: Unless Fred has other takes, but--

Fred: Layoffs, killing the free plan, and you have a month to get off of it. "And don't worry. Everything is fine," was kind of also the weird little subtext.

Dave: The paid plan is $40 - or something like that. And so, it was a really generous free plan, we should say. It was like a million rows or something like that or 100 million rows or something. It was wild.

Chris: It teaches the world a crappy lesson, though. It says, "Here's a way to start a company. Have free plans for a long time and then rug pull them." That's literally what happened. So, what's the deal?

Fred is sitting right here. It's not infeasible that at some point... What's the pricing? I didn't even look. Let's do it for the air, though. [Laughter] How much does the hosted DB cost? Is it just a flat rate? How do you bill it?

00:53:09

Fred: Yeah, so we have a free plan. We're pretty proud of it. Yeah, by the way, the timing of this, we did not plan this. This is just a weird cosmic coincidence that this is all happening and that they're removing their free plan right as we're trying to ship a pretty generous one. But a billion row reads a month, a million writes a month, a gigabyte of storage. I think a big thing for us--

Chris: Oh, you just have some... There's some metered stuff.

Fred: Yeah, it's all metered and all usage-based.

Chris: Okay.

Fred: For us, the tech stack is essentially you're paying for storage at rest. But if you're not making requests, there's no server. There's no shutdown or spin-up.

It's one of the things I love about our model. We knew this going in, so we got to design for it where maybe if there is a fault of these free plans that get yanked later, it's because, "Oh, shit. At scale, this is really expensive," and you can't really fault, I guess, realizing that and wanting to build a company that doesn't go under.

Chris: Yeah.

Fred: But for us, knowing this would matter, we built the whole tech stack around this use of it's going to cost nothing at rest. It's really, really cheap, affordable, and efficient. And that lets us then actually offer this without breaking the bank. Whether we hit a million databases or just 20, it's all pretty cheap. It all just depends on how much they're being used and aligning our incentives with our users. So, if you're using it, you pass. If you're not, fantastic. And a pretty big window before you even have to start having that conversation.

Chris: And there's some world just... I don't want to start this on a negative thing, but this is brand new for you. The PlanetScale thing could theoretically happen to you. I'm not saying it's going to.

00:54:40

Fred: It's a hard thing, really. I don't really know what the right answer is here. You can see me kind of probably struggling with it.

You want to just be like, "Yeah, don't worry about it. Trust me."

Chris: Oh, yeah.

Fred: No, that's exactly what I don't want to do. I want to know for sure it's not going to happen because, like, Heroku.

Dave: Well, and--

Fred: Got bought by Salesforce. New leadership come in. It's tough. There is no--

Chris: Well, there are unlimited examples of this.

Dave: Based on my ten-to-one, free-to-paid Heroku usage, I understand the decision.

[Laughter]

Fred: The thing I'll say about it is the big thing for me is I think this is just a human nature thing. It always comes down to incentives, like, "Why is anyone incentivized?" What I'm trying to do... Because, at this moment, we care about this. We want it to last forever. It's all about, then, can we actually put in place things now that the incentives would make no sense for us to remove it? GitHub is the example I used in a tweet of, like, "If GitHub killed their free plan, no one uses GitHub." There is no GitHub without the open-source community behind it. I think there's an analogy here of, like, if we ever imaged that press release going out, I imagine it'd be like, "Why are they killing the entire reason this thing exists?" That's what we're going for. That's what I'm trying to aim for here. It should be so dumb for us to ever pull it that even an evil version of ourselves would never do that.

Chris: I wonder what you'd hit first? I guess it just really super duper depends. But just to make this clear for people, it's ridiculously generous. To me, it seems a billion reads a month, which that's a lot of reads, I'll say, and a million writes per month, which is even more, really, as you laid out. Generally, writes are more rare, especially in a content-focused website. Then a gigabyte of storage, and you're not putting JPEGs in there, right?

Fred: Yeah.

Chris: A gigabyte of text is a fricken' lot. So, yeah. Good luck breaking that. I'd be surprised if anybody... It's been... As this airs, it'll have been out a week. I would very much doubt anybody has hit it yet.

Dave: I can do it. I can do it.

Fred: [Laughter] Dude, good luck.

Chris: [Laughter]

Fred: No, it's one of those things where what I love about the usage-based model is it incentives you to be efficient with your own database. I did a stream with ... a couple of days ago or weeks ago now.

Chris: Yeah.

Fred: The thing that I demoed through 5,000 people (or however many people he had in his audience), it was super-inefficient. Every request loaded thousands of rows. I could have refactored that and cleaned it up, and it would have been a couple of rows. It would have been super lightweight. I think it just encourages good practices in terms of efficiency on your end. Yeah, it totally aligns everyone's incentives. If you use it a lot, pay us. If you don't, that's great. Whatever that means, whether that's low traffic or just really efficient use of a database. Both are valid.

Chris: Yeah.

Dave: I like that.

Chris: Crank down those dials, man, just a little bit.

Fred: [Laughter]

Chris: [Laughter]

Dave: A little bit.

Fred: Are you trying to get me rug pulled?

[laughter]

Fred: Are you trying to rug pull me? No, we stand by that. We think we can. I mean it's early access. I would be shocked if it changed at this point because it's just part of the package.

Chris: Oh, no. I'm sure it won't. That's fine. It's just when you get to... It feels like that scale is right at the same moment where people might consider a different architecture altogether.

Fred: Yeah.

Chris: You don't want to miss them on the way up.

Fred: That's true. That's our goal is that this should scale well past this without anyone breaking a sweat.

Chris: Yeah. Yeah. Right on. Yeah. I imagine, too, you're going to get the... This will be the most common, annoying email is like, "I really want to use this, but we need to host it." Then you'll be like, "Um, sorry."

Fred: Yeah. No, not annoying. Yeah, it makes total sense. I can't remember. Yeah, we were talking about this, the idea of we've designed this all to be vertically integrated. It's not something... We intentionally are not shipping self-host in, but at the same time, it's open source tech. We want you to be able to play around with it. If a hacker culture or someone just ships the open-source self-hosted version of this, if someone wants to maintain that, that's great. But we're trying to walk that line where we don't want to block it for no good reason. But at the same time, there are things we're doing because it's hosted that you couldn't do otherwise. We don't want to shut those doors either.

Dave: You know it's really secure? A file on the VPN.

[Laughter]

Fred: It's just a couple thousand YAML.

Chris: Yeah.

Fred: Never....

Dave: Static file, you know, database file.

Chris: The trick is not caring if it's secure.

[Laughter]

Fred: I do not stand by that, just to be clear, as someone now running a database company. That is--

Dave: Abstracting that.

Chris: Oh, no. Very secure.

Fred: I do need that next to Chris's face. I need that to be on the homepage of Clerk.

Dave: Yeah.

Chris: [Laughter]

Dave: The trick is... This is Chris's Frontend Masters security course. The trick is don't put anything up unless you really want it out there. There you go. Love it.

Chris: It's from that. Was it Promethius or something? There's a robot in that movie, and he keeps holding a lighter under his finger. He's like, "You know what the trick is? Not minding that it hurts." It's creepy as hell.

Dave: Whoa!

Chris: [Laughter]

Dave: That's a good one to end on.

Chris: All right. We've got to go. It's over.

Dave: Yeah, that's a good one to end on.

[Laughter]

Fred: On that note--

Chris: Yeah.

Dave: Yeah.

Fred: All right.

Dave: Fred, for people who are not following you and giving you money, how can they do that?

Fred: Follow me on Twitter, @FredKSchott, and Astro is astro.build. That's both the website, astro.build, and then the Twitter handle is @astrodotbuild. Yeah, if everyone is hearing this, it's after our launch week, but you can go there and see a recap of everything we put out this week, including Astro DB. Yeah, it's been a crazy week. Thank you all for letting me come on here and talk about what we're doing.

Dave: Very exciting. Well, thank you. Yeah, I'm excited. It really is hitting me at a perfect time where I had this idea brewing. Then it got too big. Then I was like, "I'm not going to do it." Then it was like, "Oh, wait. This is coming out soon." It was like, "I think I--"

Fred: Yeah, where would you have time? You've been reading 5,000 books a day, I think was what you said, right?

[Laughter]

Dave: It's a lot, and it keeps me busy.

Chris: Yeah.

Dave: But hey, they wouldn't put them in the library if you weren't supposed to read them. You know? Sometimes, the whole entire library is just a to-do list. You know?

All right, well, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Follow us on Mastodon because that's the good one. Then head over to patreon.com/shoptalkshow and join us in the D-d-d-d-discord. Chris, do you got anything else you'd like to say?

Chris: Oh... ShopTalkShow.com.