Supabase: Open Source Firebase for Fullstack JS Apps

Welcome to Syntax.

Today, CJ and I sat down with Paul Copplestone, the cofounder of Supabase.

We dive deep into the tech that powers Supabase.

We talk all about Paul's outlook on open source and the origins of Supabase, including why it's super and not super.

So without further ado, here's Paul.

So welcome to Syntax, Paul. If you wanna give us a a quick introduction about maybe who you are and what you do at Supabase, and then we can get into some of the things a little bit deeper about Supabase as a product.

Yeah. Thanks for the, yeah. Thanks for inviting me. My name's Paul Cobblestone. I'm the CEO and one of the cofounders of SuperBase. We're basically a open source Firebase alternative JS how we position ourselves early on, but you can think of us really as a Postgres hosting company. Nice.

Yeah. And, you know, as a as a Postgres hosting company or even an alternative there, I I've always been impressed with UI of Superbase, how it makes things feel nice and easy for the user to get up and running. It's not like you're managing a database. Right? So I with that said, here's a quick question for my my 5 year old. Why super and not super?

Yeah. Because it's very hard to purchase the domain name super.

There was a a domain driven naming. That's pretty much how I do all my side projects.

Yeah. Nice. Which turns out to be both of, by the way, a blessing and a curse. The blessing is that it's very easy to find mentions of super Bos across the Internet, and people have started putting super pnpm everything.

The curse is that it doesn't feel that enterprising.

It's kind of like a bit of a meme, which is also, by the way, where the name came from. Like, Ant and myself like to meme a Scott. And so Super Bos, obviously, is a Nicki Minaj song, and we've we've thought it was funny that it was called Super Bass. And, that somehow stuck. Yeah. But here we are. It's working. Yeah.

Yeah. I always thought I always think of the there's an MF DOOM song where he says he's Supa in it. And I always think about that when I hear Supa Bos. So do you want to maybe give some background into, you know, how did Supa bass Scott, even from, like, technical foundations to, you know, why?

Mhmm. Yep. So timeline first JS, we started in January 2020.

So really just 4 4 years old, four and a half years old now. We went to YC in that summer batch as well and have just kind of been building fully remotely. So started during COVID and building the company remotely.

The sort of genesis was that in my previous startup, I was building using Postgres, but one part of the tool was a chat application, and I was using Firebase. I actually really love Firebase. I think the developer experience is amazing, but we hit some technical issues in terms of, like, the performance around, sending the messages.

And so I looked at migrating it to Postgres, and I did it quite naively at the start. Postgres has this listen Node system where you can push messages out of it. And I thought that was good until I run ran into another technical limitation there, on the Postgres side. And so I had to build a real time engine kind of on top of Postgres, and I did that with, Phoenix, Alexa, which kinda was the right tool for the job. You can connect lots of clients to it. It's good for WebSockets.

And we did it by kind of listening to the database replication stream, you know, and then you convert those messages into, yeah, literally adjacent payloads, and you can blast them out to the WebSockets.

So it's a cool technical solution, and, I'm a big hacking news reader. And I put it on Show Hack News, and it got a lot of interest at that point. And so I knew I was going to do a dev tool startup after my last startup, and so that seems like the right time. And I tapped my cofounder on the shoulder and said, this is what I wanna do.

I wanna go to IC.

Should we do it? And, yeah, somehow convinced him to leave his Scott up for to to help me build super base. Wow. So how long after,

like, you know, first lines are written did you end up joining YC?

Oh, yeah. So probably, I think the Hacker News launch that I did that one was on for just that real time engine Wes maybe in, like, September 2019.

Wes started the company in January 2020, and then we sort of got accepted maybe I think it was March or April of 2020.

No. And we didn't have March That's pretty fast. Quite honestly.

Yeah. But we're both 3 time founders.

We were shipping fast.

We we tried to

check off all the things that YC like like to like. Yeah. Yeah. That makes sense. So, yeah, I I like I like the fact that Supabase is open source and can be self hosted. Was that a decision you made early on that you were gonna make this thing and keep it open source?

Yeah. Honestly, it wasn't even really a conversation at the start. I think just Ant and I kind of philosophically love open source. I wouldn't wanna work on a dev tools if it was closed source. That's kind of the truth.

So, yeah, that's that's about all the thinking that went into it. And then we try to support, like, our philosophy on open source, I think, is a little bit unique in that, you know, a lot of the tools that make up the super base stack are all existing open source tools, and that was really important to us as well. It felt like open source is a lot of, like, you know, I'm gonna do some new way of doing this, and it's gonna be my own. But we actually like the model where you can try to support the tools that exist. They might not be perfect, but we can help to try and make them perfect JS the idea. So that's kind of our philosophy around open source, one of the key philosophies.

Yeah. It's it's one of the things that first drew me to Supabase. I've built a few a few projects with it. And the simple fact that it's built on top of Postgres like, I know a lot of times when you're choosing a new tech for a project, you worry about, like, vendor lock in or, like, am I gonna have to keep using this if, if I don't like it or something like that? But to me, it was super cool to see that it's built on top of Postgres.

I can use everything I know about Postgres.

And if I really ever wanted to stop using Supabase, I could. I could just literally take my database with me, which was nice.

Which has happened in the past.

We have we have, like, in our docs, one of the core principles is portability. You should be able to take anything you build, just basically PG dump and take it to your favorite Postgres provider. And there might be some things depending on how far you lean into, like, some of the tooling that we've got. But in theory, like, you can extract that. So we try to make everything very composable. So even though it's like a full back end, you can just use the database and stack other tools. Clerk's very common. You can use Superbase Auth, or you can use Clerk with Superbase. That's kind of how we want it to be. Do you have any stats on, like, how many people self host to keep track of that kind of thing? No. We have no telemetry. Another thing that we think is like, if you wanna self host, that's that's great.

Anecdotally, I see a lot of people do it, so we're happy. And, actually, yeah, some of the larger customers do it as well, so that's nice.

But because I'm a developer and I don't like tracking, then I can't give you any stats. Yeah.

Same. Same. That's awesome. I think it fits very well into you know, know, I don't wanna talk too much about Century because this isn't an ad for Century. But if it's very well in with what we're doing here at Century as well, you know, Open source tool. Mhmm. It is, you can just spin it up. You can take it with you. You don't have to worry about handing out cash to to use this tool. But, you know, it's it's your data. It's your information if you want it that way, you know, not tracking people and such.

It also shows that you can build a legitimate business on open source software, which it feels like that is a a thing people feel like you can't do these days for some reason. Yep. Yeah. I've I've been a longtime

fan of Century, by the way, and, like, the the developer focus as well is one of the things that, you know, we get inspiration from from Century.

The way they build the product, the designs of it, and the simplicity, I think, yeah, it's influenced

our thinking a lot. Yeah. And and I'm glad you mentioned the simplicity piece because that's what drew me to, Supabase. I I, you know, really got my start in in full stack JavaScript in Meteor world where you had real time, you had your database, it was all you had your auth, it was all very connected. Right? Simplicity was a major source in there. And and Supabase was the 1st product that I saw that really had that same feeling.

Mhmm. Auth is baked in. You want the magic ESLint, you got the magic link. You don't have to worry. You you can expand upon that later if you want it. But just getting up and running 0 to 60 is very fast.

So I I guess, like, what was your inspirations

for the simplicity of that? Was it just I want a tool that makes getting up and running very fast, or or what was the the inspiration there? Well, with Firebase, I think, is really one of those tools. It's incredible for that. And, yeah, I think a lot of people are like, you know, Superbase is great.

Firebase is not great, which is not true. Firebase is a phenomenal tool for getting started. It's just really incredible. And I think if they were, you know, open source I've actually chatted to the the founder.

If they were open source, like, they would have probably the same vibe that we've got today. It's just that wasn't their path in 2012.

The world was different then. Right? So I think, like, you know, we literally kind of benchmarked how fast you could launch a database on Firebase and insert a document. And then we went to RDS, and we benchmarked, like, how long it would took. And it was, like, 1 minute on Firebase, and it was, like, 8 minutes on RDS because you gotta set up your own separate application and everything. So that was, like, just our 1st test. Can we insert a document like, a row into Postgres as fast as Firebase?

Wow. Yeah. The it's Firebase is one of those, I almost called it Firebase.

Node it's, like, stuck in there.

Firebase is one of those tools I kinda always avoided just because of its you know, you never know which products Googles are going to kill or whatever, and and I didn't wanna build, you know, my information on something like that. But, SuperBase to me never had that same feeling, obviously, because of the the nature of it.

Mhmm. So okay. So you you wanna make a a better open open source Firebase, and I I think it definitely fits that vibe. Mhmm. But going forward, like, how do you take it further than Firebase now that you are you know, you have a different mission Node, probably?

Yeah. Exactly. I mean, you have to solve Wes think of a database problem. Right? You're going to launch a a database company.

What you wanna do is, like, build the world's best database platform. So you go to a big company and you say, hey. You should host your databases with us. And all of them say, no. Like, who are you? We can't trust you with your data. So there's only one way to build a great database company. It's to become the database that developers love on day 1. They kind of choose their stack before they they even think about their side project that they're gonna build. And then a lot of them start scaling up. And because it's databases, they don't churn. You know? You just make sure that your product is amazing for them, and you could support them all the way through to IPO. And over the next 10 years, we build our credibility around Postgres. We build a lot of tooling for Postgres.

We build a lot of scalability into Postgres.

And we're having to do this, contributing up, employing open source maintainers, making sure that, you know, the tool will go beyond anything that they'll even see on, say, AWS or, you know, on one of the big 3 clouds. We wanna make sure that we can really fit that vision so that when we go to enterprises, we've got 10 years of credibility and scalability and logos to prove it.

So looking at the docs, I see that there are quite a few client libraries, not just JavaScript. So I see things for, like, Flutter. And then in in the recent GA announcement, you announced the Swift client. But then there are community packages for, like, Python and C Sharp and Kotlin. So how do you decide which client libraries are gonna be official Vercel, like, keeping them more, like, community maintained?

Yeah.

Not easily.

Yeah.

I imagine. So we developed first our JavaScript, libraries and TypeScript libraries because that was the thing the thing that was really missing when we started was there was no back end for the likes for the Jamstack.

That's how on Netlify.

And so we really focused in on that use case first. So JavaScript was the natural thing. How do you as well, like, this type of front end developer, I would say, is not so familiar with the nuts and bolts of Postgres, and so it's a really easy win. We can just, abstract that away and make it incredibly easy for you Vercel, say, maybe like a Pnpm developer, popular now, probably know a bit more of the Bos and bolts setting up ORMs and things, and they're gonna use the Laravel and it might handle it for you. So so that was the use case that we focused on.

Then over time, just to cause a lot of people started piling in and, requesting all sorts. Mobile became very popular because of Firebase was very popular, and people wanted to migrate to Superbase.

And so they wanted mobile. We ended up doing, Flutter first because it was kind of like a new new system, and and that actually came from the community. This is, like, kind of our hiring strategy.

We had this person contributing.

They did the o open source Flutter, libs. It started getting popularity, and, so we just hired him, for to work on him full time. Nice. And he's a dev role. It's a good question. Yep. Yep.

You might say it. Tyler. Tyler. Okay. He's a Japanese DevRel, actually. So he was based in Japan. Funny enough, working at HubSpot as a like a just an engineer at HubSpot, nothing to do with Vercel, but turns out that he's also just very good at this type of stuff. So so it's cool.

We've done a lot of that, by the way, like people who contribute to our our Sanity, and they're kinda too good to ignore that we're just gonna hire them.

Yep. Nice. Yeah. So so I think that's kind of how it happens. Like, we just have people contributing, and then eventually, if something becomes popular enough that the community are kind of shouting that, hey. Can you make this official? Then we

pull the trigger. That's probably a good strategy. Yeah. I guess I should also mention for anyone else that's listening that isn't familiar, you don't necessarily need a client library, though. I think that's Node thing about Supabase is you could connect directly to the database and just use your preferred ORM, or you could just use your favorite Wes API client and and talk to the REST API. So So it's important to Node, you don't need these client libraries, but it is cool that you you have that support as well. Yeah. Thanks for shouting that out because, like yeah. It's actually one

thing that we did too well at the start was positioning, like, some of the super based tools, the additional tools that, at the Scott, now we're having to change the narrative that you don't actually have to use all those tools. You can just use the database and well, like, I'm a big fan of Drizzle, for example, becoming very popular Yeah. With with super Bos. But, yeah, Prisma's popular, Keasley, all all of these, like, whatever you want. You can plug, yeah, your your Ruby and anything you want on top of the Postgres database, and then we're happy. Like, that's what where we wanna be. Yeah. And you could

still take advantage of the Supabase

platform itself. Yeah. Without having to worry about the the client's deadline. We got a ton of cool database stuff like index advisers, security advisers, and, yeah, scaling up, reap replicas. Like, just making sure that it, yeah, is easy on the database side. So the additional stuff is there if you need to reach for it. Great for prototyping, and the Postgres Maxis like myself love the additional tools.

But, yeah, if they're not for you, then that's that's kinda fine. So you guys also have edge functions. Right? Mhmm. Is the idea with edge functions there to kind of remove the the need for any kind of back end server component to your like, Supabase completely would become the the back end of your your application. You can just use an edge function when you need server side functionality.

Actually, the the reason so we started doing these things launch weeks. I think they're pretty popular now. And every single launch week, we'll say, yeah. Guess what we're shipping? And people will be like, functions.

We'll be like, no. No. We're not.

And then after, like, 4 launch weeks, people were like, when the air for each epic functions? So Okay. We had to scout around to find, like, an open source runtime for for running functions, and Deno, of course, sort of made the cut. But, actually, the way I like to position our functions is, because they serve a very important purpose with databases.

It's not to like, if for example, if you're using Next. Js, I actually recommend you just bake all of that sort of routing logic in there. But where it's useful on the database side, I like to refer to them more as, like, background workers.

So as an example, we're becoming very popular for AI applications because of PG vector. You can store your embeddings in Postgres, do RAG, all these sort of things. But creating the embeddings itself, you wouldn't really wanna do it inside the database because it's a lot of compute, and you choose your compute size. So what you wanna do is maybe someone insert some content, and then you need to shove out this workload to somewhere else like a background worker.

And now we're starting to bake a lot of this embeddings, AI tooling ESLint the edge functions itself. So you can now, like, insert a 1000000 rows of content, and it'll trigger out a 1000000 of these workers' edge functions. They'll create the embeddings and stuff them back into the database. We call them database webhooks. That's the way to to offload the compute.

Gotcha.

I was gonna just bring up now now that you you mentioned, PG vector and and and that technical bit, Is that nice because you're built on Postgres that you can just utilize something like PG vector and likewise, like Wes that a tough technical challenge to implement it to an existing product?

Yeah. Actually, no. There's another funny open source story that I just wanna touch on here. So the way that PG vector came about was because this guy came in. He emailed me directly, and he's like, you know, I'm building this. This is probably February 2023 or something like that. And he's like, I'm building this tool, and I need to store embeddings. And there's this extension called PG vector, and no one's using it. Like, none of the Postgres hosts. Can you please, merge it? I've created a PR here, and I looked at the PR. It's just very well structured and everything. Mhmm. And I jumped on a call with him, and I said, you know, what are you doing? And he talked me through it. And I said, okay. I'll merge it JS long as you create, like, a, like, a chat with your docs inside our docs, which had actually Scott not been done before. And so we called it Clippy. You can, like, search for super Bos Clippy as a joke because we're really worried that it would be so that it'll give the wrong answers and everything like that. And Clippy was, of course, terrible like that. So, anyway, the guy the guy did it on a contract, and, like, it was so awesome that, of course, we hired him.

And that's the genesis of, PGVector. So we were the 1st Postgres hosting company to offer PGVector, and we've been working with now now it's, we're not the main creators. It's, a guy called Andrew Kane, but we support him along with a few other companies that, yeah, we're really grateful for as well because the performance of PG Vector in the past year has rapidly increased, which is pretty cool to see.

And, now the thing that you asked, like, is also a really interesting insight. Like, how hard was it to offer this new product? And this is, like, where I think our product strategy is a little bit unique. You can think of Postgres as like a really common Postgres problem. And we have a couple of other primitives that make Postgres really easy to use. Auth, yeah, the background workers, edge functions, storage for file storage, and, yeah, like, a few extensions that can trigger things.

But if you like, these are what I call, like, the sort of, first order primitives that you need to build almost anything.

But then we can mix and match all of these to create these 2nd order primitives.

And our 1st foray into, like, this product was actually the vectors. Like, we've got a whole section of our docs called SuperBase Vector, but, actually, it wasn't really a new product. It literally was, hey. Turn on this extension, and here's a bunch of docs on how to use it. And it turns out that Postgres is so extensible that we could do this with several things and probably will eventually, like search. You can use Postgres for searching.

Queues. You can use it for workflows.

So they're kind of like more solutions. Here's how to use our primitives to achieve a certain solution.

And so, yeah, that's what I really liked the most about Postgres, its extensibility gives us that that option. We can just think of everything

as a Postgres problem. Definitely. Nice. On that note about documentation, though, like, SuperBase has some of the best documentation, like, eve even before you added the AI stuff. So I'm just curious, did you have a strategy with that to, like, make sure you had good docs? And then also, I mean, it was cool to see like, SuperBase did the Clippy thing, and now almost every docs you go to have, like, AI. Yeah. So you can just you can, freeform search, and the docs will, like, give you an answer for it. So yeah. So, like, who worked on that? What's what's your secret? It's super cool. Yeah.

Very much a shared effort over the years. I remember docs were extremely important at the start. I remember I spent a a week, and my my goal at the start Wes, like, you should be able to consume from start to finish everything in a couple of hours so that you kind of understand what you need to.

So the conciseness was really important, and, yeah, we're using DocuSARCE.

Eventually, we kind of outgrew it. We wanted to make it, like, more of a product, like docs as a product. The guy, Greg, who merged PGPector Wes really responsible for a lot of that, sort of early the AI TypeScript, productizing. And then we hired hired someone, Karas, who has just focused really on this, not only the development of the docs, but the information architecture of, like, making it really concise. And, also, like, our goal as, like, docs as a product is somehow to bleed docs into the dashboard and the dashboard into the docs. So you'll start seeing, like, you know, the keys appearing and everything.

Yeah. That's

that's kind of the goal. That that's super cool to see, though. Because in in the dashboard, like you're saying, like, there's documentation, but it has my endpoints, my my keys in it as Wes. So that's super cool to see. Yeah. We have also, like because, yeah, you touched on the ESLint

interface that you get free of charge. It auto scaffolds out of your database. So it's kinda cool. Like, we can it just has an open, open API spec, and we can literally generate, like, an entire, like, documentation page for you. Like, here's the endpoint that you can click, and here's the, super Bos JS query that you can run, and, like, we can embed that everywhere. And that concept actually came from Airtable. I really like Airtable as a tool. And I I, actually, I think a lot of their DX like, imagine Airtable, but it was Postgres, then you would have kind of this killer product. Right? Because they had this auto or have this auto generated API as well, but their docs would also auto generate as you change the the schema. So, yeah, that initial version of, like, auto generated in docs came from my use of Airtable.

Nice. Nice. Yeah. And and I I suppose that helps keep everything up to date. I would imagine once your product continues to grow and grow and grow, it's pretty easy for docs to get out of sync. Mhmm. Next thing you know, user is having issues. Yeah. Yeah.

Man, that is it's a big challenge with such a large project. So yeah. Kudos for executing on it on it so well. I wanna talk about the the product again in terms of, like, the underlying tech behind it. Mhmm. So when you when you first started it, Vercel today, like, may let's talk a bit first the UI tech. So what's the UI built on, and then how has that changed over time? Is it same same initial code Bos? Or is it evolved into different platforms? Or what's the story there?

So yeah. I think what we had at the start was a NextShares for our dashboard and DocuSaurus for our landing page and docs. Mhmm.

Then we moved everything to Next. JS, and we started using, yeah, a mono repo so we could do shared components, moved out docs in.

Yeah. And that was the goal. Like, the goal was to get this really consistent feel so, like, you can almost feel like the whole dashboard becomes, yeah, one key product is kind of the the goal and make sure we've got consistency. So that's where, like, Next. Js and and I think, yeah, Turborepo was warp earlier adopted there just to make sure that we could get this very consistent feel and, UI kit. And we've got Johnny. You might see him on our Twitter. He shares sometimes some of the design systems and things, and he's phenomenal at coming up with, yeah, some great components and things. So we've also got this very kaizen approach to everything. So, like, sometimes you'll see that things are a bit inconsistent, in our dashboard JS because, like, he's trying out some new component that we're going like, or a pattern that we're gonna spread out throughout everything, and it might just get tested in one pnpm.

Or he's fixing my poor design decision from from 2020 probably JS the other the other thing that he's doing. So, yeah, we've leaned really heavily into Next. Js, which has been great. Yeah. Of course.

You mentioned starting naively.

So, that that fits in well with that. I think that's the best way to start, though. Right? You just get going and worry about it later.

You mentioned Kaizen as well. Do you wanna just give a a quick quick couple second what that is and and that what it applies here? Yeah. It comes from the Toyota production

kaizen means, continuous improvement from the CEO to the assembly line worker JS kind of the the term. So it doesn't matter what you're doing. Everything is a process that can be improved. And, importantly, incrementally improved is one of the things that we put a lot of emphasis on. Like, if people come out with big bang projects, we just say no. It's gotta be done, like, in a very small way, chunk it down to a couple of weeks at most, and do increments everywhere. So even like our branding and, you know, people like to rebrand their website or something like that. We haven't done that. We've just, like, evolved the branding of the website. Yeah. Yeah. Yeah. It's kinda like Bos does that too. Right? Like Yeah. Little components change here or there. Next thing you know, it's

very different over time. Does that come from you, the Kaizen philosophy? Or or did that is that is that something that you brought to the table?

Yeah. I think that one's kind of one of my, like, core life values, actually. I think that everything should be approached in this small improvement type way.

I love that.

Node. So talking about internals, we talked about the UI tech. It's built with Next. Js. Can you talk a bit about, like, the open source Supabase stack? So you mentioned the initial thing was kind of like a plug in for Postgres.

What else is involved in in that stack?

Yeah.

The total stack is a few servers. Each one of them is open source. So Postgres we don't run a fork or anything like that. We have a Postgres bundle. So our bundle has a bunch of extensions.

That's all we do. So we make the extensions in. But that same one that you see in our open source is the one that you could self host and everything. Yeah.

So that's the key component. And then, like, the other components are, for example, as one that you mentioned, Postgres, which is an auto generating API on top of Postgres.

And, what you're gonna find as I go through the tools is every single one is written in a different language Yeah. Unfortunately for us. But, you know, usually, they're the right tool for the job for a particular reason. So Postgres, actually, I had used it, this stack, in my previous startup, which is why I was so confident on it, and it became the early stack. But I had also, like, written a blog post about it and had reached out to the maintainer to make sure everything was okay to say in the blog post.

So I kinda knew him. And then when we're starting Superbase, I reached out to him to say, you know, is it alright if we use it in Superbase and promote it and, anything that we can help with? And he said, you know, we're looking for some sponsorship, and I need $200 a month or something like this to keep maintaining it. And I said, like, what are you doing? And he literally was not working on anything.

And I was like, well, there's no way you can maintain this for $200. So we just employ them immediately, to work on that full time. Yeah. Node

This is, like, the best reoccurring story here is that Yeah.

You needed something so you employed them. That's great. Yeah. Wes and it's just such a good common good for the world. Do you know? Like, so many people use Postgres, and it's it's so hard as a open source maintainer to make money from sponsorships. I mean, like, 250 dollars a month, the poor guy I mean, he lives in Peru, but still the it's for the value that the world gets, it just seemed completely, unfair. So, anyway, we have maintained he has maintained that, for us, but for everyone else for for the past few years. But that's been really helpful for for the super Bos community too because we've had a to patch a lot of things that are important for our customers, as well. But we try to make sure that nothing's super Bos specific. He makes choices only for the community.

Auth Yeah. Actually came from Netlify.

They had an auth tool, which they I I guess, we didn't have auth when we launched, which was kind of funny because your database wasn't safe. But Yeah. Everyone was asking for it. And our promise to the YC community, because we Scott launched on Hacker News, was that we'll build auth, but we'll do it in a very Postgres native way. And they're like, well, good luck. And we spend all of our Wes batch trying to figure out how to do this. And we ended up, yeah, finding GoTrue by by Netlify, integrating that with Postgres row label security, which was quite a bit of work, but we ended up getting there. And in the end, that one, we actually had to fork because, yeah, it diverged so much that we couldn't upstream some of the stuff.

So, yeah, storage. We have a storage engine for large files.

That one as well, we had to create ourselves.

It just sits on top of s three. So it's a very simple ingestion ESLint, can stream can do transformations, things like that. But we do integrate with, image proxy and support and upstream a lot of tooling there to integrate with Postgres. So doing things like distributor locking.

So that's been a lot of fun working with the evil Martians team

on that side. Yeah. Oh, they're great, aren't they? Yeah. I I'm a huge fan of their their blog in general. Yeah. And for the s three thing, for self hosters, you just give give the, config a s three bucket or a location, and then Supabase does the Wes? Is that the the scoop?

Yeah. So on that one so our self hosting, if you want the entire stack, JS just a docker compose. So you just put docker compose up. Okay. And inside the docker compose, you put your s three, access key and, secret. And so that will route it to your to your bucket. You can actually just each one of the components, because the way we've designed it, can also be self hosted individually. So you could take the storage engine, for example, chuck it on fly, and then use it with or something like that or wherever you want. I don't see a lot of that, funnily enough. I thought there would be a lot more like, oh, I want this individual tool. Our auth server, for example, is in Go, and it's very simple.

I thought a lot of people would use it, but but they don't really. They just wanna use the entire stack together rather than 1 individual tool.

Yeah. I guess that makes sense. Yeah. And, personally, I've Vercel hosted it, and I I think it's because ease of use, it's literally a docker compose up. So I didn't have to worry about, like, swapping out the pieces. And then for the s three storage, I just self hosted MinIO. So all of that kinda just works together. Nice. I think overall, it's really cool to hear that even though Supabase is built on top of all this open source stuff, it's you're you're basically giving back to the community. You're making sure that all of those open source libraries stay maintained, and

Supabase isn't gonna fail if one of these libraries fail because you're you're heavily invested in them in them as well. So that that's really cool to hear. Yeah. Over overall, I think that that seems to be, like, one of the very positive messages. You Node, Wes one trap that you can get into hosting a podcast like this is, people come on to pitch their product. And it's just like, here, here's my product, and here's why my product is so great and why you should be locked into my product forever.

But, like, that it feels so much, I don't know. It feels great to be able to talk about a project like this that doesn't lock you in, that enhances your workflow. You can host yourself if you want it. And and I'm the opposite from CJ. CJ, have you always hosted your own Supabase

whenever you gave it a try? No. When I first tried it, the the self host option wasn't available just yet. Okay. More recently, when I was trying out, like, Coolify and some of the self host server stuff, that's that's finally when I spun up my own instance.

Yeah. I I'm I'm the type of person that I will look at the fact that you can host it yourself and just say, I'll sign up for the service anyways.

And, and and for the most part, you know, I had just, nothing but ease when when getting into it. And so when you're designing this as a as a product on top of an open source project, how much of a consideration is that to make like, I I know you don't want to make the the self hosted version any Wes, but how do you how do you, like, make this into a viable business so people aren't just taking your your code and running with it? Yeah. It's actually one of the hardest

things of open source. What I've realized is no matter how open source you are, you can never be open source enough for some people. So I I have this, like Yes.

Blog post in my brain, which I've been meaning to post. And, like, there's several spectrums on upon which they'll judge you. So the first is, like, your license, how open source is your license. And so we actually check all those boxes because we have only MIT, Postgres, and Apache license.

The second is how self hostable you are is actually, it's actually unrelated to open source by the technical definition, but people will judge you by that. Then the 3rd JS, actually, are you a commercial entity? And if you make money, people will just not think you're open source enough. That's what I've come to realize.

And so it's tricky. Like, I just that third one I think is unfair, and I just categorically remove them from my my brain now if I'm talking to those people. I know that we can't satisfy them, which I think they do such a disservice to the open source community because, of course, then open source maintainers feel bad asking for money, and, of course, then they stop maintaining things, which, I wish that all the money's all the money in the world poured back into open source. That's would be the ideal situation in society.

Yeah. Yeah. We do a a big open source, donation here where Chad from Century had wrote an app that scans our our Deno. So even the syntax repo and then donates an allocated amount to all the projects on a on a consistent basis. And it's like it was so simple for him to set up. It's a small allotment. We're getting so much benefit out of these projects. Mhmm. Like, it would be trivial for many companies to set this up, yet they're more satisfied with, you know, just taking the code and running, really. Yeah. Yeah.

I think on the self hosting side, I get this question a lot. Like, do you hobble it so that people have to use your cloud hosted service? The answer is no. Not at all. Like, we don't, like, intentionally try to do anything, but we have a lot of work to do, even on our platform. Right? And these people are kinda paying for it. They're the ones who will jump up and down rightfully. So, like, if things are not working, they're like, I'm paying you $25 a month. Can you fix this thing? Versus the ones who are saying, you know, I'm paying you nothing. Can you fix this thing? You, of course, have to focus on the person who's giving you money.

I mean, that's just out of fairness to them. So we try like, it's very hard to balance these 2 because, I quite obviously, I hope demonstrate to the world that we are open source and focused on open source. But it doesn't mean that we can spend all of our time focusing on on customers who who warp to talk self host. It's just not the way that we can operate a good business. Maybe as we grow and we make more revenue, we will be able to allocate a lot more of that revenue towards that. Yeah. But we're not at that stage yet. Yeah.

But, you know, you mentioned that there you can never be open source enough, and that is true. You could be as open source as possible, and there's still going to be someone on the Internet complaining, no matter what. So, you know, I think, like you mentioned, optimizing for the paid customers is great, giving the open source option, self hosting options. Those are all great. So it it feels very, like I don't know. It feels very open and transparent.

So it would be surprising that anybody and sure enough, I I can imagine someone's gonna leave a comment on this, like, oh, this is a great ad for Supabase. And it's like, okay. Somebody did that with our pocket Bos episode. We talked about pocket base for, like, 20 minutes. Somebody was like, this is an ad, and it's like, it's not an ad. What are you talking about? Yeah. I mean, Pocketbase is a, yeah, amazing

open source tool. Like, and I yeah. The good thing is, like, you know, like, they don't have a hosted option. So, like, they can check all of those boxes. You know? Like, they truly are an open source, product. So, like, you know, if they bring out the a host option, then they will fall into that last category. But, yeah, I I think it's, like, it's kind of fair. Like, it keeps you keeps you focused on your community. At the end of the day, like, we also want to serve them. And, people jumping up and down gets the you Node, gets our attention. That's the truth. And, like, we wanna solve all those problems. If we had infinite resources, we we really would. So, you know, it it does serve a purpose when people complain out loud, and it's one of those things that we learned to Sanity, especially me personally.

They would make personal attacks and things say that, you know, we're devious or whatever.

But there was a kernel of truth in what they're saying. Like, we we weren't as you said, CJ, maybe you used it when the like, in 2020, we didn't have the dashboard open sourced yet. It's literally because I was too afraid to open source for security reasons. They had they had billing code and things like that. So the exercise to move it to Next. Js and turn into a turbo a mono repo was actually quite an exercise to get it into the open source.

And we spent a good couple of months, but largely because of a personal attack. And now I've I've, become a lot better at I think JS you said, Scott, like, you kind of just need to be clear. Well, here's the contract that we have with you. Like, we're we're not trying like, here's our commitment to you in the open source.

This and not much more. Like, we just need to make sure it's very clear, and we're not trying to pull the wool over anyone's eyes in terms of how open source we are. Yeah. It seems like, you know, you guys have definitely popularized

the, the whole launch week thing. I I think you were really even some of the first ones that I saw do that, if not the first. And and it seems like you guys just launch a lot. I I know that goes along with your incremental updates, but what is the the future of Supabase look like? Like, what's the next step here? Because it it's a really well developed product. It does a lot of things.

Like, what what what what even what else can you even do here?

You're asking for for me to reveal our next launch week. Is that Oh, no. Is that Does not have to be

anything nonpublic. It can be anything yeah.

No. Actually, like, we haven't really gotten to the bottom of the laundry list on almost all of the products. So, like, auth still has a few, like, really key features.

Storage has a lot of key features. Like, each one of them the way that launch weeks work actually is kinda more internal at this stage where Wes need to organize the team. They're we're very asynchronous, so we don't have meetings or anything like that. So we just say, well, here's the date of the next launch week. Tell us what your, like, big project you're going to ship. And they come and tell us, oh, this is what we're going to ship.

So, yeah, I actually don't even know what is in launch week. I have Vercel ideas of some things are kind of new and exciting.

But, you know, the the next stages, like, are really around scale and types of data that people wanna store. People wanna store a lot of their like, people are storing logs inside their Postgres database, which is just not a good idea.

They shouldn't be doing that, so we need to solve that.

But we do want them to store their data with us and their logs and all that sort of data. So, like, you know, we've got enough problems. And and as well, people aren't using branching well enough. They're not using the migrations well enough.

We want better integrations with the one the, you know, ORMs, the drizzles, and things like this. So so there's a a ton of stuff for us to to still solve in the database space.

Yeah. Speaking of, like, branching and stuff like that, congrats on the GA. I know it was, like, 2 months ago at this ESLint. But if you didn't know, Supabase was in beta for, like, 4 years until, like, 2 months ago.

Can you talk about maybe some of those features? Because I I didn't even realize you all had branching now, so that's super cool. And maybe what are some of the other recent things that you launched that people should be excited about? That's a good question. Now that we've got to

let me see what we did for GA

week. I will say I'm also looking at a a blog post on Supabase. It's called top 10 launches from Supabase g a GA Week, so that's definitely something to check out.

What is our top I even wrote that, and I can't remember all that. So yeah.

I love it. There's a bit of something for everyone. Yeah.

Yeah. And I haven't I haven't used that one yet either. I mean, there's there's so much new stuff that I need to explore in Supabase, but the first one is Bootstrap. So you literally have a CLI that'll create a new project, so that's pretty sweet. Yeah. That one's actually cool. Like, we're gonna do a bunch of these templates to, like, launch

a project very fast. So you can bootstrap with Next. Js or Svelte or, you know, whatever it is. Yeah. As you said actually, yeah, these ones were, like, very cool. The Sanity, performance, and index adviser.

This one's cool because, know, I talked about you can use anything with, SuperBase. This is one of those tools that, like, really fits into that category in that, like, I saw someone was, like when we released our pnpm adviser, it actually gives you this hypothetical index. If you add this index, it will reduce the, latency on your query by 90% or something like that.

And so I literally saw, like, one day after we released it, someone said, oh, yeah. I turned this on, and my, my query JS 98.5% faster. So it was like an immediate win. Yeah.

Yeah. And that's cool because security as well on databases is is incredibly Yarn, so we and we lean into row level security, which can be a bit niche. So, you know, we wanna build out a lot of this advisory stuff, which you don't think about when you're like, you don't wanna have to learn if you think about a development life cycle, you wanna get started really fast, and then you want information exposed to you only at certain points. You don't wanna have to be thinking about, is it secure? Is it fast? You just wanna be thinking, does it work? Then after you get it working, you wanna think, oh, is it safe? Is it secure? Is it, fast? And that's where the adviser JS kind of the right information at the right time. After you've done prototyping it even on your local machine, you can then go to the adviser, have a scan through, like, all the, the the recommendations, and, like, enable this index or do that. And so it's kind of like a nice workflow pattern where you focus on building and then focus on the secondary steps.

Yeah. And that work that tracks too with what you're saying about maybe even initial some of those first customers being Jamstack or even primarily non back end developers. Right? Like, those people are the the prime candidate for somebody who's not going to write an index when they should, and they're gonna see potentially slow queries because of it. So having any kind of adviser there is a a great way to not only, like, help them, but to, like, educate them. You know? I think that that's kind of like a step most people have to go through when they're learning about performing database,

queries or any of that stuff. Mhmm. One thing on the advisers, I think, like, credit really goes to PlanetScale on this one because I think they do a phenomenal job on Mhmm. On database performance and really exposing, like, for a developer how to make the queries faster. So, yeah, I think, like, we look up to them in that respect in terms of building a really good product for for performance.

That's cool to hear. We we host on PlanetScale and have used their branching, have used their, yeah, their indexing features like that. So, yeah, it's cool to hear. Yeah. It sounds to me like you could even

take your Postgres database to Supabase and all of a sudden get a bunch of really good info even if you're not using the rest of the product. Just all of a sudden you have a bunch of insight into your database, which is pretty cool. So one last, like, lighthearted question for you. The Supabase account on Pnpm is really good at posting memes and stuff like that. So Yeah. You mentioned at the start of the the the interview that you like memes. Do you run that account? Or is it like do you have, like, a Slack where people like workshop meme ideas?

Well, that's my cofounder, who finally got this our CTO, who spends a lot of time on our, on our Twitter. We we also have an internal memes channel, which is great for hiring around.

Wes literally sometimes hire people because they or, like, the reason why they get ahead is because they're good at memes on Twitter.

So Nice. Yeah. I I think, like, our strategy there, no one wants to see a boring corporate Twitter account. Wes actually had never used Twitter before this, really. Like, I think we had accounts but had never really done developer marketing. But the one thing that we did think is, like, no one just wants to read about Superbase, this product that they've never heard of. They just wanna hear about, like, shipping cool shit and doing memes. And so we're already sending memes to each other, and he just started posting them on on,

on Twitter. So, yeah, it's worked very well for us. If you can do it right, it works. I mean, sometimes, like, for certain companies, it'll come off as cringe, but Superbase is doing it right for sure. I always have a a chuckle every morning. That's the other funny thing. We realized that we actually

realized this by trying to hire someone to do this for us instead of Ant doing it. And we realized that actually, it's very hard to find someone who can do it right. And so now we're like, Wes, Ant, that's clearly the only thing you should be focused on, and, and other companies kind of just can't pull it off. I see sometimes, like, our competitors have clearly looked at our Twitter, and they're like, oh, let's do what they're doing. They've got a lot of followers now. Mhmm. We need to do that. And I look at what they've done, and it's just very cringe, just really off the mark. You kind of get memes or you don't, it seems. So, yeah,

a lot of them a lot of them don't. But Yeah. Get a good, chief meme officer on your Yeah. On your team, and you're good. Yeah. Alright. So now's the part of the show where we talk about sick picks and shameless plugs. Paul, do you have a sick pick for us today?

Yeah. So I just arrived in the US 2 weeks ago, and I bought to try it out, the like, an Apple Vision Pro. So I've been testing it because I fly a lot. I travel a lot. So the idea is then I can work on a plane, work in a hotel room. So I've been trying it out. So far, I think I'm still on the honeymoon phase of this. I don't know whether it's gonna be a regular feature in my life, but I'm very impressed with the technical aspects of, yeah, the VisionPRO software.

Yeah. A little bit to be not many things to download on it at this stage, but, yeah, for usefulness as a as a, like, monitor, 2nd monitor or multiple monitors has been good so far.

Yeah. I I have one too. I use mine a lot, like, if I'm working outside.

Like, I'm working at a, like, a table outside. I no longer I'm constrained to my little laptop. Blow it up. There's an app that if you don't have yet split screen Okay. It allows you to do multiple monitors. So you could have several monitors. And so that that's a a must have for me. I I use that one a lot.

But I I agree. There's not a ton ton to use right now, but the experience is really pretty incredible.

Yeah. Yeah. It's crazy. Like, I actually, in another startup life, worked on, like, kinda metaverse and ARVR.

Mhmm. And Node, like, went deep on a lot of the things that could be solved.

And I thought, well, the technology, the hardware just isn't gonna be there until, like, 2026, 2028, 10 years ahead. And what they've delivered now has kind of just pulled forward 5 years. It's crazy.

Yeah. It's crazy. Yeah. It feels like the software is what's lagging, which is the the the crazy bit. Yeah. Yeah.

And shameless plugs, is there anything you would like to plug?

Yeah. I mean, of course, like, if if people wanna use Supabase, I would love them to use it, but I I guess the real plug, from my point of view goes to Postgres.

I think it's just such a good tool. It's really becoming better all the time. It's one of the most unique open source communities that I've ever seen, and I I can see it becoming kind of just a staple to the world. So I think it would be hard to plug super base without just directly giving a lot of the credit to Postgres itself.

Nice. Awesome. So, well, Paul, it's been amazing having you on.

It's really great to learn about internals, tools, all that sort of stuff. And, man, I I can't wait to see, where SuperBase goes from here. So, thank you so much. Thank you. Peace.