Ep. #71, Open Source Firebase Alternative with Paul Copplestone of Supabase

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Paul Copplestone aka Copple coming in from Singapore.

Copple how you doing?

Paul Copplestone: Hey Bdougie.

I'm doing good. Thanks.

Brian: Excellent. So we've chatted a couple of times and I invited you on podcasts cause you've never been on the podcast before and you just launched a really cool new version of the thing you're working on.

So do you want to intro yourself and tell us why you're here?

Paul: Sure, sure. Yeah. So I'm the CEO of Supabase and Supabase is an open-source Firebase alternative.

So basically we're building the features of Firebase but we're using open-source tools.

Brian: Excellent. So why Firebase?

So you have like a, a love for just the structure of the platform?

I mean, I'm a big fan of Firebase and I think most people if you've probably heard the first 20 episodes which you can find them on Heavybit's website, I think someone actually reached out to me asking where the first 20 episodes were--

You know I've used Firebase for a lot of different projects so I'm excited, but I'm curious why build another Firebase?

Paul: Yeah. This for good reason, right?

I mean, a Firebase is kind of an amazing tool that when you start using it gives you basically everything you need out of the box yeah.

Are really a great tool for especially building prototyping very early on getting started.

The problem that we really wanted to solve or I personally wanted to solve was later on when you start scaling.

So the origin story of Supabase is that we were using Firebase in my previous startup and we hit some scaling problems and we had to switch to a Postgres database.

And in that process I wrote a real time engine on top of Postgres. And that was to implement a chat feature inside our startup.

Then I open-sourced that real-time engine. And from there things kind of evolved.

We ended up building a few more features and then we decided at the start of 2020, that would make a proper business.

My co-founder and I, and we sort of adopted the tagline and adopted the target to build this open source version of Firebase.

But with the key feature that it's as easy to use at the start, but you can scale it indefinitely.

So that means we've made a bunch of decisions around the technologies that we use to make sure that they're sort of enterprise grade.

They're very robust they're very scalable, and making sure that even if you start something and you build it in a weekend it can just scale to millions of users.

Brian: Yeah. And that's super enticing too, as well.

And I'm curious to briefly touch on the scalability issues that you had with your startup as well.

Cause like I'm familiar with Firebase, I've been using it since the start and end of me doing mobile development.

I don't do anymore mobile development, but yeah it's been at least five years since I first did my first Firebase app but I'd never got to the point where I hit a scaling issue.

I think we're really, I just sort of fell off to stop shipping code to a project that was not going anywhere.

So like what was the sort of the, the limit of that and sort of how is Supabase solving that scaling if we want to get a more detailed?

Paul: Yeah, sure. Actually we chatted to a lot of developers at the start of last year and that means different things to different people with scalability issues.

For me in particular, in my startup, we had one very peculiar bug where you can query one document per second.

Basically you can query in cloud store a document one query per second. And does that make sense?

Brian: Yeah, yeah.

Paul: And the way we had structured our data was that we're dumping everything into a document and using that for the real-time streams.

And of course people are sending chat messages more than once per second.

So there was a little bit of a lag between when you are sending messages but scalability for other people is different things.

You can actually have limits of throughput. Maybe some people were hitting limits around, maybe they're getting 3000 reads per second or a thousand writes per second. There could be limits around scaling their code base because there's a no-sequel store. They find that their schema starts living inside their database. It's hard to build relationships between the documents.

It could be a limits around just missing functionality for example, doing counts rather than querying all your documents, counting how many all the particular type of document there are, is a limit.

So it's all sorts of limits that we're aware of.

And we just want to mitigate them from the very start.

And so the way we've done that actually is by choosing different technology.

So we're a Firebase replacement in spirit but not in compatibility.

So we don't use a no-sequel store. We actually use Postgres, one of the sort of most trusted and scalable databases and open source database that there is on the market.

And we basically choose tools for each of the features that we know can hit scale.

We do a performance tests on them. We make sure that they're easy to use like Firebase and that they can scale up to basically enterprise grade.

Brian: Excellent. Yeah. I mean, I've been using Postgres databases since the beginning of my career as a developer.

So I understand the tooling pretty well cause I've just had to use it in my day job. And I think the excitement of the no-sequel space is that it with everything was new, but it doesn't come with a lot of that sort of existing experience in the tooling.

So I definitely understand the reasoning for that as well.

So yeah, I'm interested in kind of bound testing it with some projects that I have coming up in the next couple of months.

So more than that in the future folks, definitely.

If you aren't subscribing to this podcast subscribe to the podcast and you'll hear more about that, in future podcasts, but I'm curious about the story.

You had mentioned your co-founder.

Did he also come from that same startup or did you know each other from other places?

Paul: No, we actually knew each other from about three or four years ago.

We both moved to Singapore for a program called entrepreneur first.

Which is this accelerator where they throw a bunch of people in a room, a hundred people in a room together.

And you basically know nobody and you have to form a company together, usually a deep tech company.

So we spent three months on this accelerator. We got to know each other there.

We didn't do a company together but we ended up living together for a year.

And when I decided that I wanted to do Supabase I kind of sat him down at a cafe one day and I pitched him the idea, he decided to join and yeah that's the origin.

Brian: Wow. That's excellent. And speaking of origin like you're now in Singapore today too as well.

So are you just in love with the country or like what still are of Singapore today?

Paul: Yeah. So I've been in Southeast Asia for, I think six years now.

I actually moved over to Kuala Lumpur for my first startup and then moved to Singapore for that program.

I think, I mean, it's a great place to live.

It's very easy, very convenient but our company is fully remote.

So it doesn't matter where people live.

We've got people in Peru, the U.S, Canada and Europe.

You can really be anywhere. I actually just got back from France. I was working there during Christmas.

So yeah, our team's really spread out and so we're not really headquartered in Singapore but for me, I quite like it.

The weather is great, the taxanes quite good and it's quite cheap and convenient to live in.

Brian: Excellent. Yeah. I mean, for the context of folks listening, if you listen to this down the road, we are at the beginning of 2021.

So you spent your entire year working on Supabase which when I first heard of it was an alpha and it was sort of just, people were sort of just getting excited about it actually heard it from Thor a contact friend that we know.

And I, that was my first introduction to Supabase.

And from there, I was just, I was hooked to that sort of open-source Firebase piece of it.

Paul: It's funny actually. So Thor works at Stripe is a developer Africa.

And one of his colleagues is my COO of my first startup.

So that's how we knew each other. And I actually was in Stripe just chatting to this guy, John, about what we're doing getting ideas and they invited Thor over.

And at the time we kind of had an adopted the idea of open source Firebase.

It was just Postgres making it very easy to use.

Then we started building and we did a launch on Hacker News about April when we got into Y Combinator.

And after that I was meeting John again for coffee and that's where I actually showed Thor a demo of what we're building.

And it was this one click deploy of a Slack clone where you can get a real time chat app up and running just by sort of clicking a button and deploy it out.

And from that moment on, yeah, he's been amazing.

Thor has been just promoting us and building on top of Supabase, helping us out was yeah.

A bunch of our open source libraries. So yeah, it's been great.

Brian: Yeah. Yeah. And Thor I partnered with a event that we had towards the end of the year, close to the GitHub universe which was the floss and code hackathon.

It was a thing we did. I've done previously for our ERG, the black, the cats.

I GitHub focus around teaching open source to underrepresented folks in tech.

So competent engineers is not doing open source.

And Thor helped involve Stripe and Supabase and Vercel Fleece invited vercel to come and help too as well.

And we have this one-click deployment for a Stripe integration.

That's powered by Supabase and doing authentication and all those wonderful bells and whistles too as well which was pretty timely because you just announced your beta within weeks of that event as well.

So I mentioned, I learned a bit in the alpha. Do you want to talk about what the difference between now that you're in beta?

Like what features we have for Supabase?

Paul: Yeah, so right now the features of Supabase are basically the database which is a Postgres database.

We've got auth baked in. So we use actually never face go true server which I know you're very familiar with.

Brian: Yes.

Paul: For authentication. And then we use for authorization.

Postgres has row level security and we wrap all of this with client libraries and an interface that's very easy to use the, this kind of got a table interface quite similar to air table built on top of Postgres.

And then we use a tool called PostgreSQL.

In fact, we employ one of the maintainers of Postgres and that builds instant APIs on top of your Postgres database.

So you focus on building your schema and then you do nothing for the API.

It just automatically works out of the box.

As you add a table or as you add a column the API self updates and the documentation inside your dashboard updates as well.

Brian: Yeah. That is amazing too, as well.

And a couple of weeks ago, I started working on this project and then we talked about off before we hit start on the podcast, but I'm building these sort of database to help with open source contributors find open source contributions and projects.

So I basically started a Supabase database on stream. It didn't really get too far.

I got the database working but then I was sort of reading documentation and chatting.

It was one of my first drains back. It was post-holiday.

So I was sort of really distracted. I'm looking forward to get back to actually shipping that.

But what I'm getting at is the ease of me just getting started.

It's very familiar and sort of the Firebase experience where I can just sort of start typing records and create tables and relationships between the two.

And then what's great about is the API is actually pulling that data inside of my react app, which I'm a big react fan and similar to all the STKs for Firebase.

So yeah, I really appreciate this having that sort of like out of the box experience and I didn't know about the API thing of actually building APIs on top of the database.

Cause I didn't get that far for obvious reasons.

Paul: Yeah. I mean, the beauty of what we're offering is that if you want, you actually can do a full serverless setup.

I know this is particularly targeted at JAMstack so you actually don't need any middleware. If you use row level security then you can query directly into the Postgres database and it'll use the JWT to authenticate and then to verify that the user has access. So you can write these policies directly inside our dashboard to authorize whether a user can access certain rows or not. And these are forms, sequel queries. So they can be very powerful.

I've seen people build social networks was just these policies.

So yeah, they can really be quite powerful and it's worth noting that the database that we offer when you spin up a project is a full Postgres database, it's not a schema within a database, it's literally a form database.

So you can connect in you can use database migration scripts anything that you want and connect into your database directly.

You don't have to use our dashboard but that's the aim that we start you off, as you say very easily within the dashboard and then we'll offer some tooling later on around working on your local machine.

Brian: So I'm curious about the tooling too as well.

Like I know a tool like Prisma, Prisma too being out for over a year now at this point, the Supabase do they integrate with things like Prisma and other tools in the ecosystem?

Paul: Yeah. So for any tool that wants to integrate with Supabase, then yes, it's basically the question is, does any tool integrate with Postgres?

Because as soon as you can integrate with Postgres then it works with ours.

All you need to do is update the schema and we'll try to work as natively as possible with the Postgres database.

We don't do anything fancy on top. There are a couple of things that we do for our auth.

For example, we put an auth schemer inside it and we try to keep your database clean by adding an extension schema where you install your extensions.

But otherwise it's really just a native Postgres database.

You could literally dump your Postgres database today and restore it inside Supabase.

And it will sort of just work as the idea.

Brian: Okay. That's excellent. I had an application that I worked in, it's an internal app.

I GitHub mainly for only employees. So no details is needed about it, but the point is that we decided to sunset it.

Cause we ended up moving on to support it in different ways.

So I actually exported the database and had nowhere to put it. It was basically a rails app.

The project basically died. So like there's no really need to migrate it to Supabase or anything else like that.

But it was my first time ever even trying to attempt to migrate a Postgres database, which to me was like very interesting, but also slightly scary.

So it sounds like if I choose a tool like Supabase I can get a lot of those features for free.

Just sort of pointing my database to it.

Paul: Yes. Yes. Well, that's the thing, I mean the very long-term future is of Supabase is that we know that databases are sort of this unsolved problem for a lot of engineers.

I mean, people know about migrations but they don't know what is the canonical best way to do it.

People might be trying to migrate large databases maybe trying to fork.

How do you do it with preview deploys? How do you manage the database with lots of different users developers developing on top of it?

So we basically want to solve all these lower level problems that you know, people just don't have to think about at this stage or don't want to think about and we'll solve them for people who aren't so experienced with databases in particular.

So if you're a front end engineer then we should bring the easiness of front end to Postgres itself.

Brian: Yeah. And that's what I love about the JAMstack.

Cause I don't have to be an expert at specific layers of the stack. Like I can get real deep on whatever I want to.

But as you mentioned, database is something that I just did not spend a lot of time to like my background I mentioned rails is where all my post-crisis experience comes from.

So I have active records, which is why my question was geared towards Prisma, which provides me that layer of abstraction that I don't have to worry about.

And then all day there, rail shams extensions that exist.

I'm just sort of this trusting the rails community to help me along the way when it comes to database interactions.

But it sounds like folks who maybe are shy on touching this part of the stack, the backend of the database portion of it, they can actually approach super base with confidence and even maybe learn something coming out of it. It sounds like

Paul: Definitely. And we kind of want to give this I guess you could say like a rails like experience where it's we start you off giving you best practices but you can get off the rails very easily.

I mean, you've already got Postgres level access to your database, so you can hook in directly and you can start doing whatever you would do with a normal Postgres database.

So that's the goal.

Brian: Yeah. And you said the serverless aspect of it.

So when you said you could take it in hosted elsewhere are you saying that I can host my database and like AWS and whatever their hosting provider is?

I don't know if it's, I think serverless like Lambda but I'm not sure if there's another thing I'm missing.

Paul: No. So the serverless aspect is that essentially we are your server. We are your database provider.

Brian: Okay. Got it.

Paul: But to touch on another underlying question and probably one that most people are thinking about do we work with existing databases?

So would you connect us to say an RDS instance or an Aurora instance at this stage it's no, because we're still in beta and we're just focused on building on top of our own Postgres offering which is literally just Postgres with some extensions installed and all the right permissions for replication.

So yeah, at this stage we are a hosted service but at some stage we will actually give the ability to yeah bring your own database and we'll just connect in and you get the interface, you get the APIs and we'll connect in and give you everything.

The reason why we don't at that stage is because it's easier to build on something that we fully control especially the real time aspect.

So our real-time engine actually uses the Postgres replication stream to detect changes to tables.

And a lot of the providers actually don't give the right level of access for replication that we need.

So we'd have to turn that off for most people and it's just a bit harder to support.

So once we've built out a good feature set then we'll start working on how we can turn things on and off for different providers.

Brian: And I'm curious about the EBIT to the replication and the real-time aspect of it.

Are you leveraging open source tools to parents?

Are there familiar names that people are familiar?

Like I might not be familiar with them but maybe someone listening is.

Paul: Yeah. So we basically an amalgamation of six tunes right now, Supabase.

So yeah, it's a bit complicated obviously on the bottom if I go bottom up you've got Postgres QL the database then coming up a layer for the APIs is Postgres which is the automatic APIs that I was talking about.

Then for the real-time aspect we've actually built a real time Alexa engine ourselves this is the one that we opened source at this time is called real-time Supabase real time.

And that is the one that decodes the logical stream and blasted out over WebSocket.

So you can connect to it from a client or a browser.

Then we use Netlify go true for auth. And then finally we use an API gateway called Kong which is great.

And we plan to provide some support around turning on and off plugins and the dashboard for the API level.

Brian: Yeah. I'm familiar with Kong actually. And familiar actually all the things you named.

So I'm like, I'm impressed with myself to be quite honest but yeah, that, that's interesting.

And then I'm curious the future of Supabase in the roadmap but also one thing that comes to mind too as well as like post-GRAD file, which is graph QL on top of Postgres as a tool I've always wanted to leverage but I'd never really had a database that's been in Postgres long enough to even attempt to do something like that.

So if I wanted to bring in like an extension that you are already supporting, can I leverage that natively without exporting my server base somewhere else?

Paul: Yeah. So GRAD file is pretty cool actually for those listening GRAD file is basically like Postgres and it automatically detects your schema.

So, and it booms automatic GraphQL engine on top of your Postgres schema.

So it was sort of like the GraphQL version of Postgres we ourselves don't plan to offer it.

But if you wanted to you could just connect it into our database.

Since we give you Postgres level access, you just need to install it point to add your Supabase database and you've got GRAD file up and running.

So it's very cool. The reason why we won't support it at this stage is because Postgres itself actually offers sort of nested queries.

You can query into foreign relationships automatically.

And we provide libraries that make it very simple to do this.

There's a lot of overlap at this stage and we don't see the need for offering both.

Brian: Yeah. And would you say Postgres level access?

Is that me actually typing PSQL in my terminal pointing it to my Postgres database.

That's hosted with Supabase said adding the extensions that way?

Paul: Correct. Yep.

Brian: Okay. And this is part of the thing where you can get off the rails, right? Yeah got it.

Paul: So people routinely break it their database with us but we don't care.

I mean, this is, we want to give you full access. You shouldn't think of this as just a toy.

This is something that you can use. You can debug yourself.

You can literally, we give you a sequel editor inside the dashboard itself.

So you can g et down to SQL level when query you can connect in with your favorite tool.

I use DB or table plus whatever you want to use.

You can actually start interfacing with your database using whatever tools you're familiar with.

Brian: Wow. I'm impressed. And I'm looking forward to getting more confidence.

Yeah. And it's funny, you bring it up. This is not a toy. And I appreciate you bringing that up too as well.

Cause like when I approached this like I want to build a toy app, but also if the app takes off where people actually leverage it I do want to take it seriously.

Eventually. That's just how I've approached my careers.

I'd sort of play around with things and see if they stick and then, then I'll run with that.

If people actually want to pay me money for it, which sadly, no one's done that yet. So hopefully this is the year.

Paul: Perfect. Yeah. Well, I hope for the success of your app, but yeah that's really what we're trying to make sure that we provide.

If anyone does have a successful app that they've sort of built over the weekend is just a prototype.

They get hit with Hacker News.

Actually there was one, two days ago that sort of showed up on the front page of Hacker News it as just a show how can use called Paint.wtf where you can sort of paint a picture and then your, it would have an AI analyze whether the picture was correct.

It would give these absurd things like draw an upside down dinosaur and then the AI would analyze the effectiveness of your drawing.

And then it would rank you globally.

And someone had built this using Supabase.

And at the end, they'd got onto the front page of Hacker News.

And I think they were getting around two queries per second averaged over six hours, but peaking at around 2000 queries per minute, something like that.

So it's one of these ones where, you know, if you built it with something that it's a toy, you know, you built it on top of, I don't want to name any other tools but it is something that can't handle these sort of scales or more yeah, yeah.

It goes down and you've lost all that traffic.

Brian: Yeah. Yeah, no, that is unfortunate.

And I think this kind of the hard way most people sort of figure out how to solve scaling issues is by getting on the front page of Hacker News.

Paul: Yeah. Exactly. Yeah.

In fact, there was our first real test. We, when we were in alpha we've been building for three months and we got onto the front page of Hacker News. I think we stayed there for about two days and everything was blowing up. But the main thing that was blowing up was our cloud limits. The actual stack that we were using survived fine.

And at that stage, because we only had, I think 50 users but it was sort of an open alpha where you could sign up.

And then we had only 50 people.

We were hosting everything on just a Docker compose app on a literally just, you know SSH into a server Docker, compose app.

And then it would have the six tools running on this machine.

But for those two days, it handled all the traffic just using that stack and Docker compose.

So we know it's good, scalable even when you're sort of misusing it.

So yeah, we're working on making sure that we can scale even beyond to very scalable circumstances.

Brian: Yeah. That's amazing.

And speaking of scale, I'm curious, I do want to talk about the future who we're based what you have planned for the rest of the year but also curious about pricing too as well.

So like when I--

One thing that I'm scared of, when I do touch databases or touch part of the stack that I know once I get more than 10 users, whatever it is I'll have to start paying money.

Which is part of the reason why I haven't built this thing I mentioned which is D is to the recommendation engine for open source i s because I already have 200 users on my main project.

So 200 users on a Heroku Postgres is automatically already going to be paying money right out the gate on a side project.

So that's one thing that I'm concerned. So I'm curious, what do you have in store for pricing and then what you have for in store for the future of this year and the roadmap for Supabase?

Paul: Yeah. So pricing, yeah.

For those listening we're currently free we'll bring up pricing very soon.

Still working out the details, but it's likely that there'll be sort of two tiers, one extremely low price but with sort of a very generous time period for free apps I think a year won't give free.

If you're just dappling, while if you sign up while we're in beta, you'll get a year of usage and then it'll be a very low price.

I won't put a number out because we haven't finalized the price.

Brian: Yeah that's fair.

Paul: And then sort of a medium tier where you go up in size.

But the key is that, you know, we know a lot of people get boom shock with Firebase where you're priced on the number of API calls but we'll probably do as just as some soft limits around how much space you're using in your database, rather than the number of queries for non enterprise customers.

So will be something like two gig of storage for the base tier.

And then it'll go up to 10 gig for the next tier, but there's soft limits.

So if you blow over them accidentally then it doesn't matter.

We'll just reach out to you to move up into the next tier. So yeah, we should be mitigating while we're in beta.

Any concerns around a bill shock it'll be very cheap and competitive with Firebase.

Brian: Excellent.

Paul: For features actually. Yeah, it's quite exciting this year.

We've just started planning out what we can release.

And of course, Firebase has a lot of features that we need to build at the moment.

We've got sort of the datastore and the APIs and the client libraries but they also have the big two storage and functions, cloud functions.

And these are the ones that people are most readily asking for.

So this year in Q1, we're going to do actually something called launch week at the end of Q1 where we basically launch one thing every day.

And the key headline I can tell you right now is going to be storage where um, in the process of building storage now.

So yeah, look out for that. And then we'll launch something else each and every day for that week.

Brian: Okay, excellent. I'm looking forward to that.

I will be marking my calendar and folks definitely follow Copple. You are KiwiCopple on Twitter

Paul: Yep

Brian: and Supabase I believe you have. Do you have a Supabase on Twitter as well?

Paul: Yeah, we do Supabase_IO.

Brian: Okay, excellent. Perfect. Yeah. Anything else that maybe we didn't cover that you want to mention?

Paul: No, I think that's been, yeah, pretty good. Thanks a lot for all the questions.

Brian: Yeah. And speed of questions were actually moved out of questions and it depicts, these are jam picks things that you're jamming on.

It could be food, music, movie related. I definitely appreciate the conversation we had about Supabase.

I'm actually super excited to actually work on this project that I've been talking about.

I've actually been talking about this project for too long.

So definitely folks follow me everywhere on the internet.

So I can talk about this, but if you don't mind I'll go first with my picks.

My first pick is Instagram which is kind of what, it's a weird pick.

I just kind of sucked a lot of time in Instagram in the last couple of weeks, for whatever reason the news has been really weird in the last couple of months.

So I just kind of been sucking my time into just scrolling through Instagram because people seem to be happy and I just want to see something happy.

Paul: Well, so what are you doing? Because you're in lockdown, right?

You're posting a bunch of what sort of stuff. What's your thing on Instagram?

Brian: Yeah so I used to use Instagram whenever I traveled.

I used to do a lot traveling.

I was actually supposed to be in Singapore earlier last year and usually to take pictures and do photos and food.

But 2020, I just kind of stopped doing that because taking photos and pictures of food of like my local coffee shop this is not as interesting to me.

I wanted to show which I probably in hindsight, I probably still could have did that same coffee every day cause my coffee shop has been open the entire time.

They just happened to have a nice walkup window which has been COVID friendly.

Paul: Cool.

Brian: But that's besides the fact now I'm really into food still into food.

I've been making a lot of food and I'm getting a lot of recipes on Instagram.

I know this has been a thing that's been on Facebook but I haven't used Facebook regularly for years.

So I think a lot of people, while Facebook has figured Instagram has been their sort of lost leader.

And they've been basically gaining adoption through Instagram, but losing adoption through Facebook.

We don't have to go back and forth on that people you can at me and mention me somewhere else.

But what I'm getting at is actually I have a lot of furniture I look at an Instagram.

I watch a lot of reels of people dancing for some reason. I have tech talks on Instagram.

Paul: Okay.

Brian: But yeah. And then I, shout out to Korean Dad.

Korean dad is actually he's based in San Francisco.

He's actually the owner of the coffee shop that was inside of GitHub when we had the office open, like the guy blew up on Tik Tok and he's also blew up on Instagram and Twitter and I've just been following him because this guy is hilarious.

And he says, basically a Korean dad.

That is a super nice, super positive has nothing negative to say.

And I love his persona. I hope that's his real persona.

I hope he's like super nice in real life as well because I have not met him before in real life.

I just knew of him. Yeah.

So check out Korean dad leverage Instagram.

If you're cool with that I know some people have a weird security limitations in what they can use or what they want to use.

So definitely use that your own,

Paul: At your own peril.

Brian: Yes at your peril.

Paul: And what's your Instagram handle so everyone can find you.

Brian: I'm BDougieYo. Yeah, it's the same as Twitter.

Paul: Okay.

Brian: It's as funny as that I've never promoted my Instagram ever cause I just, its just for me.

It is a public Instagram but I just always did my own stories.

And if you knew I was there, you would follow me.

So I only have like 200 people who follow me.

So hit me up on Instagram.

I'm going to start doing some food related stories and pictures because you know, I'm at home, which is one last pick which I'll mention, which is Joshua Weissman, who's a YouTuber.

He used to be a professional chef in Austin, Texas.

And he's been doing these things where during quarantine he's been doing, he'll find like a fast food restaurant or a popular item like at Popeye's or whatever and he'll make it from scratch at home.

So he did Cinnabon, which I don't know they had Cinnabon down in Asia.

But if you know the cinnamon rolls I know they're probably called something else out there but cinnamon rolls, Cinnabon, they're super bad for you.

You get them at the mall. It's like quintessential American treat.

And he made one of those and like shared the recipe.

And over the holidays I made the same thing, used the same everything that he did.

And they were amazing.

I had cinnamon rolls, Cinnabon cinnamon rolls at home Christmas morning for the entire family, which you know, brush a little off my shoulder because yeah that I was pretty good, but yeah he's a whiz and he just breaks everything down for you and it makes it approachable for you to do.

Paul: Yeah. Okay. Very cool. And it's cool that you mentioned sort of the positive aspects of social media.

I actually, you know, I have most of the tools but I actually don't use any of them.

They make it very hard to code if I spend too much time on social media, but you know you hear a lot of negative stuff about social media.

It's always nice to hear people talking about the positive aspects that you know, you can find.

And I think if you cultivate it spend some time cultivating the right audience there are very positive people, it can be a great thing.

Brian: I'm not afraid to unfollow people. It could be my wife, sister, brother, mother.

I'm cool to unfollow you if you're not giving me the content I want.

Paul: Okay, cool. So be positive or BDougie will unfollow you. That's great.

Brian: Yeah.

Paul: Nice.

Brian: Excellent. Did you have any picks for the audience that you wanted to share?

Paul: Yeah. I mean, your lifestyle is far more interesting than mine because I think I'm consumed by work.

The only thing I can think at this stage is that we've got a couture maybe is relevant for a lot of the open source people.

We've got a tool called repository.surf.

If you go there you can actually look up a, an open source organization.

For example, you could go to repository dot surf slash super base or slash versatile.

And you can see their star grows over time but also you can claim an organization.

And then when you claim your organization you can start seeing your, how many issues are open and sort of the burn down of issues or the burn up of issues in our case and how we're growing these sort of things.

So this is one that we sort of have been dogfooding internally.

It's been quite fun, just building something unrelated to what we're building, but still useful.

And it's been quite cool actually.

I'm sort of surfing around different organizations seeing how they growing, seeing the bumps why the bumps come and you know what they're doing.

Brian: Yeah. That's really cool. There's a tool that you might've heard of.

Algolia there within the JAMstack they every year did a thing where it was they would give something away for free to the open source community.

So they built the search for Hacker News which is something that Hacker News search is not the best.

Paul: Yep.

Brian: So they built a better version of it, where they index the entire Hacker News site.

And you can go back and look at historical Hacker News articles and then a couple other things.

So you all should consider shipping that for the world to benefit from. I guess it's public reputation

Paul: Its public but also it's open source. So if anyone wants to improve it, yeah.

We thought about, you know, putting in some community features where you can see, you know, who are the top contributors and sort of profile them or maybe highlight the maintainers.

So, you know, you can surf around but to be honest, we're super busy.

So if anyone wants to contribute, it is open source.

Just go to Supabase on GitHub, find the repository surf or go to the website and click on the GitHub, link down the bottom.

Brian: Excellent.

Paul: But yeah, this is the one we've been jamming on. Has been a lot of fun.

We actually do sort of, dogfooding a lot of tools but this is the most interesting one that I can think of at the moment.

Brian: Yeah. Yeah. I mean I actually that's how open-source got developed it's because I was dogfooding Netlify.

And a lot of their newer features.

So I built that little tool while I was working there and it's like little pet project, but I'm interested to see if there's any room for contributions on my end are maybe replacing my Instagram's growing and I can start scrolling and do some repositories.

Paul: That'd be great. Yeah. We'd love to get you in there contributing. That'd be awesome.

Brian: Excellent. Yeah. Looking forward to it and yeah. Thanks for the conversation folks.

I hope you got a lot of insight at a Copple's story as well as what Supabase is offering for the community.

Definitely try it out. And the listeners keep spreading the jam.