The Changelog: Software Development, Open Source - Supabase is all in on Postgres (Interview)

Episode Date: January 25, 2022

This week Paul Copplestone, CEO of Supabase joined us to catch us up on the next big thing happening in the world of Postgres. Supabase might be best known as "the open source Firebase alternative," a tagline they might be reluctant to maintain. But from Adam's perspective, he's never been more excited about what they're bringing to market for Postgres fans. In the last year, Supabase has gone from 0 to more than 80,000 databases on their platform — and they're still in beta...and it's open source. Hopefully today's show sheds some light on why everyone is talking about Supabase.

What's up, welcome back. This is the ChangeLog. We feature the hackers, the leaders, and the innovators of the software world. We face our imposter syndrome so you don't have to. Thank you for tuning in. If this is your first time joining, the Master Feed is where it's at. Get all our shows in one single feed. Check it out at changelog.com slash master. Today, Paul Copplestone, CEO of Superbase, joined us to catch us up on the next big thing happening in the world of Postgres. Superbase might be best known as the open source Firebase alternative, a tagline they might be reluctant to maintain. But from my perspective, I've never been more excited about what they're bringing to market for Postgres fans. In the last year, Superbase has gone from zero to more than 80,000 databases on their platform, and they're still in beta, and it's open source.

Hopefully today's show shed some light on why everyone is talking about Superbase. Big thanks to our friends at Fastly for making all of our MP3s super fast all across the world. If you downloaded this show, it was fast because of Fastly. Check them out at Fastly.com. This episode is brought to you by our friends at Sentry. Build better software faster, diagnose, fix, and optimize the performance of your code.

Over 1 million developers and 68,000 organizations already use Sentry. That number includes us. Here's the absolute easiest way to try Sentry right now. You don't have to do anything. Just go to try.sentry-demo.com. That is an open sandbox with data that refreshes every time you refresh or every 10 minutes, something like that. But long story short, that's the easiest way to try Sentry right now. No installation, no whatsoever.

That dashboard is the exact dashboard we see every time we log into sentry and of course our listeners get a deal they get the team plan for free for three months all you gotta do is go to sentry.io and use the code changelog when you sign up again sentry.io and use the code changelog so we are joined by paul cobbl from Supabase. Welcome to the show, Paul. Hey, you guys. Nice to be here. Happy to have you. I should say this episode requested by John Stodall, longtime listener, who also got a request serviced last year.

The Darkling episode was John's request, and he's back requesting Supabase. He says, hey, open source Firebase, need I go on? They're building an all-in-one solution. You can self-host or buy as a service. They aim at providing the same features as Firebase, but with their own twist. They've already established off database and storage with functions on the way.

Is that a pretty good pitch, Paul? Well, you probably should have just got him on the show. I mean, he's already done my job for me. That's pretty good. All right, and we're done. Thank you for coming, Paul. Yeah, there you go. Well, I guess we have it.

It's well-positioned open source Firebase. I know you're going beyond that now because I've read some of your more recent stuff that was kind of like at least the starter is like a Firebase. But it seems like from what I'm seeing, it's less of a recreation, like an API compatible thing

and more of like an inspired by Firebase. Or am I not reading it right? No, that's exactly right. of a recreation like an api compatible thing and more of like an inspired by firebase or am i not reading it right no that's exactly right so we yeah the main thing that we offer is the database so it's a postgres database it's a full postgres database it's no abstractions and really what we're building around it is the tooling to make postgres as easy to use as possible so automatic apis and all the things that he said actually and so really it's this inspired by as you said we're not going for one to one compatibility if we were then you know the only differentiator would be open source and already firebase is very good it's a very good product and just having open source as a

differentiator might be enough, but we feel like we can go above and beyond. We can also make it incredibly scalable. We can make it work with existing open source tools. We can support open source tools. So yeah, we sort of take a few liberties beyond just being a one-to-one alternative. So I've never used Firebase beyond the demos. I know some people who sing us praises. I know there's been some decent businesses built on top of Firebase. It's not a new thing.

Firebase has been around for many years. I don't know what the general zeitgeist feeling is. Is it stagnant? Is it continuing to add? I feel like I don't hear about it as much as I used to, which may be a hype cycle thing, or maybe it's inside Google now, and so is it maybe just being maintained but not worked on? much as I used to, which may be a hype cycle thing, or maybe it's like it's inside Google now, right?

And so is it maybe just being maintained but not worked on? I'm sure you know this far better than I do. So maybe catch us up with Firebase, your feelings on it, and why Superbase became a thing. Was it a reaction to Firebase? Or you see an opportunity? Unpack that. It's definitely still a thing, still growing. I think the team inside Google, I've heard from one person is 200 or so. So it's fairly decent size.

Yeah. I don't know that for sure. I actually would have to fact check my facts. But yeah, it's still very popular. And I think a lot of big businesses are built on it. Well, from the conversations that we have. So yeah, I think it's just one of the best tools that you can use if you're starting new now when you start scaling then maybe there's a different conversation to be

had but um i think it's still very well loved especially in the mobile space they've got a lot of products as well so i mean we kind of have four core products, database, auth, the APIs, and the storage, so kind of file storage. They've got something like 18 different products, analytics, ML, all sorts of things. So it's probably a bit beyond what we would consider offering. ML and things is probably better done outside of our ecosystem. And originally, we weren't really thinking of building an open source Firebase alternative. It's just that we changed the tagline on the website one day

and it went straight to the top of Hacker News that day and we kind of had to run with it. Yeah, it was well positioned, like I said. So you may have stumbled upon that, huh? Yeah. I had to run with it. I like that. It's like an accidental blessing, really.

I mean, especially if you're at the top of Hacker News, I think Firebase has a lot of praise over the years in terms of its platform and what it can do. Obviously, their tagline on their website says that it's loved by app development teams from startups to global enterprises. So that's a good spectrum, and you'd want to capitalize that as well.

On the people we want, yeah. I think for us, I mean, getting on Hacker News was kind of this perfect storm of timing as well. I mean, we're open source, it's Postgres, and Firebase is the tool that developers love to hate because it's Google now. Right. You know, it just happens

to be very good timing and positioning. Right. It's worked out for us for the past couple of years. We constantly have debates whether to change that tagline but for now it's working. At a certain point you're like, just please stop comparing us to Firebase. You're happy about it at first and then you're just like, all right, we've heard enough.

Especially enterprises, they say, well, we wouldn't choose Firebase, right? So it's not great positioning for the enterprise customers. Whereas Postgres, of course, is beautiful positioning for enterprise customers. But yeah, we'll have to shake that tagline. For timing's sake, or in terms of understanding historicals, when did things begin? So take us back to that tagline day when did things really begin for for superbase yeah actually so right at right back at the beginning i met my co-founder actually in an accelerator in singapore and then we didn't

do a business together we just hung out and we lived together for a year and we did our separate startups for a couple of years and then i kind of incubated some of the tools that we built for super base in my that startup and then i said to him look i'm going to do this postgres tooling startup i think i pitched him the name was like backstack or something like that as a placeholder something ridiculously terrible and so he was keen i think i actually pitched him, we're going to assemble this squad of people who are going to be very YC friendly

and we're going to apply for YC. And he had applied for YC like five or six times and been rejected. So I think that's really what he was going for, hopefully just to get into YC. Then we did, of course, January, 2020, we chatted to a few people about Postgres. Everyone loved Postgres.

We'd ask them what they wanted to use. We asked them what they were really using and they said Firebase. And so that's where we got this idea, well, the tooling is very important. Why did they use it? It was just very easy. So we sort of changed the tagline

and made the tooling centered against Firebase. We got into YC and that was summer 20. And since then, we've just been building nonstop, trying to catch up with all the features of Firebase. I guess that becomes your North Star too, right? If you get compared to them and you do it by your own tagline and admission, it gets traction. You get attention. Obviously, you're going to want to do whatever Firebase does. Does that limit you though in your creativity? Can you remake the model?

I guess a little bit. It's not so limiting because, I mean, really, Firebase is like many different businesses. We could do a few things that they haven't done, and we have done some things, I think, better. For example, our auth solution, I think, is just really good because it's got Postgres row-level security. So if you pitch it even to a database expert who probably loves row-level security, but no developers use it, then they fall in love with it as well because suddenly they get to use,

we make it very easy to build these database rules using Postgres' built-in auth system. So in these ways, I think we've kind of taken some of their ideas and made them our own and hopefully made them a bit better and i think we'll carry on trying to do that we try to choose like a very very elegant way to do everything centered around postgres the database it seems like a more one-to-one analog with firebase would be like a mongo db in terms of a data store right i mean postgres relational database firebase is like a more one-to-one analog with Firebase would be like a MongoDB in terms of a data store, right?

I mean, Postgres, relational database. Firebase is like a NoSQL thing, isn't it? It's like kind of a document store. I don't know how their architecture is, but that's how they sell it. Are you mapping on top of that, or are you just kind of ignoring that part of it? I know it's like, hey, it's Postgres

with services around it, which I think's cool, but it does seem like a departure from Firebase. Yeah, it is. You have to squint your eyes a little bit. That's why it's only on the main page of the website once you get inside. You're like, it's cool. I'm not really sure why they said Firebase.

We don't do any abstractions and actually that's the thing that I think most people love because even if you don't know that it's Postgres, you get in, we've kind of got this air table-like viewer where you can build your tables and then you discover oh this thing's actually a full postgres database i can write functions i can do triggers i can do whatever i want so to be honest it isn't so one-to-one yeah but we knew at the start that we never wanted to abstract actually this one came from a vc i have to thank them they rejected us the pitch to

them went terribly but um it was to sequoia one of the guys at sequoia had been at facebook when they acquired pars right and pars is still going and there's a great tool as well i don't know why people don't use it more but he said that they had this enterprise graduation problem because everyone would get to sort of enterprise level, but then there was too much magic. They didn't understand like everything happening under the hood. There's too much abstractions going on. So it became for us, we just took his term, no magic. We'll make it feel magical, but you can really understand everything. It's just Postgres. Yeah, we failed at that pitch,

but I think we won a very important lesson from it. Well, you're definitely speaking my language. I am a longtime Postgres diehard. Nice. In fact, Adam and I often joke about how hard it is for me to accept anything else as a data store. It's just like, it's just tried and true. I think there's lots of places

where you can be risky or more progressive in your choices. And I feel like your data store is just like not the place to go ahead and experiment wildly. And so why go away from something that is tried and true? It sounds like your story then is with Supabase. We'll get into the open source, the business side. We're going to get into all the details, but it sounds like when it comes to trying it on for size, at least for existing Postgres users, there's a portability story that I'm hoping is there where it's like, hey, it's just Postgres.

Even this auth stuff is implemented as Postgres features, and so you can walk away with that very simply. Is that the case? That's definitely the case. PG dump, and you're away laughing. Hook up whatever you want. The other thing, all your users live in your database. You can do joins on them,

row-level security rules with them. It's really just whatever you would probably build yourself ideally but we've thought it through we've plugged all the pieces in for you so whatever you might do yourself hopefully we've just done it a little bit better or a lot better depending on how well you hit your market right yeah where did this inspiration come from? Are you a long-time Postgres user yourself or are you just trying to find out what would be the perfect Y Combinator slash Hacker News? Love Child is like, we know they love Postgres.

You know, we know they love open source. Yeah, yeah. I don't know what else we could probably throw in there to make them love us more. Yeah. At the moment, it seems to be... Lisp, maybe? I don't know yeah something yeah lisp rust yeah rust that's it that's what we need rust libraries coming up soon there you go i think

no no no we used yeah actually my sql and postgres my sql i used in my first startup postgres in my second startup i particularly like the extensibility of postgres. And I fell in love with another very cool tool around Postgres, which is Postgres with a T. It's this auto generating API on top of your schema. And so you don't have to build an API. And it also is kind of this thing that, you know, it builds the API better than you would build it yourself. And so I used this, actually most of the tools inside Superbase were what I used in my previous business. And then the idea was, well, it was just so easy.

We built this whole business with just me and two other techies. And just because the tooling enabled us to do a lot more. And then I just decided, well, perhaps there's a business around it. And I chatted to Ant, my co-founder, and he agreed. So we went with it. There was kind of an impetus as well.

So we were using Firebase for one part of the system. It's like a chat application. And it has this weird limitation where you can only update a document once per second. And then it rate limits you. So I had to implement real-time functionality inside our Postgres database. And I did it using an Elixir tool,

and I open sourced it, and that started getting a lot of traction. So that's the thing that kind of gave me the reason to reach out to Ant and the reason for us to start Superbase. So let's continue talking about these other aspects. We touched on auth i think we'll probably revisit auth in a deeper way but you're also offering obviously the postgres

database as is file storage which i think is pretty self-explanatory you can tell me if there's interesting bits there but then the api site sounded interesting to me so you want to touch on file storage if there's anything to say besides it's like a file store? Yeah, there's one interesting thing. So we map your, let's say you've got a bunch of S3 buckets or folders inside an S3 bucket. We map all of them into a storage schema and then you write row-level security rules on those as well. So once again, when people are accessing those,

you can put rules like, oh, this user can access this file and you just write those rules inside the database. Okay, that is kind of cool. That is interesting. Yeah. Then we've got the suite dashboard for like you just sort of upload everything, drag and drop whole folders inside it.

And the dashboard is actually, I think the storage part is one of the coolest. Got a few Miller columns. You know, normally S3, if you go on there and you try to use it, it's terrible. The dashboard is actually, I think the storage part is one of the coolest. Got a few Miller columns. You know, normally S3, if you go on there and you try to use it, it's terrible. And no storage service out there is good for some reason. And I just think our interface for it is just 10 times better. It's as good as like a desktop app. Wow.

What's it built with? Frontend's Next.js. Been very good for us. Yeah. And so obviously good UI, good thing to have, but on the auto-generated APIs bit, it seems like better than just a fancy UI. That sounds like a really cool thing. Yeah, the tech behind that is very cool, and it's a very cool open source project. So it was around long before we sort of started the business. We employ one of the lead maintainers, or the maintainer of Postgres.

It was originally started by someone else. It was D. Griffith. I can't, I only know his GitHub handle. So I don't know his full name, who is no longer active, but Steve Chavez works on it now. And he's a full-time employee at Superbase. So it's a Haskell tool

and it kind of does this introspection on your database. And as you make changes to your schema, they're exposed, the tables are exposed, and then you can write a bunch of filters, modifiers, equality, full-text search, anything that basically Postgres can do, you can do it over a RESTful API, which is cool because we're starting to leverage this a lot

for a few cool things that I can chat about if you want. Yeah, that's spectacular. I've definitely heard of that tool. There's another one, which seems like it'd be right up your alley, which is PostGraphile, which is going to now create, instead of a REST API, GraphQL APIs, similar concept, right? Like go through your schema, introspect it, create a GraphQL API. Is that something that you guys are thinking about

leveraging as well? Yeah, which is, I think, very cool. And Benji has done a great job on that one. So actually, we were asked a lot for GraphQL at the start, and we just didn't have sort of enough resources to run so many APIs. But what we've ended up doing instead is that, and we just announced this,

we started building a Postgres GraphQL extension. So the GraphQL resolvers live inside your database. This is quite good because it solves the sort of N plus one problem. Then we expose the extension through Postgres. Well, that's the plan, we will. So we use the same RESTful API that you use for accessing your table. You can actually use it to access

Postgres functions as well as RPC calls. So we'll just expose one RPC function and then you can actually use GraphQL as well. You can choose REST or GraphQL. That is super cool. So one thing that we've been batting around here is a little changelog API and we are on Postgres. Now we have a full stack Elixir app in front of it. We could also just build that out in Elixir, whether a REST or GraphQL API, but I've always liked this idea of hooking it directly into the database and then have it be portable that way. It sounds like even if I wasn't into Superbase,

I could be into this cool new extension because you just plug that right into Postgres yourself. For sure, for sure. Yep, we're only at 0.1.0, so it's literally very early. But I mean, performance is great. It's looking good. I mean, it's looking very good.

So yeah, if you want it, install it on your Postgres. We'd love that. Super cool. So this is going to open up another can of worms we might need to defer the bigger conversation for a little later but it's like how do you decide just to build an open source postgres extension when it's like you've got these vcs behind you looking for you know you know like wait a second you're just giving away this extension that's

could open up a whole new area of business for us? Seems like there's a push and a pull there. Yeah, well, I mean, they are very patient, our investors. They luckily got very deep pockets. But also, I mean, our core business is hosting Postgres databases, right? So anything to make that more attractive to our customers would be good. Yeah, the better Postgres gets, the better you guys potentially get. Yeah, exactly. And we know that probably a lot of people will use this.

It was very popular on Hack News when we launched it. We know that probably a lot of cloud providers might want to use it, which is fine by us. I mean, Postgres itself, I think is the epitome of good open source. And I wish if all open source operated like this, where we're kind of sharing resources then you know the world would be a great place right so hopefully by other people

using it that will help us improve it as well and it's good for everyone This episode is brought to you by our friends at Firehydrant. Firehydrant is the reliability platform for every developer. Incidents impact everyone, not just SREs. Firehydrant gives teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. What would normally be manual, error-prone tasks across the entire spectrum of responding to an incident,

this can all be automated in every way with FireHydrant. FireHydrant gives you incident tooling to manage incidents of any type with any severity with consistency. You can declare and mitigate incidents all inside Slack. Service catalogs allow service owners to improve operational maturity and document all your deploys in your service catalog. Incident analytics like extract meaningful insights about your reliability over any facet of your incident or the people who respond to them. And at the heart of it all, Incident Runbooks, they let you create custom automation rules to convert manual tasks into automated, reliable, repeatable sequences that run when you want.

Create Slack channels, Jira tickets, Zoom bridges instantly after declaring an incident. Now your processes can be consistent and automatic. Try Fire Hydrant free for 14 days. Get access to every feature, no credit card required. Get started at FireHydrant.io.. Get access to every feature. No credit card required. Get started at firehydrant.io. Again, firehydrant.io. so super base is open sourced can you explain to us what all that means because open source all shapes and sizes and software many facets surely there's some aspects that aren't maybe

or maybe not maybe it's all open open source, and then the business side. Let's dig into that. The whole VC-backed open source company thing is fascinating. Yeah, as you point out, everyone's choosing a different flavor of open source these days. Basically, for us, everything is open source except for our platform code. So you can sign up to superbase, app.superbase.io, and you can launch a database or multiple databases, whatever you want. All that sort of orchestration code is closed source,

it's proprietary. Anything else, if you want to self-host, you want to put the dashboard in front of your database, you want to put all the components in front of your database, that's all open source. And quite particularly, we try to, well, we do, we ensure that we choose very OSI-compliant licenses, MIT, Apache 2, Postgres, anything along these lines.

One other thing I thought was interesting too, as I was doing some research, was just the flexibility, I guess, this model gives to those who would use. You can do a local machine, you can do the cloud service, which is what you're talking about, the platform code, or even as a Docker container. So you really you can do a local machine, you can do the cloud service, which is what you're talking about, the platform code, or even as a Docker container.

So you really have, from a user perspective, the highest advantage, which is really open source. The mantra behind open source is adoption, right? I can put something out there and one person can use it and get value or everybody can use it and get value.

And I think that's kind of interesting that you're so flexible that you can do local cloud service as you do or a container and just giving the user base that kind of flexibility to be so restriction free. For sure. I mean, we get a lot of people who want us to integrate. They want to integrate with us or we don't really have a marketplace or integration platform. The thing that really holds us back is that usually if they're proprietary tools, then you can't run it on your local machine. You can't stick it into the Docker or you've got to sign up for a proprietary API.

Even this is quite difficult with Stripe. We'd like to do a lot of stuff with Stripe to make it easier. But, you know, it's all web based and you can't sort of emulate all of Stripe inside your database. But with Superbase, everything, you could literally run it on an airplane with the Wi-Fi off and you can start building your app in the airplane. So yeah, that's a huge developer productivity gain. How did you get to that thinking?

Did you stumble into it? Did you hack your newslet one day and put up a tagline and get there? I mean, how did you, was it following the Firebase way by any means? How did you stumble into this model, this thinking? No, I think that's just how I've always developed. So in our first startups, I just would never have chosen tools

which you can't run in isolation for the team. And then in my second startup, I sort of iterated on that and found better tools. So I think it's just how I've developed for a while. Here's a hypothetical. Let's say you wake up one morning and you check Hacker News. And the number one story on Hacker News is AWS now runs Superbase. I like this hypothetical.

What do you do next? What's your next move? It's a good question. Well, first of all, they're already trying. Oh, really? Not Superbase. They've got a product called Amplify, which is their response to Firebase.

And it's not great. Okay. It's okay. Well, it's as good as AWS developer experience, right? If they did, then like run all of the tools. The thing is we're a suite of tools as well, right? But they're all open source, right? Yeah, they're all open source.

So they'd have to- So they can package that all up and, you know. They could. AWS-based. That's true, that's true. As a service, Superbase as a service. I'd find it quite flattering. Maybe a SaaS company.

I'd find it quite flattering. I think ultimately, you know, we're going to go with a much better story, multi-cloud, open source, local emulator. I think there's no chance of us relicensing. I mean, Postgres itself, we don't own it, right? We can't license it. Postgres is part of a sort of committee now.

Yeah, we maintain it, but it's not ours. We don't think of it as ours. We would be happy to do that with a lot of the tools that we are developing as well. All right. So what if they did, though? What if AWS Base was out there? I like that, Jared.

That's a good name, AWS Base. AWS Base. So I guess the question really is like, not so much, you know, one, flattering. Sure, of course. But, you know, how maybe from a business standpoint, did you design things to compete with the behemoth, the Goliath? Well, yeah yeah i don't know to be honest does it even matter does it even matter the probability just seems so slim i mean

and even if they did they've got to keep up with all the stuff that we're developing as well right you know i just it doesn't really work for our model it works for like single servers or something like that i just because you're a suite of tools, it's harder to put together in a way that's cohesive, perhaps. It might require more work than AWS tends to put into these things. No offense to them, but it seems that way. I get that. I think the more successful you become,

I think the probability of something like that happening goes to one. But you can fly under the radar for many years. And I think if your answer is we're going to out-compete them, which it sounds like what you're just saying is like, well, we're just going to be better. We're not going to do the relicensing thing. You definitely have chosen this path. And I appreciate that you

say you respect Postgres has its own IP, its own copyright, its own licensing. And you're building around that. And so, yeah, I mean, what else are you going to do? You just got to compete at that point, I guess. For sure, for sure. We'll do better product lines, better developer experience,

better taste. I mean, they'll never be, I mean, AWS just doesn't have it in their DNA. I mean, go on our website and you'll just know straight away it's just not an AWS product. What about the other side? So that's attack from the behemoth but what about attacks from the scrappy scammy low moral people who are just like you know what i don't need to i can take the time to put the thing together they're putting all the work into it and so i can create a thing that is their thing only less work

i can focus on other aspects you know they can kind of hit you from the bottom. That's true. I think a good one in that regard was Sentry. I think a lot of people were relabeling Sentry. And it's actually quite an analogous one because they are sort of a suite of things that do a particular. Yeah, yeah.

I can see that probably happening more than AWS. I don't think it's a problem. I mean, we're just growing so fast. Good luck. Even other startups are not growing as fast as we are. So good luck anyone else who's trying to take us. I think it just forces us to be faster and better than them. If they take off some of our customers,

then by all means, that's not the type of people we probably want. I think, too, there's probably some sentiment in the community, and maybe not this may not be for the way everybody thinks, is that you've got to respect somebody's work, right? And while somebody may rip it off, it's open source. You're able to do that legally, so is that really ripping it off? Maybe, maybe morally, as Jared said, it is, but legally it's not. So this is totally a possibility. I think though,

there's a lot of, I would imagine the people you've hired are deep in the community. They've got their own respect. So it's not just the Superbase brand or just your brand, Paul, it's the people you've hired, the people that are involved in these committees, the people who are involved in maintaining these libraries that are open source and that commitment that people respect. And they'll read between the lines and see, okay, this is AWS base or this is whatever. And the EC2 people and the people that are inside of AWS may be like, you know what? I'll use AWS base because that's my ecosystem. But not because it's not super base. Or the flip side, the

moral ground might be like, you know what? That's a copy. We don't like copies. We're staying with super base. Yeah. The sort of really fundamental truth is, you know,

we're not open source as a marketing thing anyway. It's just, and, and I philosophically, I mean, someone would have been having this conversation with Postgres probably 20, 30 years ago when they were starting thinking, well, you're going to give it away for free, makes no sense but now it's an amazing product and probably

they had no way to capture value back then we do, I mean we can offer something that you can host for free and we can capture value so philosophically we wouldn't care if someone sneaks away a couple of hundred thousand dollars. The enterprise customers will never go to them. They'll go to the established, well-funded startup as long as we can manage to make it there.

On that note, then, what do you think is the, if you can say how you're capturing the value most, is it just being who you are and being reliable? What is it that captures the value for SuperBase today? Yeah, well, at the moment, most of our customers are the Jamstack crowd. So we work very well with Netlify and Vercel.

Anything that you're deploying as a front-end and you need a back-end, sort of a serverless back-end. As we push more into enterprise, maybe Jamstack will grow into enterprise, it seems to be. Given the recent fundraising rounds that we're seeing for Netlify and VSL then they might be more interested

but for now the pitch is developer productivity around Postgres our auth is becoming very popular with sort of the enterprise crowd so different parts of the stack support of course is the thing that enterprise customers always want. Uptime, SLAs, all the boring stuff. So the exciting stuff gets the Jamstack crowd in. The boring stuff gets the enterprise customers. So while we're on the

financial side, I noticed on the website you are backed by Mozilla. I've never seen that before. Can you talk about that? Yeah, that was a, I don't even know how it happened because there is actually a Mozilla grants program that was happening a bit. But when we were doing our seed round, somehow we got, they outreached to us and it's literally Mozilla the company. I think we might have been only one or two companies that they, or startups that they invested in and since then i have to say because actually it was around the time that you know they had um a bit of a org

reshake and downsizing the person who invested i don't think is there so i send emails and i've never never heard back from them so whoever it is in Mozilla, hopefully we're looking after your investment well. Yeah. That's interesting. I don't even know how that happened. We just, it just happened. Yeah, it just happened.

Such an interesting response to that. I didn't expect that. Talking about catching a flyer, like, oh, Mozilla's going to back us, and then gone. Well, in terms of popularity, I would say that I've heard Superbase way more, I would say, towards the mid to end of last year and obviously into this year.

I do follow you on Twitter, Paul, and I did appreciate the hockey stick you published, which I think was quite interesting because you published both the X and the Y axis. Sometimes these hockey sticks are just the, I believe it's the Y axis-axis and no x right they call that a Bezos chart don't they yeah Amazon's famous for not putting the one of the labels on their charts yeah I'll probably

if you start seeing me do that then it's probably for a graph that I'm not not so proud of I was gonna say it's a bad sign if they start taking away no no

I see it I see it all the time and actually I have been guilty of it but this one I just thought was quite flattering. Yeah, if the numbers represent you well, throw them out. Right. And the tweet essentially says how it started in January 2021,

which I believe the right side of the graph is at 5,000. And then this is the common thing versus how it's going now, which is January 2022. And the right side of the graph is pointing at 80,000. And I believe this is databases, right? This is total databases on Zubase in that time spectrum. Yeah, on our hosted platform. So hopefully there's a lot more self-hosted.

Right, so this is beyond what you can quantify. So these are customers, basically. Whether they're on the free tier or not. I was going to say, tell us about the free tier, because surely you're getting on there for free at least. But that shows interest. Right. Yeah, exactly. And developer tools is, I mean, very hard to do without the free

tier. They are famously not willingly paying customers. So yeah, we offer actually two free projects. They'll pause if there's inactivity, similar to like a Heroku type situation. That's because they're databases. Unfortunately, it's not like a static website.

We have to pay for compute. And that's why we couldn't have done it without VC backing, to be honest. We needed the cash to build our platform. So every free customer costs you money. You're obviously motivated to convert those free to paid or see them as adoption and growth and maybe they're a side project. You've been a developer for a very long time. I'm sure you can appreciate a free tier on a service.

I might have my side project on a free tier but my day job, I love Superbase and I brought you an enterprise customer through my day job i love super base and i brought you an enterprise customer through my day job for example so you never know that even though how this crossover can you share what the spectrum of that 80k might be just rough or exact if you want to be like of paying customers these are the ones where i share without the yxs okay yeah no no no it was a percentage we can't we can't derive the math just give. Okay, yeah. No, no, no. Give us a percentage. We can't derive the math.

Just give us a percentage. Yeah, but no, it's a valid point. I mean, a lot of people- How's business going, basically? How's business going, basically? It is, yeah. Yeah, well, it's going. First of all, there's one thing to note

is that we're still in beta, actually, even after two years. Because there's databases, we want to make sure that we've got complete stability, right? We just know that there's always going to be an 80-20 type situation. So there's going to be 20% of our customers who fund the bottom 80%.

And actually with databases, it's actually a long time before you start monetizing. I think it took Mongo six, someone can fact check this, but I think it took six years to reach 10 million ARR. I think that's the number I saw, which is a lot longer than most SaaS businesses. So we just know that as a database company,

it's going to take longer. But when you make it, if you make it, it's very hard to break into this market. Then the market size is just a lot larger than most other companies so that's what we're banking on and we've got the right backers to get us there and make sure we can get there yeah it's good to have the right backers in place too because like you had said you can move patiently you can move you can put something out as open source and not feel like oh gosh we, we have to get to, obviously the name of the game of business is to profit and sustain, right? But, you know, if you can, Jeff Bezos is a baseline, like Amazon lost money for many,

many years and look at the, you know, the juggernaut they are today. I mean, if you can see, if you could see that far in the future or a world where eventually or to some point that horizon where you get to profitability, you can be a lot more patient. And it certainly helps having the right kind of people in place, the right kind of backers in place that can give you the funds to grow like you said you need to have, but also that sentiment of patience. Yep. And we definitely have that in our current investors. And I think you get it when you do these big, audacious,

I mean, we're not going after Firebase, really. We're going after the oracles of the world. So that's sort of the longer term and all the Postgres hosting and database as a space. It's just growing ridiculously fast. So the pie is getting very big at the moment. We just want to make sure that we're in the game, ready to grow with the market itself. One of the things that Evan Weaver said, the CTO of FaunaDB, when he's on the show, is that everything is moving to cloud services and the database is kind of the last bastion of the on-prem or self-hosted world. It's been slower. It's been a burn. But it's happening.

People are starting to move there. Would you consider, I mean, it is a crowded space. I think there is huge opportunity. Like you said, it's hard to capture this. But when somebody trusts you with their data store, A, as long as they're in business, they're going to trust you for a very long time. So they're going to pay you for a long time.

And so loyalty is a big thing that makes churn lower, right? And unless your portability story is really strong, which your guys is, is like moving off is also expensive and a pain. So there's lots up for grabs, but there's lots of competition in the space. I mean, Fauna is one, Cockroach, you guys, Prisma, I think does data. There's a lot of people doing databases in different forms. Like you said, Firebase has been there, established 18 different sub-projects, maybe not your immediate competition. Who do you see as SuperBase's competition

in the database as a service? I know you're more than just database, but still. Yeah, ultimately we'll be going after the serverless database situation. So that could be, for example, Aurora aws aurora have a serverless postgres offering google also uh bringing out you know a similar offering a very good service at the moment is planet scale as well i think they're doing very good stuff for the mysql crowd so anyone who's doing this um cockroach no doubt well yeah well they're postgres compatible as well right not fully 100

postgres because it's sort of rewritten but i guess yeah it'll will definitely be bumping shoulders with these type of people you know as we grow but yeah really this market is getting very big and i can see there's not going to be a winner-takes-all type market. There's definitely going to be a lot of space. So you mentioned Jamstack people love you. Is a Jamstack developer a front-ender, JavaScript, not so much familiar with backend? Is that your ideal customer, or is it broader than that? Who do you think you're building for now?

I realize you change focus as you grow, but is a Jamstack person your sweet spot, or is it more full-stack people? What do you think about that? Yeah, for now, definitely Jamstack. We want to have people who probably aren't so familiar with databases in general. We just make it ridiculously easy for these people. And actually, it's quite rewarding.

We get a lot of people coming in saying, oh, I learned Postgres with Superbase. And we get a lot of schools, for example, who come to us and say, ah, previously I had to spend lessons teaching them how to set up Postgres. Now they can just launch, you know, a project on Superbase and they can start learning Postgres with us. So really, yeah, this is great because the technology that you learn on, you tend to stick with. So it forms into our patient approach. Eventually, yeah, we'll start targeting more established full stack developers, even people who really enjoy Postgres already. Maybe we'll win them over with, say, our road-level security,

a few of the things that we talked about earlier. What does transitioning look like? So let's imagine, since we have Change.com as an example app, we're a three-tier app with Postgres as a database, and let's just say we're interested in trying Superbase out. What would it look like importing, maybe it's pgdump, pgrestore? Is that basically the story, or is there more to it? I mean, I assume I would have to then access it through Superbase somehow or do I have a direct connection?

Just tell me how that works. Yep. So the process would be exactly that. You'd dump your database, I guess, restore to a public schema. You sound like you're using Elixir or maybe Phoenix or something. You can just connect that to your database.

We give you a Postgres connection. So the very basic, they were just like, hosted Postgres is like in a nutshell and then everything is added on top of that, but optionally. Yep. There'll be some, you can access your data through the dashboard.

You can see it, poke around. Then you can start using the APIs if you want. So either the RESTful API, we're building some Elixir clients. You might even use it within your Elixir application. We've got real-time APIs. So you might just want to listen to data popping out of the database for example small use cases then eventually hopefully you go all in on maybe the rest of the suite maybe our auth maybe the storage whatever you want so client libraries in many languages or how to or is there

a happy path it seems like you're all your stuff is kind of typescripty your docs and stuff yeah docs are typescript we've got a lot quite a few languages so officially we support javascript libraries then the community support the all the other languages then in terms of tooling we've got well yeah we use go typescript pascal for the We use Go, TypeScript, Pascal for Postgres, a few other things, I think. A lot of Alexa, of course, for our real-time server. Flesh out that story about the real-time again. You said you can just listen.

Tell us what that's for, what people are using it for, and how it works and plays with the Postgres side. Yeah, this one's very cool. I think it's one of the most unique features. I was using Firebase, as I said, in my previous company, and it was to listen to chat messages. You send a chat and then you receive it in a very typical situation. Then I moved it to our Postgres database and I was using Publish and Notify, if you know that inside Postgres.

I didn't realize that there was a hard limitation of 8,000 bytes. So I found an Elixir library that helped out a lot, but I built this engine where you can connect via WebSockets to your database and you'll just listen to the replication stream. So the write-ahead log sends events out of it. I connected to that with the Phoenix server and then I sort of decoded this stream

and then I blasted the decoded JSON into the WebSockets so you can listen to any change that's happening. And then, you know, we've just built out this functionality. We just released it with row-level security. So the rules that you specify on your table are adhered to on the real-time security. So for example, if you had a messages table and let's say you wrote a rule where only you,

your user ID could listen to message ID one and three, you could just listen to all the changes in the messages table, but you would only receive changes to message ID one and three because you're authenticated through the real-time server. Have you stress tested that thing at scale? Yep. Yeah, we did some performance testing on this one.

I don't actually know. I think it was 325 requests per second or something. Yeah, it's reasonably high, but we know we can get much better as well. One of the things in the benefit section of the Readme, which thank you for an awesome Readme, it says the beauty of listening, so to go back a little further, the beauty of listening to the replication functionality is that you can make changes to your database from anywhere, your API, directly in the database, as you obviously do, and then via a console. And then you still get those changes via WebSockets.

Yeah, this is cool because a lot of people do it in the middleware. So you obviously have to send it through the middleware, but you can connect using PSQL sort of and make a change that way and it still gets propagated. Yeah, that's neat because sometimes you get stuck where you're like, well, if we want this thing to actually be notified or enter into the stream, we have to access it through the app because the app is the one that does the whatever. Or we have to access it through the app because the app is the one that does the whatever.

Or we have to access it through this functionality, through the API. But because of where you built that functionality in, anywhere that you're accessing your database, that's going to get, because it's inside of Postgres, it's using pg notify, right? So it's right there, it's going to happen. You're not going to have a chance to miss it.

It doesn't use notify anymore. It uses the replication log, right ahead log. Okay, sorry. Which is kind of even lower level. But I mean, fundamentally, this is actually one of the things that we've learned is just very good for us to do. If we put everything right at the bottom of the stack

and extensions, for example, the GraphQL, we'll use row-level security, of course. Then we'll probably do subscriptions and things using that same, we call it Walrus, real-time write-ahead log security. So we'll still use that same functionality. Because it's right down at the bottom of the stack, everything above it benefits, right? So it just makes sense to code everything into the database when it comes to these fundamentals. So it's just becoming a very elegant suite of tools when we combine it with the REST server,

the write-ahead log, all these things combined become very cool. Because Superbase is in beta and just beneath the benefits is the server-guaranteed delivery of every data change. And there's some essentially limitations and warnings, basically. Like your database may run out of disk space due to the write-ahead logging. So there's a crash possibility, like treads around water.

Would you consider this in the same vein of beta as Supabase? Or is this ready to be used are you iterating on those limitations this one's probably slightly different um yeah every tool kind of has its own status right ultimately is it done or is it is this just sort of like a future what you love to have i mean like postgres of course it's it's not a beta product right it's it's very tried and true uh the real-time server, for example, it's very robust for certain use cases. You wouldn't use it for guaranteed delivery,

changed data capture, but we'll probably code that in. For example, we might do some sort of cache busting with it, in which case we want guaranteed delivery. So we'll probably code that part into it. But for connecting multiple customers to like multiple clients to the database and listening usually is for like message updates and things like this you don't really need guaranteed delivery you want almost guaranteed

delivery but it doesn't matter if the occasional message slips through they just refresh the page so in this case it's just, it's definitely a done product, but we'll keep iterating on the CDC part of it. This episode is brought to you by our friends at Subspace. Subspace is a network as a service that helps developers accelerate real-time applications for hundreds of millions of users worldwide. Their mission is to deliver real-time connectivity from anywhere to anywhere. When the standard internet wasn't built for the way the world works now, reliability has always been the main priority. But in a remote workforce environment and an uproar of real-time applications,

developers not only need reliability, but they also need speed. When every millisecond counts, Subspace gives you the fastest, most reliable network to route your traffic through. But the question is, how does Subspace do it? They developed a fiber optic backbone and hundreds of cities plus AI that weather maps the Internet in real time. This gives their network the power to find the best paths and pull traffic through them in real time. It's like a private carpool lane and GPS, but for dynamic Internet traffic. And it all works via global IP proxy that takes just minutes to set up using a simple API. No client-side installation is required.

And if that sounds easy, that's because it is. Learn more and get started for free at subspace.com slash changelog. Again, subspace.com slash changelog. And also by our friends at MongoDB, the makers of MongoDB Atlas, the multi-cloud application data platform. MongoDB Atlas provides an integrated suite of data services centered around a cloud database designed to accelerate and simplify how you build with data. Ditch the columns, the rows,

once and for all, and switch to the database loved by millions of developers for its intuitive document data model and query API that maps to how you think and code. When you're ready to launch, Atlas automatically layers on production grade resilience, performance, and security features so you can confidently scale your app from sandbox to customer facing application. As a truly multi-cloud database, Atlas enables you to deploy your data across multiple regions on AWS, Azure, and Google Cloud simultaneously. You heard that right. You can distribute your data across multiple cloud providers at the same time with a click of a button. And the next step is try it today for free. They have a free forever tier, so

you can prove to yourself and to your team that the platform has everything you need. Head to mongodb.com slash changelog. Again, mongodb.com slash changelog. So as a Postgres user who also speaks with a lot of database, newfangled database vendors, a lot of the stories that I hear about the architecture of databases have made me believe, I'm here for you to debunk or to agree, that a client server relational database such as Postgres

architecturally is not well suited in a serverless world. Your response, sir. What do you think about that? Do you think that's the case? Or do you think that that's just a small thing that you can work around or is it a big problem? Well, yeah, I mean, it's definitely not a small problem. So the experience right now for you, if you sign up to Superbase,

is we sort of scale your database for you. There's no sort of unlimited scaling, actually. There is some theoretical limits around this. And we will sort of work around these eventually. But what they're really getting to is, is there a cloud native Postgres? Right. So the holy grail really, I think the person,

or the company doing it the best would be AWS, Aurora, have the sort of serverless Postgres. It has a bunch of quirks as well. Really though, I mean, it's very hard to bet against Postgres. They know that there are some limitations around this. And we work around a bunch of these limitations with our existing tooling. So for example, one of the limitations is around connections and it doesn't scale so well if you're doing serverless directly to the database. So you've got to put a PG formula in place or something like that we provide a poomler for you

or if you just use our apis the http api you don't have any problems at all so really we're solved some of the problems of working with serverless and postgres then you've got to ask well how can postgres be serverless and this is the thing that really our business is going to gear up towards. Over the next few years, we're going to try, yeah, make sure that we can help with these efforts, build out a cloud native Postgres. We don't want to have run a fork of Postgres. If we do run a fork, it'll be to upstream as much as we can.

And there are companies, a lot of companies that are going to be working on this. A lot of people are interested in this, of course. Everyone thinks there's a lot of money in it from a commercial side, but even the open source contributors just know that it's something that Postgres needs to get to. So there's a lot of stuff coming in this space. Plugable storage is an interesting one. New storage engines for Postgres, fundamentally rewriting the storage engines to be distinct. Ways of combining

it with other, say, disk tools, maybe ZFS, things like these. So there are people working around it with clustering and things. So that's how we do it at the moment. But really, I've got no doubts, give it five years, Postgres will have some very cloud-native

functionality. What particularly about ZFS can you talk about? Because we're going to air, I think, before your show. So if you're listening to this, there's Matt Ahrens, one of the co-creators of ZFS was on the show. What specifically about ZFS is going to be solving to make it serverless? So that introduces a bunch of functionality

that you might want that other players are doing. So for example, a very good company is Postgres ai they use um zfs for doing and thin clones so you can clone a database basically in half a second it doesn't matter how big it is because you're basically doing this copy on right functionality which means that you can do branching your database so if you've got a production database you want to run a branch of it, then run a bunch of tests, then wind it down. That's how you would do it with ZFS. You can do a similar sort of thing with even snapshotting with LVM as well, but it's just a bit more elegant with ZFS. But I know of other companies who are completely rewriting it because if you combined Postgres with ZFS, then you've essentially got Postgres doing a storage mechanism,

ZFS doing a storage mechanism. So it's like double handling of storage. Ideally, what you want is it handled all inside Postgres itself. Even when you talked about the architecture too, to make Postgres serverless, you talked about like maybe an intent log or something like this. It reminded me of the ZIL, which is the, I don't know, I think what the ZFS terminology is, but it's like an intent log. Like ZFS intends to write this to, you know, its storage engine or whatever it might be.

I'm not familiar with all the necessary particulars of language and lingo, but that's what it's an intent to write it. And so like this log is a separate cache or it can be a separate cache. It seems like what you're building to make Postgres serverless is not necessarily converting Postgres to serverless, but adding services on top of it to augment and add to it. That may actually land in, you know, may begin because you're kind of user land technically, right? You're commercial user land that might actually eventually land in Postgres itself. Correct. Correct. And we will work on it with the community for sure. I mean, we've got the funding to do this and that as well as our intention. But for now, yeah, I mean, as you say, it's a really good term.

We're in user land and we're providing the tools that abstract all the difficulties of Postgres, including this sort of not being serverless. So we abstract all of that away so that people don't have to think about that and they just think in user land. And then it's up to us to figure out how to do really serverless Postgres so that if you get to 20 terabytes of data,

you don't have to worry. And from a, I suppose, database, I don't know, like Postgres versus mysql for example like you bolster the future story of postgres whether it benefits superbase directly or not because if people choose and prefer like jared does postgres like pride out of his cold dead hands i dare you just try it kind of thing you know then you're going to get people on the postgres side versus another side basically a mongo side a mysql, or whatever it might be. Because if they're in line with Postgres, then they're potentially a future customer, or at least an appreciator of the work you're doing

in the community, and even commercially. For sure, for sure. I mean, it's a huge benefit for us. A lot of people come in just because they like the fact that we're Postgres. I mean, an analog to this, which I think is at a smaller scale, was the NoSQL trend, which was kind of like, look what you can't do with your relational database without n plus one queries or whatever. And then Postgres, the community, and the core team reaction to a certain degree to that, which is like,

look at all these cool JSON tools we have built right into Postgres. It's like, my database can do that just as well, if not better, given these constraints, and et cetera, et cetera. That was an answer to a desire for a different style thing. Now this seems more foundational, and we're talking about storage engines. It's lower than a data type,

and I think therefore bigger of a lift. But I can see where you're coming from. There's money here. There's gold in them hills if we can figure it out. There's a lot of people with vested interests in Postgres, 25, 30 years of development on the software project. If you were to forget about the how and just tell us the what. So what would a cloud-native Postgres look like? Forget about how it gets done. What are the attributes? What makes it cloud-native versus not?

What's it missing? Decoupled compute and storage. So the idea is that you should be able to attach the compute part of it to a storage, hopefully like an infinite storage, like anything that is infinitely scalable. If you can do this, and in particular, if the compute can start up very fast,

maybe in, say, 100 milliseconds via, say, some sort of HTTP response, then that's cloud-native. And at that point, you can do geographic distribution of storage as well, correct? Yeah, well, okay, so that's an even... I like that laugh. Tricky, yeah, okay.

Then we're getting into distributed systems, so yeah. Well, aren't cloud-native systems kind of inherently distributed? Yeah, it depends whether you want like multi-master or a master and a read. So it really comes down to if you want to write your data well it's classic cap theorem right it is yeah i mean what you could do is that you write to one place the easiest thing is you write to one place and then you read from many and it could be even that you

distribute the data around the world by copying disk bytes from that point rather than the write ahead log sure so so that's one way to do it but if you have multi-master especially if it's like across the other side of the world then of course they have to have consensus about who's writing to the same row right that's another thing and i don't think that should be a goal for postgres okay although it is something that they're putting some pieces in place for this which in theory could lead to it but um i i think first thing should be that decoupling compute and storage is fundamentally the problem that needs to be solved so you think that that problem needs to and is going to be solved but the distributed

right around the world, because this is the promise of some databases, which are working very hard, and more money being poured into those as well, is if you can geographically distribute your data store alongside your applications, which have been geographically distributed, and you're basically edge computing in its entirety as close to the user as you can, that's the holy grail that

some people are pushing towards and you're saying that postgres probably shouldn't or won't get to that point in its current incarnation not for i don't think it should be its first goal i mean let's be honest latency on write versus latency on read you know you can cache read and you do that so that's the thing that really you want first and then you get into complexities around distributed systems which yeah it's just such a complex thing so i would far rather choose a tool and you have to choose you can't choose both so so i'd far rather choose a tool which had fast, you know, fast rather than, it's the cap theorem, right? So which do you want to choose?

Eventual consistency or strong consistency? Yeah. I'm remembering back to our conversation around Fauna, we had like, choose two. You can't have all three kind of thing with the cap theorem. Yeah. Yeah, but what Fauna is trying to do and claiming to do, and even the team inside Google, I think with Spanner, is doing this, is like, choose two, but also you can minimize that third one to be such a small occurrence that it's not a zero.

You're never going to get a zero or 100%, depends on which way you're choosing. percent of all three of these but we can choose to and then we can minimize the third one so small that it's it's not nothing but it's virtually you have all three yep and i think that that's a hard problem it's the kind of deep tech problem and i'm just curious if like that's on postgres's roadmap you know in this case you might choose for example to distribute a partition, for example, to distribute a partition. So for example, you might say, well, this user table is partitioned into geographic regions. And in which case you would route and you would say, well, this compute only writes to this partition. In that case, you could still do, you could also minimize it in this way. It's just going to have a single writer and you've still minimized the latency. if you know, well, all my European customers

are going to write to this table. Of course, then you have to have knowledge of your data. So it's just a very hard problem. Now you're in user land again. You're back in user land. Just to layer one more here for listeners catching up, I actually went to the transcript, which is always so helpful. Gosh, it's so awesome to be a user and consumer for a transcript as well as part of an authorship of them as well. But Evan said in that show, so the CAP theorem says that you can have consistency, availability, or partition tolerance at the same time. So just to kind of clear up what the three pieces, the three moving targets that you can or cannot have

and to which one you can minimize. But then he goes on and says, but we're trying to. So go listen to that one. It is an interesting conversation with a team that is trying to at least do what I described. I think the verdict is out.

I think they have working software and things they can show and they have customers and so they're doing some cool stuff. But whether or not that holy grail is landed, that's kind of up to implementation details and I think probably some subjective judgment and maybe some trickery on getting around certain things. Because at a certain point, it is all trade-offs.

What's cool about Postgres is the community. To me, there's so many people, so many smart folks. I love that Supabase is now added to that. Here comes a brand new, new in terms of the long run, startup story of people dedicated to making Postgres more awesome. How cool is that? Everybody benefits with the work that you guys are doing. Tell us about the Supabase community. Who's involved? Maybe even your team size now. Are you growing? Are there non-hired people building cool stuff with you? Flesh that out for us.

Yeah, there's a lot to talk about when it comes to community. The team is 35, fully remote everywhere. Then in terms of sort of non-core team we have like a squad of people that we pay through open collective as well for some maintenance and then yeah in terms of contributors yeah i mean a lot i don't know actually the numbers i think it was 275 on our main repo when i last looked but then we've got so many repos and there's repos outside of our organization, which we support with employees or otherwise financially.

So yeah, I think overall, hopefully we're leaking out and providing benefits to other people as well. Then, yeah, in terms of growth, I think if we take, well, maybe GitHub stars, if you use that as a metric, is going very well. Obviously a lot of interest.

I think for five consecutive quarters, we've been in the top 15 fastest growing by GitHub Stars. So yeah, I think I mapped it out on one of the days we are growing. Our main repo is growing as fast as React was when it launched, which is nice because React is by Facebook, so it obviously had a lot more eyes than we did when we started. I'm not sure if this helps you at all,

but again, back to your Twitter account. A recent tweet, you actually laid out some of your growth and one of them was contributors. You went from 88 to 271. I'm not sure what that's in reference to, but you did just say that you're getting started. So contributors at least based on your tweet was 88 to 271. I'm not sure what that's in reference to, but you did just say that you're getting started. So contributors at least based on your tweet was 88 to 271. I'm not sure when 88 was, but 271 may jog your memory. Is that for the start of 21, end of 21 kind of a thing? Yeah, it must have been start of 21. In 2021, we grew by X, I guess. Yeah, I guess the year.

It's good to be in growth mode, right? I mean, that's the exciting time, right? Growth mode is fun. You can attract new talent. You can attract, obviously, new awareness to a certain thing. You're in a great place to, I guess, tackle hard problems. New funding, of course, as you have done this past year. It's a lot of fun as well because we do one thing quite unconventional. We got the idea of Cloudflare, actually. We launched in beta at the end of 2020 and it was very successful, but the team was exhausted. And we got together and we thought, well, beta was pretty cool, but how can we do it even better? And we decided that we'd launch one thing every day for

a week. So we did our first launch week in March last year, and then we loved it. We did another one. And then we did another one in december so we did three launch weeks last year where we launch one thing every day for a week but usually on friday we launch even three things wow so i think it really feeds into the growth but it's also a lot of fun for the community because you know they get to see all the stuff we're shipping it's a bit hard for a lot of people say oh you know how are you doing your growth and i tell them this and they might try emulate it but the truth is we've just got so much to build that we kind of have to pack it into a week otherwise it's it's it's uh not getting seen so that's really why we're doing

it that way can you break down maybe your most recent launch week like what those things were kind of encapsulate what what some of the things might have been when you say things. What do you mean by that? So launch week three, I'm just pulling it up because I can't remember. On Monday, we always did community day or we started doing community day where we usually spotlight on Postgres, Postgres or any of the tools. Kong as well as another service that we use outside. Dashboard on Tuesday, we launched the dashboard open source. So part of the stack was closed source

and we just made sure that it was completely open and MIT licensed. Wednesday, real-time updates, we turned on road-level security for the real-time server. So previously it didn't have those rules and we released that. Thursday, we acquired a company, LogFlare. They are for ingesting logs, but we sort of wanted to feed into our server-side analytics platform. So you can

query your logs using SQL through your Postgres database. And so we acquired LogFlare to do that. And then Friday, one more thing, actually it was three more things, was the GraphQL extension, a CDN that we have released. We also released some updates for our super-based functions, an egghead course, and a hackathon. So yeah, it's quite a lot. All in a single week. How do you motivate a team to deliver that? You had said some timeframes.

It's obviously not back-to-back month-month, right? You're going to span it out like to quarters, right? Like that's a lot of a marathon. That's a lot of a sprint really than the typical marathon you might be in as a business or as an engineering team. So for example, we'll get together, I think probably next week as a team, and we'll plan out maybe five features that we want to launch and we'll work towards a date. It'll be the end of March

again. And then we have this fixed timeline variable scope mentality. So usually what happens is maybe some other things creep in, some of the things that we plan fall out the other side, but we just know on that day or the week before we'll do an internal launch. And then in that week we'll launch at least five things. What do these launch weeks do for growth? They've got to be great for marketing. I mean, this is like the work in public kind of situation, right? You're on Twitter, Cloudflare really got a lot of benefit from that too. A lot of PR and fanfare from like, hey, this stuff is happening. You pay attention like, hey, it's Monday, it's Tuesday, it's Wednesday. And each day there's something new. What does that do for maybe morale and growth

on both sides of the spectrum? Yeah, I mean, usually what happens is that it's got this compounding effect. So maybe if you get, you might get on, say, GitHub Trending. I don't even know how that algorithm works, but somehow we get on to GitHub Trending usually on these weeks.

Or on Hacker News, we try to make sure that we're always publicizing the Postgres stuff on Hacker News. So people will see it, Superbase, multiple times that week. Twitter actually is the main channel for us. So just people get this sort of flooded Twitter feed of Super base mentions or launches. So that's always good just to make sure that we're top of mind during that week. Well, clearly you got some inertia behind you. Clearly you got a great team behind you.

You got a great seat of investors who are patient with, you know, and even considering your outlook and how you approach the market, probably care a lot about open source, which is great to have. Otherwise you'd have probably said no. Yeah. Right. Like I like your money, but I don't like your ideas kind of thing. Yeah, definitely. You know, even when you pitch and you don't get accepted by Sequoia, you still get something out of it. So it seems like you're, you're turning all of your,

all of your experiences into the positive, which I think is a positive thing. Yeah. Yeah. Well it's startups, right? You've got to have gotta have you're gonna be fairly optimistic yeah anything in closing anything we didn't ask anything we left on the table that you want to mention here in the closing no i think um the usual marketing stuff right so uh i guess just go check out our twitter at superbase our superbase.com if you want to try it out but But also, I think the thing that's really helpful for us is people leaving feedback. And we've got this little feedback widget. If you use it and you write a little note, I read every single one of these notes.

It's useful to know about any product ideas that people have, especially while we're in beta. So yeah, if you do try us out, definitely make sure you leave some feedback. I'll read it. And if you shout out to me in particular, I'll email you. Nice.

Get a nice little direct line to Paul. Well, Paul, thank you for your time. And really thank you for, I guess, fighting the fight of being an entrepreneur and building this company and pushing Postgres forward. I know whether we use Supabase directly or not, there's some fruits for us to even enjoy here at ChangeLaw. So we appreciate that. So

thank you for your outlook on the marketplace, what you're doing, and appreciate your time here. Thank you. Thanks, Tim. That's it. This show is done. Thanks for tuning in. in do us a favor share the show with a friend if you got some value from it and of course thank you to paul copplestone for sharing his time today such an awesome conversation about superbase postgres the future of databases what developers need and so much more i loved it and if you love the two share that sentiment in the comments links are in the show notes. And I mentioned at the top of the show, our master feed is where it's at.

And I wasn't lying. Everyone, even me, I listen to the master feed. Check it out at changelog.com slash master. Get all our shows in one feed. Again, changelog.com slash master. And for those super loyal Love love us forever fans out there, I bet it's you. Check out changelog.com slash plus plus.

That's our subscription. You don't have to do it, but if you don't like our ads, or you don't want our ads, or you just want to support us, that is the easiest possible way. I would venture to say sharing a show with a friend

is the best bet for me. I don't want your money. I just want you to be happy with our shows and share them with your friends. But if you like our shows that much, hey, changelog.com slash plus plus is there for you. Once again, big thanks to our friends at Fastly for making our MP3s fast globally all around the world. If you downloaded the show, I know you did. I did too. It is fast because of Fastly.

Check them out at Fastly.com. And I can't end a show without thanking Breakmaster Cylinder. Our beats are awesome because of Breakmaster. Thank you so much, Breakmaster. You are the best. That's it. This show's done. Thanks for tuning in. We'll see you next time. Outro Music