Brian:
PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution, which is to say, it's not really sponsored by anyone. It's sponsored by us, BlogRocket, and we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested, and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks. Today, Ben and Kate talk with Paul Copplestone, CEO and co-founder of Supabase. The open-source Firebase alternative. They discuss how Supabase works, what's in store for 2021, why open-source matters, and the role Hacker News played in Supabase's launch. Let's get started.

Ben:
Hey, Paul, really excited to have you here today. How are you doing?

Paul Copplestone:
Good. Thanks, Ben. Yeah, very excited to be here.

Ben:
Yeah. I've used Firebase over the years quite a bit for side projects and stuff. So really excited to learn about Supabase, which on your website, it says an source Firebase alternative. So maybe my first question is what is Supabase, and how does it compare to Firebase?

Paul Copplestone:
So, we are an open source Firebase alternative, as you said on the website. And basically, we're building the features of Firebase, but we're using open source tools, and we try to use existing open source tools wherever possible. For those who possibly don't know what Firebase is, Firebase is basically a suite of tools that help you build very quickly. So it's a database, a real-time database. It's storage, it's auth, it has cloud functions, it has analytics. So it's not a single thing, but an amalgamation of tools that make it very easy to build, and so you just focus on your product. And it's actually a great tool, really nice to build with, but it's not open-source and that has some scalability issues, is typically what people would run into. So we're just building the features of it, but not a one-to-one comparison. We've chosen some different technologies, and then we're trying to choose technologies, which first of all, exist in the market, so we don't reinvent the wheel, but also have enterprise grade scalability.

Ben:
Cool. And I definitely want to circle back on that topic of scalability, but to start, I'd be curious to talk through those aspects of the stack. You mentioned the tools that are part of Firebase, starting with the real-time database. As I recall, Firebase is like a NoSQL database, right? It's like... You give it JSON, and so it's a NoSQL type database? What database is included as part of Supabase, or what open source database have you built into it?

Paul Copplestone:
So, we actually built on top of a Postgres database, and I think as you correctly pointed out right at the start, Firebase being a real time database, and Postgres is not. So this was actually the first thing we built and open sourced ourselves, and probably the only tool that we'll really build from scratch is a real time engine on top of Postgres. And then basically, we listen to the replication log of Postgres, and we blast it out over web sockets using an Alexa server. So yeah, this is the part of our scalability, which has solved for us. Postgres is an amazing database. It's basically an application server, as well, with different extensions. And so that's the first departure from being a one-to-one mapping with Firebase, as you correctly point out, the Firebase database is a NoSQL one, and we are bringing a relational database to the mix.

Ben:
Aside from scalability, are there any other reasons you decided to go with SQL instead of NoSQL?

Paul Copplestone:
So scalability actually means a few different things. It can mean just technology, throughput, reads, how fast you can do it, how much data you can throw at it. But it can also mean, for some people that we talked to at the start, it was meaning, well, how do they build their relationships in a database? Now this schema is living in their code. How does it work? So in this regard, having a very strict schema can actually be quite scalable for your programming practices. The tricky thing is that it's a bit harder from the start. So this is really what we're bringing. We're bringing an experience that makes it incredibly easy to use a relational database, just like Firebase makes it incredibly easy to get started. We basically pop up a dashboard. The experience is you come in, you sign up, one minute later you've got a full Postgres database, you can build your database using like an air table like builder, if you want. Or we've got a SQL editor directly inside the dashboard and you start building it from scratch. So later on, when you've got your schema, you're quite set. It's set to scale, even indefinitely.

Ben:
Got it. And what does the API look like for those real time aspects? As a programmer do you subscribe to certain tables, or updates on certain records, or tell me a bit about how you use those real time features?

Paul Copplestone:
Basically, now we're six different tools. We have the Postgres database, we've got another tool called PostgREST, which builds automatic APIs on top of it, and we employ one of the maintainers of that. We have GoTrue, Netlify's GoTrue server for auth. We have our real time server, and we have a Meta-API for managing it. And then an API gateway, basically. Anytime you're doing data fetching, CRUD type operations, go through the PostgREST API. And that actually utilizes Postgres's Row-Level security, so if you're, say a JAMstack developer, you want to deploy to a Netlify or Vercel or something, and then you didn't want to put any middleware in between, it's fine. You can just write your roles directly into the Postgres database. And then anytime you are subscribing, you can subscribe on our database. You can subscribe on a table level or a column level. You specify an equality filter on your column, and then you'll receive data as those changes happen on that column.

Ben:
That makes sense on the database side. How about storage? So that's another aspect Firebase makes it super easy to store assets, or do blob storage. Is it a similar API in Supabase for doing storage?

Paul Copplestone:
We're still quite early. We've been building for less than a year, and we're just building out our storage now. So we're trying to find the right open source tool for this. One that we can support, and we'll build the API around it. So Firebase is... We think of it as four core products, the database, the auth, the storage and the functions, and we're still yet to deliver on the storage and the functions. Storage is coming in Q1 this year, and then functions targeted for Q2.

Ben:
Correct me if I'm wrong, but Firebase is now just a wrapper around Google cloud object storage, right?

Paul Copplestone:
Yeah. So it's quite confusing. They have two different databases. They've got Firebase Realtime and they have Firebase FireStore. And I believe that Realtime originally started as a MongoDB, and possibly still is. Their new FireStore is, yeah, a wrapper around one of their database products. But I couldn't tell you which one, actually.

Ben:
Yep, it's a bit confusing, I know. So for folks who maybe aren't familiar, Firebase was acquired by Google a number of years ago, and now it's somewhat integrated into Google cloud, I guess, but still it has its own dashboard. It's a little confusing what's Firebase, what's Google cloud, what is the same, but it's still a great product. And you mentioned auth... You said that... I missed the name of the tool, but you leverage a tool from Netlify there?

Paul Copplestone:
GoTrue. Yes.

Ben:
Can you tell us a bit more about that?

Paul Copplestone:
Yeah, so we actually had an accidental launch in April last year. What happened was we got into YC, and someone found us before we got into Y Combinator, and put us on Hacker News. At that stage, we were very early on, three months into building, something like that, and we had only really delivered the database and the real-time engine. And everyone inside at their launch was asking for auth, so we spent all of our time during Y Combinator building out this auth solution. So we looked at several different open source tools. We looked at another really good one, ARIS cloud, we're checking out. It was very cool one. We checked out Keycloak as well, but we settled on Netlify as GoTrue server for authentication. And this is the part that lets people in, as sort of a SAML based JWT server. It lets the people in, and then we can use the JWT inside the database to pause it, and build rules around it, and policies around Row-Level access, who's allowed to access what.

Ben:
If I recall correctly, and this is where we're really stretching my memory, when I use Firebase a number of years ago, and built out auth rules, they had a DSL for building auth rules out. It was a little confusing, and a bit difficult when you have a complex database schema. How do you build your auth rules in Supabase?

Paul Copplestone:
Once again, we rely on the database. One of the key things about Supabase, is that wherever possible, we don't stray away from the tool itself. So Postgres is the tool, we're just trying to make Postgres as simple as possible. We're not building any strange proprietary stuff on top. We're just trying to make sure that if you want it, you could either dump your database and bring it into Supabase, or if you wanted, you could dump your database and take it out of Supabase to any other Postgres provider.

Paul Copplestone:
So there's portability, is really key to us. And in that regard, your rules engine is just Postgres Row-Level and security. So you write them a SQL statement, and you can write, basically, any SQL statement you want. And we expose JWTs, the roles of the users, to make it a bit easier, but otherwise, yeah, it's nothing fancy. You can just write it however you want. And a lot of the tooling that we're yet to build is centered around making that incredibly easy for anyone who's never done SQL before, building a learning platform, as well. But building tooling around the migrations, as well, is going to be one of the things that we have to focus a lot of time on.

Ben:
Definitely. And what about at the API level? You mentioned that you use PostgREST to help build some of the crowd APIs without a ton of manual writing of code, but how does the auth work at the API level?

Paul Copplestone:
So PostgREST, I just got to give a shout out, because it's such an incredible tool. We're checking out is PostgREST with a T for those who are confusing it with Postgres, the database, which happens very frequently. But it's a tool which basically... It sort of introspects your schema, so as you update your database, the API itself automatically updates, and then you can query through relations, you can filter, you can join tables, everything through this crowd API. So it's not a basic crowd API. It's probably better than most people could build themselves.

Paul Copplestone:
And then what it does is that it just adds a very thin layer on top. It's actually written in Haskell, and it pauses the JWT, and then it passes it down to the database, and all the key stuff is run inside the database, the queries themselves are built directly inside the database. So it just validates that the JWT is valid. And if it is, then it will let it through to the database level. Then, once you get into the database, we can pull out the headers from within the SQL query, and we have actually just written some nice SQL functions. So you say auth.role to know whether the user is authenticated or not, or auth.uid to get the user's ID, whoever's accessing it, and you can use that inside your rules to determine whether they're allowed access to a set of rows.

Ben:
Makes sense. And moving on the last core tenant here is functions, and often you need application logic, and that's what the functions are for. How do functions work in Supabase? How do they compare to Firebase functions, or any of the huge plethora of server less platforms that are emerging?

Paul Copplestone:
Yeah, so functions, in the traditional sense right now, like cloud functions, we're still building as well. So one of the things... It'll come in Q2. We're trying to figure out which, once again, open source to use, but also likely supporting the existing function ecosystem. So Lambda is definitely one, or cloud functions, themselves, from Google to make sure that people who have written their code can run that code directly. Likely we'll choose another open source tool. Some of the ones that we're checking out now are OpenFaaS, open Functions-as-a-Service, which seems cool. OpenWhisk, as well, seems very cool. Some Knative type applications seem cool, as well. So in the meantime, you can actually produce stored procedures and functions directly inside Postgres itself, which can be written in JavaScript, and Python or SQL. And you can actually run them directly from the libraries, which is great because once again, the execution happens on your database, so you leverage the full benefits of the query optimizer and Postgres's amazing ability to improve execution times.

Ben:
So what does it look like to host a Supabase app? Do you offer a fully hosted platform, or how does that work?

Paul Copplestone:
Exactly. So Firebase is not just a technology, it's an experience. You can sign up, and you're up and running immediately. And this became very apparent to us very early on. People were saying, "Well, it's not Firebase because I have to host everything." So we changed that. The experience is you sign up, you create a project, and one minute later, we'll built everything for you, and we host it for you. And yeah, it literally is a full Postgres database. And so you don't have to think about anything. Right now, as well, because we're in beta, we're completely free. So yeah, it's a very seamless experience. And some of the stuff we're doing is just we're focusing on making it even easier. So we've partnered with a few people. We do one-click deployments, even if you have got a Jamstack type application. One of them is, for example, a deploy with a Vercil button, and you get the front end and the backend completely just by clicking a button. It will populate all the [inaudible 00:13:45], and everything. Builds the schema, builds the front end, and you deploy it. You've got a website on Vercil, and you've got a database hosted was Supabase.

Ben:
And so to circle back, the first pitch you gave is that Supabase is an open source version of Firebase. And I'm curious to understand, why does open source matter to the end user, who just wants to build an app, and have a really easy to use platform? What are the advantages to knowing that the underlying tooling is open source, when something like Firebase is not?

Paul Copplestone:
Yeah, first of all, it would matter if we don't deliver on our promise for scalability. If we didn't do that, then it's up to the user. I mean, they would have to migrate away. And how hard is that? With Firebase, that's extremely hard to migrate away. So a lot of people have been burned. I think if you look at it, there's a lot of love for Firebase, but a lot of people who have been burned when they hit scale, and their product starts suffering because of it. So if we don't deliver on our promise for scalability, we hope that our customers can take the systems that we build, and they can host them themselves, modify them, tweak them. So, that's important.

Paul Copplestone:
The other thing just better support. I mean, we've got a community now that we're building up. We're still very early, but it means that you're not relying on just a company to support you. You've got a community around it. The community, as well, means that there are experienced people, people who have done it before, who can help out. Easier to hire for these people, and that's going to be increasingly important as we increase the number of tools that we offer that... We as a company are quite small, but the community itself is growing and that support is going to be incredibly helpful, not just for people building, but for us as a company.

Ben:
And so in terms of that migration path, in the case where the deployment can't scale on your hosted solution, is that just since it's a Postgres database under the hood, and Postgres is a tried and true platform, you could just move to either some hosted Postgres, or host your own Postgres, and you'd have to move your data, but you're not re architecting or reformatting your data or anything like that?

Paul Copplestone:
Correct. Yeah. pg_dump, pg_restore, or you could even use replication if you're familiar with it, to do a live migration. It's... I mean, a migration from Supabase, of course, wouldn't be seamless. Migrating anywhere is never seamless, but it's a zero lock-in type mentality that we're trying to bring. So everything's portable, including the functions and everything that we do.

Ben:
And so Supabase... Correct me if I'm wrong, you've built a startup around the open source project. What has that been like? You mentioned you were in Y Combinator. What was that experience like? How has it been building a business around this open source project?

Paul Copplestone:
It's tough. I mean, there's a lot of work, for starters. Just building, first of all, an ambitious project like a Firebase alternative is not like building a product and open sourcing it. It's trying to support many different things, and many different user preferences. Some people want different things at different times. So, that's the tricky thing. We've been incredibly fortunate that the tools that we support, the communities are also very open to the support, and helping us in how we're trying to help their community, essentially, get started with their tools. So, that's been good.

Paul Copplestone:
Mostly our team is just focused on shipping, and then we shout once a month. Our strategy is basically built for a month. At the end of the month, we just shout about what we've built, and then get back to building again. We just know that we've got a lot to build, so we haven't been overly focused on trying to do sales, or marketing or anything like that. We really are just in build mode. That's because, yeah, we're still early on. We're less than a year of building our platform. So, we've got a long way to go.

Ben:
I'm curious, there was this bit of news recently where Elastic came out and changed their license. For those maybe not familiar, elastic is classic search. It's a database that was previously under a permissive open source license, and rolled back a bit, and put some restrictions on the license just to avoid having Amazon and Google offer a hosted product and not contribute downstream updates. So how do you see those developments? And I feel like everyone building open source infrastructure is a bit worried about Amazon, and Google, and Microsoft being able to just take something open source and host it, and hurt everyone's margins. So, how do you see long-term that affecting your strategy?

Paul Copplestone:
Yeah. Well, this is probably one of the most difficult things about open source. I mean, I'm an avid hack and use [inaudible 00:18:09], even if you look through the comments on each side of each of the blog posts, you've got all sorts of varied opinions, right? Well, Amazon aren't doing anything wrong. It's open source. That's the way it should go. And then you've got the other side, well Amazon should definitely be contributing more. They're making so much money off it. So there's no sort of right way of doing open source, in the eyes that will be beneficial for the whole world. So largely what we're focused on is just delivering an amazing experience. First and foremost, we need to make sure that it's useful to people, and if it's not, it doesn't matter. Then the open source aspect of it, I'm sure that at some stage, we'll have either problems with cloud, or problems with the pureness. There's bound to be problems on either side, but at the end of the day, as long as we're delivering a valuable tool for people, that's what really matters, right?

Paul Copplestone:
So at the moment, I feel like we're doing that. And definitely, I feel like we could be more pure in our open source approach, and we'll have to figure out a way to be pure like that, but also protect ourselves from getting consumed by one of these big players. But largely, I think it's okay because Supabase is, as well, like I said about Firebase, it's an experience. You come in, you get something very seamless. That experience is not being delivered by any cloud, I don't feel. Not in the way that we are delivering it. So for them to take our technology is fine, because the technology belongs to everyone anyhow. But to take the experience will be very difficult. They would have to re-engineer a lot of what they've already done.

Ben:
That's a really interesting way to look at it, because you look at some of these companies like Twilio or Stripe that have built incredible companies where great developer experience is one of their core tenants. So, that makes a lot of sense that that could be a very durable moat. Do you have any thoughts in the future around considering an open core model where you start to add closed, or features that you pay for on top of the core open source for any of the ancillary parts of the application stack?

Paul Copplestone:
Yeah. The only thing that actually is closed this way... As I say, we could be more pure. The only thing that's closed right now is our dashboard, where you can see everything. Largely because we would have to engineer our own... The security stuff, split it out. People's database are extremely sensitive, and we want to make sure that we're complying to all the laws and everything that needs to happen. So at the moment, that part is closed. I'm more concerned with, can we open up more rather than close it out? I don't think there'll be any core closed off, especially because we're building on existing tools, and those tools are all open themselves.

Paul Copplestone:
They're either MIT, Apache2 or Postgres licensed. And so we want to maintain that ethos as well within our company, and make sure that we're supporting those communities basically. And it'd be unfair, I think, in the way that it would be unfair for AWS to come and take our technology. It'd be unfair for us to take their technology, and somehow build a walled garden around it.

Kate:
So we talked about Hacker News a little bit. That was really where I first saw Supabase was on Hacker News. Having that publicity early, and then also getting a lot of love on Twitter. What is it like to build a community so early with your product?

Paul Copplestone:
It was very frightening at the start. As I say, we had been building for three months when we got posted on Hacker News by another person, and quite honestly we went from 80 developers that signed up and we're kicking the tires to, I think, over a thousand signups. And these are literally... We spin up databases for these people, so it's not just a frightening in terms of, we're still finding our feet, but frightening in terms of the bill that we're footing for a lot of people. So that was quite surprising. And actually, in that process, we had credits with a cloud provider, and they ran out rapidly. We had all sorts of cloud limits, domain limits, all sorts of things were on fire. And we ended up having to migrate 800 databases in a week.

Paul Copplestone:
Otherwise, the community have been amazing. It's been one of these things where we've got people jumping in, building the client libraries for us, giving feedback for us. Very lenient because we only actually moved out of alpha into beta about a month ago. So we're still getting amazing feedback, and a lot of patience, and a lot of excitement, obviously, around just the platform itself. So yeah, Twitter, as well, as you pointed out, has been a really surprising channel. I didn't expect it. We were largely focused on just posting what we had built onto hack and use and Reddit, but Twitter seems to be where a lot of the JAMstack crowd, especially, are finding us, and coming in, kicking the tires, checking us out. So yeah, all of these are quite new to me, especially as an engineer. I'm more focused on building each month, but yeah, it's very cool. I've got to say the community has been amazing.

Kate:
Yeah, no, that's awesome. The power of Hacker News is just incredible.

Paul Copplestone:
It's crazy.

Ben:
Yeah, LogRocket launched on Hacker News, too, and that was the majority of our earliest customers were from the initial Hacker News launch. So, it's a pretty incredible community.

Paul Copplestone:
Yeah. And the right sort of crowd as well, because I mean, like I said, when we first launched, we didn't have auth, and then people were holding us to the right standard. It wasn't that we could just ship some auth solution. They wanted a good auth solution, so we made sure that it worked with Postgres Row-Level security, and then when we came back and we did a launch for our auth, the credibility was there. People remembered, "Oh, I was asking for Row-Level security and you delivered it. Thank you very much." So, it's a nice crowd. They're not just there to troll you or anything. They're there for good technical solutions. Yeah, occasionally pitch forks, but I got to say, very well moderated. Dan does an amazing job to keep the community spirit very tolerant and... Yeah, it's such a great crowd.

Kate:
Speaking of Twitter. So there was a tweet by Guillermo Grouch about some sort of collaboration that's happening. Can you speak to that at all?

Paul Copplestone:
I can say some things. Basically, there's a Vercel, Stripe, Supabase collab coming up where of course, just trying to clear it and make sure that it's ready to launch and get everything prepared. But yeah, we are hoping to make it incredibly, incredibly easy to get up and start building a SaaS company. So I mean, less than a minute to deploy everything, and have all your roles up and running. So I don't know when this podcast is coming out, but it might even come out before that. But yeah, I'm sure if you follow any of our Twitters, or any of our blogs, I'm sure you'll see it come out, and we'll shout about that as we do on the usual channels.

Ben:
So the database in Supabase sounds like the most mature aspect of the technology. And then you said that storage and functions are coming soon. So what does the timeline look like? If I'm thinking about potentially using Supabase for a production application, what is the timeline? And you don't need to get exact dates, but just how should I be thinking about what is usable now, versus what do I need to wait? And when some of those things will come out.

Paul Copplestone:
Yeah. So, we're officially in beta now, but to be honest, there are plenty of people using us in production. So actually, the database, the auth, the CRUD, the API is completely stable. We're very happy with them. Q1 will be storage. Q2 will be functions. Otherwise, probably after that, we'll move from beta to full release 1.0. So yeah, we're really ready to go.

Ben:
And what is the back half of 2021 look like once storage and functions launch?

Paul Copplestone:
Yeah. There's some exciting things. Actually, even in Q1, there's some exciting things. We've got this thing that we're planning launch week where we're going to try launch one thing every day for a week. And we've got quite a few exciting things coming. After that, a lot of it will just be around stability, adding a lot of items to our existing feature sets. So for example, more auth providers, more enterprise grade security audits, things that are important as you start scaling, but probably less people are asking for right now, and they will be asking for it in the future.

Ben:
And outside of Supabase, what has you most excited about the world of application engineering?

Paul Copplestone:
So definitely there's a lot of new frameworks coming out, which I think are very cool. I'm not too dogmatic around frameworks, and which one is the best, or anything like that, I just love trying try new ones. I do think, regardless of which framework, the concept of branch deploys becoming a lot more mainstream, and especially for us, I mean, the thing that I think about is how does this work with databases? How's it work with base migrations, things like that? So, it's more a engineering workflow, I see, where you can quickly preview all your deployments on one branch, make sure that they're valid, and then merge them in and have this seamless productivity suite works together from end to end. And yeah, it definitely is something that makes us more productive as a team. So I think that's pretty cool. Actually, a good question to ask you guys, what do you guys see as some of the most exciting things?

Ben:
Yeah, I mean... Definitely very interesting to see how Vercil, Netlify, I mean the whole JAMstack phenomenon. And not necessarily front end, but low code, no code app building in general, and Airtable and Java script becoming this tool where... The fact that you can now build simple JavaScript on top of Airtable, and a lot of these low code, no code are something I'm really excited about. Just democratizing the ability to build apps for business functions and stuff. I think that's super interesting, and obviously a little bit different than being able to truly build an application from scratch with great tooling like you're building, but the fact that we're moving towards a world where almost anyone can build a simple piece of software just to help automate their job. It's cool.

Paul Copplestone:
Yeah. That's very cool. Very cool.

Kate:
Yeah. I'm not a developer, but I read a lot of technical stuff working on the blog and stuff, but we've also done a lot of interviews with Redwood and stuff that's easy setup, and going back somewhere Angular, that cycle. It's nineties fashion. It comes back. You see it again, you see it again.

Paul Copplestone:
Yeah, yeah. Exactly.

Ben:
A cynical person might say, "Oh well, Rails and Django figured this out 20 years ago," but it's not... There's a lot of cool things that are being done that echo some of the early MVC frameworks, but with the modern technologies that really help with developer productivity. So I think there's some interesting stuff there.

Paul Copplestone:
Yeah, definitely. Especially this productivity one it seems to be accelerating. I mean, as you say, low code, no code, it just means that people are more focused... While engineers are more focused on the hard tasks rather than the basic thing. So if you look back 10 years ago, 15 years ago, maybe developers were very focused on building HTML website, and then WeWorks came along and sort of obliterated that. You don't need to worry about that. You start building applications, and now applications will probably be built by sort of low code, no code people and the engineers can focus on maybe even the harder nitty-gritty stuff. I mean, whether it's getting into machine learning or very low code over the next 10 years, this is probably where people are going to focus. So it's just freeing up time, which is awesome.

Ben:
For sure. Yeah. In 10 years, they'll just be like AGI writing all the applications.

Paul Copplestone:
Yeah. Yeah. Humans doing nothing. Who knows. Well, even some of the stuff like... For example, because we've got the schema and SQL was quite hard, checking out open API, whether we could just throw your whole database schema, and then it could help you use it to ask a question, like Google. You would say, "Oh, what are all the top users in my system," and then it will generate this SQL directly. So these are the things that probably can free up engineer's time, so they don't have to send think, "Here's the query for finding your top users in your database and handing it off to your people." So, it's quite possible. I think it's not here yet. It's still probably quite a few years down the track, but definitely heading in that direction.

Ben:
Thank you. This is great. I really enjoyed learning about Supabase. I'm going to be very excited to check out the Vercil, Stripe, Supabase collab. I mean, it sounds very interesting. So we'll look forward to seeing that, and best of luck as you continue to build the company.

Paul Copplestone:
Thank you guys for the time, and thanks for having me on the podcast.

Brian:
Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought. And so I want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them, and don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So if you'd like to suggest a topic, or volunteer to be on PodRocket, we'd like to hear from you. So you can do that by going to podrocket.logrocker.com/contact -us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.