It all starts with Postgres

We’re here with Paul Copplestone. From Supabase. Back again… Paul, last year almost this time you quietly went public… But not really. And the reason why I bring that up is because, one, it’s funny; you tweeted about it… And I borrowed your tweet, put it in our news… Because you were off that week, Jerod.

Yeah.

And to this day, it’s got double the listenership and reach of a normal Changelog News episode. Almost 40-some thousand listens of that episode. So when and if you go public, it will be big news, apparently.

This is why big news works, you know? Because people tune in for fake news. Paul, flesh out that story for everybody.

Well, basically what you’re talking about is that one year ago we appeared in the Time Square as part of the Infrared 100. This is Redpoint’s kind of top 100 companies. The funny thing is literally yesterday I also tweeted the same joke, because I’m not so original… So it’s really funny that you bring that up. I thought that’s what you were talking about. And I’ve had so many people reaching out in my DMs congratulating me on becoming a public company… But the second tweet, of course, is “Hey, I’m just pulling your leg.” But yeah, I got a lot of people – I called a lot of people out.

We got a lot of people, because I did the same thing. I followed your joke in our news… So we have a show called Changelog News. This is meta for those who already know, but maybe a primer for you… It is both a podcast and a newsletter… And occasionally, Jerod needs a week off. And I’ve done it, I think, twice. That was the last time I did it. And I’m like “You know what? I think our community will like this headline. They’ll get that it’s a joke, they won’t be upset, but it’ll be fun.” And so it’s kind of clickbaity, because we literally said – we put the flame emoji and said “Supabase quietly went public today.” And that’s what happened.

Nice. Well, for those listening, Supabase does not take itself too seriously. So this is basically how we operate on social media all the time.

Yeah.

So I’m sorry for the same repetitive jokes, but… That’s also how we operate. We’re not so original.

That’s okay. I mean, Jerod, you’re a really good re-user, and I guess taker-backer, if that’s even a phrase, of the memes that you put out, that others have tried to take from you…

Oh, yeah.

…and I think you’ve put them into the newsletter, and put them on LinkedIn more, to be like “This is mine. I was the OG of this one.”

[00:07:51.13] Yeah… I appreciate original memes. I also like the remixes, so I have no problem with recaptioning an existing meme. That’s totally cool. The only thing I don’t like is just blatantly posting somebody else’s meme as if you came up with it… Which has been happening to some of my old memes; I kind of stopped making them eventually… And somebody’s just been posting them on X as if they created them. And I’m just like – I’m not gonna really react to that, but I’m actually gonna go ahead and start reposting some of my old ones, because they’re still kind of funny… And why not reuse them [unintelligible 00:08:19.14]

That bug one, though… That bug one looking into the mirror was like –

Did you like that one?

I loved that one. That was so cool. Just since I mentioned it, give context, please. What is meme? Just for context.

The bug one?

Yeah, the one with the moth looking at itself in the mirror.

Yeah, so I found this picture of a moth just happened to be on – somehow it’s on two legs, and it’s in front of a mirror. And I was pondering what it might be thinking about. And I assumed that it’s doing its own daily retro at the end of the day… Kind of a remix of the old Stormtrooper meme… You know that one, Paul? Where he’s at the dinner table with his wife, and he’s saying “I knew those were the droids that we were looking for.” It’s like kind of that moment… But I figured this is like a bug’s life, you know? And what does a bug at the end of his day? Well, he’s reviewing how well he did that day. Like, how many failures did he cause, did anybody find him… Because bugs are out there to cause trouble. You know that, Paul.

I’m gonna find that meme, and I’m gonna repost it without changing it at all, and I’m gonna take credit for it. That’s great. [laughter]

If you could repost it onto the Times Square Jumbotron, that’d be spectacular. I would allow that.

Well, speaking of big, let’s laser in on this tagline. I think the last time we talked to you this was not the tagline. I think it was like the open source Firebase kind of alternative was your tagline on your homepage… I don’t know when it changed, because I’m not a stalker, I’m not on your website every single day, but “Build in a weekend, scale to millions” seems like a big promise. And you tweeted this recently, and I didn’t know you were gonna share this, but this is where I wanted to begin, which is like, how true is this promise? How true is this for a brand new startup, a greenfield, or maybe an existing – like, who comes to Supabase and gets to build and deliver on this promise of “Build in a weekend, scale to millions”?

Yeah, I did a tweet about this a few months ago, and the tweet kind of just says “Well, it’s not hyperbole.” There have been, I think at the time – I don’t know the exact numbers now, but at the time there were 12 companies that had literally started on Supabase, zero users, and scaled to over a million users on Supabase. Some of them many times more than a million. And so yeah, it’s happened numerous times… And no surprise that most of them are AI applications. I think it’s kind of more of a b2c type model to get a million users. The other two might be gaming ones, I think it was.

So yeah, I mean, now, it was ambitious putting that title, I guess, a couple of years ago… But now we’re quite comfortable with that. It’s really what we wanted to deliver on, and we’re quite happy that we’ve been able to.

So the last time we had you on it was like two and a half years ago; you had just gotten started, you were the open source Firebase alternative. Of course, that episode’s called “Supabase is all-in on Postgres.” You were all-in on Postgres; it seems like you were still all-in on Postgres maybe even – can you go more than all-in? I don’t know, you were giving it 110%. And you’re still open source, and doing that whole thing, right? Have you changed your stance at all? Because in the meantime we’ve had this “rug pull, not cool” situation over and over again, where companies are now formally open source, now some other alternative to open source… And they’re very much playing the same game you’re playing, which is like found a business around an open source tech, and try to go big with it. Are you all-in on open source still? Are you rethinking those decisions now?

[00:11:48.20] No, there’s never been a second thought on the open source. I think the thing is – I don’t know if I’ve described this in the last one, but there wasn’t really even a conversation about whether we should be open source with my co-founder and myself. It’s just that philosophically we are kind of open source people. I wouldn’t want to work on or in a company that is not developing open source. And obviously, people question around “Can you commercialize?”, but we’ve derisked that for ourselves. We’re quite happy we’re making revenue; we’re doing it in a very good way, we’re giving back to the open source community… And at the end of the day, as you point out, it’s Postgres that we’re really betting on. Postgres itself is just a phenomenal open source tool, so we’re happy to contribute back where we can, and really just focus in on building the tooling around it, and going deep on some of the things that could be useful to have in the future of Postgres.

So is the entirety of Supabase open source? Could AWS stand up Supabase as a service and do what it has done to many other offerings in the past?

Yeah, so the way that Supabase works is that it has multiple services… And you can think of them – it’s kind of a product design philosophy. You start with the database, and let’s say you’re going to build the next Instagram… What you need is probably some way to log your users in, and then maybe somewhere to store the images… So the way that we think about the product is you start with the database, and we offer these optional tools on top. You can just use the database, like RDS, or you can also use some of our other tools like auth. With the auth product it stores the users in the database. With the file system, if you want to store images, it will store it to S3, but it will map the directory into your Postgres database.

So you can think of the platform as a Postgres service, but then Postgres becomes the substrate for all the other services on top. You don’t have to use them, but you can. Yeah, so each one of these services is all open source, and you can tie them all together with a Docker Compose. It’s got a nice dashboard… All of this is open source.

So the question “Could AWS take it and host it?”, it’s not like taking, say, Mongo, or an Elastic Docker image. It’s actually a full suite of services that we run. And so I think it’s much less likely. And in fact, we work quite closely with, say, the RDS team on a lot of postgrads tooling.

Right. It’s kind of smart that way.

Yeah. That was kind of like – your question was kind of my question, Jerod, in a way… But more benign. I was gonna say, if you were to not – like, with the whole “rug pull, not cool” situation that’s happening over and over again, what would make… You’ve already said you wouldn’t, but let’s just hypothesize that you might, or you would; what would happen in the market to make you want to no longer bet on open source, and no longer be – what would threaten that for you, I suppose?

Well, I imagine the only thing would be I would be fired and replaced as CEO.

[laughs] So if your board of directors turns on you, or something.

Yeah. Which is not a problem at this stage, and I don’t foresee it being a problem.

So what you’re saying - as long as you’re in the seat, open source for life.

Yeah.

Good. Okay.

I think that’s a good product strategy. It’s kind of like just make it painful enough for them to do, so that it’s unlikely that they’re going to do it or benefit from it. And if they do, let the competition come. What about on the self-hosting side? Are there opportunities? Are the people self-hosting Supabase? Because that’s an enthusiast market; it’s not a scary, giant, crush-you market. Are you servicing that? Because it seems like you make it harder for AWS, just because – not because you want to, because of the nature of what’s Supabase is… And you also might make it harder for self-hosters.

Yeah, well, a ton of people self-host Supabase.

Really?

[00:15:46.00] I just literally got off a call before this, chatting to a guy who’s self-hosting on GovCloud, for example. And we don’t have GovCloud. So this is the beauty of open source. I mean, we offer it cheap enough that you probably wouldn’t bother to self-host it, especially for like indie developers. Some are more frugal. I mean, our lowest tier – you can use it for free, and then our lowest-paid tier is $25 a month. Now, does anyone want to manage a Postgres database, have a fully-managed service? $25 is pretty cheap. So for a lot of people, they’ll just pass that $25. For some, that is too much, and they’ll self-host. That’s fine. I mean, it’s not like we would have made money off them. We would rather that they used the product, or they contribute back to open source… And so it’s – part of the community, we can give them things for free,a nd we can support them, and they can support us back in different ways.

Gotcha. But for them it’s a matter of Docker Compose. Basically, tying together all the stuff that you all tie together on your production platform.

Yeah. The official support is just a Docker Compose, it’s a couple of commands. The guy on GovCloud, for example, was using a community-developed AWS. It was actually developed by someone at AWS, and it lives in our community organization… And he hacked it around, and spun everything up using that. So there are different strategies, some community-developed, some officially supported by us.

What is the path to self-host Supabase, if you wanted to? Lik, just to tickle – I don’t know if I like that word. [laughter] Just to appease those who are –

Don’t tickle us.

So I made myself laugh on that one… Just to appease those out there who are thinking “You know want? I want to tinker with this. I just want to play with how to self-host it.” Not to literally do it, but what is the path to self-host?

Well, yeah, I’ve got a five minute video if you want to sort of follow along on YouTube…

Sweet.

…which is really easy. I do it on a Digital Ocean server, which obviously has Git installed.

Could you change that to a Fly server?

Yes. Yup. Yup. In fact, we work with Fly…

That’s why I said that.

Yup. So yeah, you can use our – we’re just working together with Fly now to build a managed service. But actually, you could use Fly to host all of the services yourself, if you wanted. Each of the services is a Docker Compose image, so… Sorry, each of the services is just a plain Docker image, and so you can host it anywhere you can host Docker.

So why don’t you let all of us catch up on exactly what all of these services are? I think you enumerated a couple of them, but… How many Docker containers are there, and what are the individual services that y’all offer on top of Postgres?

Yeah, so it’s easier to think in terms of the product suite. We have a Postgres (obviously) server, and that comes bundled with a bunch of extensions that we need for the platform. These are the things that developers usually find useful; PostGIS, pg_cron, a bunch of the useful extensions.

The second and most popular second product is our auth service, and that, as I pointed out, stores all your users in an auth schema in your database. So it’s very useful, in that you can join your OLTP data to your users, and you don’t have to reach out to a third-party service.

The second one is the file storage. You can store images, videos… And it all stores to S3. It can be Minio or any S3-compatible service, and then it maps the directory into your Postgres server. And the reason why all of this mapping it into your Postgres server is useful is because for the auth service the way that we do authorization [unintelligible 00:19:46.23] is we lean really heavily into low-level security. And so if you want to restrict access to, say, some files, maybe a certain user that you’ve got in your database can only access their Instagram images. You just write a SQL rule, RLS policy, and that will control that access. So now you can see all of these services kind of start fitting together, even though they are individual services.

[00:20:16.21] The next one is an existing open source tool called Postgres. This has been around since the start. It autogenerates an API on top of your Postgres database. It exists as a separate community; we employ the maintainer of this to work just on Postgres. And so what you do is, as you create tables, it’ll auto-generate or introspect your database and generate an API for you, a RESTful API. We’ve also built a GraphQL extension inside Postgres, so you can use it for GraphQL, if that’s your preference.

And then the last two edge functions - these are Deno, if you know it… Deno is by the creator of Node, and it’s a TypeScript-native, almost like Node.js, but it runs in, say, a serverless environment… And I like to think of these actually edge functions as a bit of a strange term, but for us, the way I like to use it, and what we see most commonly being used is a background worker. So you can offload long-running, heavy compute tasks to these edge functions.

As a good example, our last product is a vector offering. And this is just PGVector and a bunch of nice tooling on top. So for example, if you’re trying to store embeddings, or you want to use embeddings, you want to do RAG, anything like this in terms of AI, you can use these edge functions to create the embeddings. And some Postgres services have this, in that you create the embeddings inside the Postgres database. We think that’s probably not always the best idea. Let’s say someone inserts a million rows into your database; you can trigger off a million asynchronous functions to create these embeddings, and then store them back into your database without, say, having really heavy compute.

Cool stuff. So the PGVector - is that something that you’ve added in a response to market pressures of late? Or was that already in your roadmap? I always think about, as a startup founder, building a suite of products, you have to decide where to allocate resources. And I think that roadmap - I’m sure, Paul, that’s probably on your lap, right? The roadmap is something that you’re highly involved in, if not directing in. So how do you make those decisions? And specifically, we can focus in on PGVector, which seems cool, and even existed prior. I think PGVector was around. But now I’m sure there’s probably people saying “Well, if it can’t do AI, I don’t care.”

Yeah, so PGVector is the brainchild of Andrew Kane. He’s a phenomenal engineer, and he’s been the one developing PGVector for - I think it has been around for three or maybe even more years. I don’t know exactly. The story for Supabase is pretty cool, because I got this email from a dude who said “Hey, I’m building this thing, and here’s what I’m building, and actually, I really need this one extension called PGVector.” And this was in February 2023. So it’s kind of before AI really kind of broke. So I looked at the PR, and it was awesome; really cleanly done. And so I jumped on a call with him and I said “Well, what are you building with it?”, and he showed me, and it was basically RAG. And I said, “That’s cool.” We merged the PR, and I said “Why don’t you help us build inside our docs a RAG-like thing where you can chat with your docs?” And this hadn’t really been done, and so he joined for a few weeks just contracting, and built that for us. We were really embarrassed that AI would hallucinate all the answers, and we were worried that it spit out a lot of things that were resolved in support tickets… So we called it Clippy, Microsoft Clippy, because it seemed like a bit of a joke.

[00:24:16.06] There you go.

And sure enough, it was a big hit, and so Greg, the person who emailed me originally, now works at Supabase full-time, and just started building out this vector product for us. And yeah, he was the one really responsible for putting that in front of me, and making sure that it was kind of on our radar. And we were lucky, because – and this is part of having a great open source community; I get to chat to people who are doing really novel things, and find where their pain points are. And he really needed this, and it was quite clear that it was a useful solution even for what I think of as day one problems… And so because of this, we were the first, I think, and – well, yeah; I know we were the first Postgres hosting company to offer PGVector.

That’s a cool story.

Break: [00:25:07.26]

I love a new laser focusing on the pain. I have so many conversations with sponsors, let’s just say, and sometimes turned partners to work with us… And that’s where I focus, like “Where the pain?” The way you get somebody’s attention, they way you get the marketplace’s attention is to focus in on the pain. What is the pain? And in this case it’s like “I want to do some cool stuff”, and this was burgeoning at the time… And good for you to hop on that call so quickly, because you were responsive as a CEO; also where the platform needed to go, what was coming up… And obviously, “PGVector’s already out there, but how can we leverage it to do this vector database stuff for the burgeoning AI things coming around the corner?” That’s a good example of great timing, but also good response time, too. Because you could have just not responded, didn’t care, or cared about something else that was less important… But you didn’t.

Well, you make it sound like I always get it right… [laughs] But I assure you, for every one that I got right, I’ve got a few wrong. So –

Well, there’s only so much of our time to go around, that’s true. But at the same time, this story was cool… And AI has taken over in a lot of cases… And back to – the framing of Jerod’s question was “Did you add this as a result of market pressure?” And it was a bubble-up; you listened to your community. And I think - back to even your harkening to the desires of open source for you, and that for Supabase to not be open source-focused would have to be you being removed as CEO. That to me is – that’s how you focus on great product, is you listen to your community. And that seems like a quality you have.

Well there’s this other piece that this particular product fits into. When I talked about most of those products, you would have noticed that they’re kind of standalone servers. And then the vector product, even though we launched it as a product, is actually an extension, and it ties together, like I talked about how to use [unintelligible 00:29:58.10] functions… You can use it with cron, pg_cron, you can use it with – we’ve got this thing called Database Webhooks, which is just another extension to trigger events out of your database to call the edge functions.

So these are all what I call or think of as the first-order primitives in terms of a platform. And Postgres is the substrate, then you’ve got these first-order primitives, and they’re the key products. But it turns out then if you combine some of these first-order primitives, you’ve got these second-order primitives. This one like vector is one of those second-order primitives. And they’re kind of jobs to be done by an engineer.

Another good example, which is quite popular on Postgres platforms, is queues. We could do queues inside Postgres, but also because we’ve got these background workers, the edge functions, they can be used too for the queues. Another really good one - we’re doing a lot of content around maps at the moment, PostGIS, and you want to store your… There’s a really awesome open source tool called Protomaps, where you can store all your tiles inside S3… And so because we’ve got storage, you can store them in your S3.

So you can see you can keep mixing and matching the primitives that we’ve called to release a suite of other kind of features or tools that developers need if they’re building. So we focus on what I think of as day one products at the start, and now we can kind of get these other maybe day 10, day 20 products.

Mm-hm. What are some other second order primitives that either you’re chasing, or currently exist, or are in the back of your mind as potential things?

[00:31:42.23] One that I – well, it’s always good, because [unintelligible 00:31:42.22] where it’s a win. One where I failed was workflows. I actually think of queues, and say database webhooks - all of these fit into what I think of as a category, as just web flows. A really good example was let’s say we could have an enterprise-grade Zapier. Temporal is good, it’s the type of thing that we want, but I think it can be simplified a lot.

So I can see a future where our edge functions have the ability to call other edge functions spawning off, and then storing the events inside your Postgres database… Or one actually that I didn’t talk about, that is going to be a much larger feature, is storing logs with Supabase. So we acquired Logflare. I think we talked about this the last time. We’ve open-sourced that. And this kind of logging service is going to become a really key part of the Postgres platform.

What was the failure? You mentioned a failure, but I didn’t hear what the failure was. Can we focus it on your failures, Paul?

Yeah, yeah. You wanna really dig into them, make me feel [unintelligible 00:32:42.06]

[laughs]

Just a little pain here…

Just so we can all learn from what you’ve learned.

Yeah. We announced this one, actually… So what happened is because of our positioning, our open source Firebase alternative positioning, at the start we didn’t have functions… And so we would do these launch weeks, and every single launch week people in our community would say – we’d say, “Well, what do you think we’re going to launch?” and they would say “Functions.” And we did this three times, and then they’re like “When the f- are you guys gonna launch functions?”

So I didn’t want to do functions, because we’re a Postgres company, right? I could see that our community were using – they were using Vercel, and Netlify, they’ve got functions, or people can use Django, that have their own middleware for doing a lot of this heavy logic. So what I thought that we could do is launch this workflow service. And actually, we developed an open source server for this, and it is an open source step functions, if you know AWS Step Functions. It maps exactly the same to their Step Functions language; that’s actually an open source spec. We created an Elixir library around it, and put it into our Elixir server.

The thing that I was hesitant about is I didn’t want to offer it, because I know how chatty workflow services are. They produce a huge amount of logs. And so I just didn’t think we could support it, and give a really good experience around it. Especially when you need to debug, there’s a whole bunch of things that you need to debug around workflows, especially if they’re long-running, maybe a year, and you’ve changed the workflow in between that one year when it was created, and now it needs to execute something… You know, you want to have a really good debugging story. So actually, we didn’t launch it. We announced that we were going to launch it, and then we pulled back on it.

Did you face any feedback on that? Had peopl forgotten about it? Did they care?

Yeah, people still say “Hey, when are you launching the workflow service that you announced?”

And what do you say them? “Maybe never”?

Yeah, exactly. [laughter] [unintelligible 00:34:49.14]

Right. “This is all so cool.”

Sleight of hand. “It’s over here…”

So what’d you learn from that?

Yeah, there’s a ton of things. I think – you know, I’ve got an idea for our platform, especially at the start. I had a really good idea of the tools that we need. And I learned that – we’ve already got, in my opinion, product-market fit. So when you’re a founder at the start, a lot of it is your vision, and you have to put something out to the world… And yes, your vision helps, but the more you go on and you’ve got users, the more you can kind of listen to them and just let them guide you. And yeah, as you pointed out, Adam, you just listen to their problems, and find the next incremental solution to that problem. So we might be inching our way towards a workflow service, but we might also never have it. If people don’t tell me that they’ve got that problem, then no worries; we probably won’t do it.

[00:35:54.07] The other thing is that our team is really competent now. We talked a lot now about my involvement in the product roadmap, but actually, these days it’s mostly the team. So I rely on them to tell me what is going to be the best solution in the world. And yes, I try to get involved; that’s the thing that I enjoy. But honestly, we’ve hired people that are much better than me at most of this, so I can just rely on them to tell me what good is going to look like. If anything, they’re probably annoyed when I say “Hey, what about this cool thing that we could build?”

Nah… Let’s not focus on that, Paul…

[laughs] Yeah, yeah…

We’re gonna do our own thing over here. We’re kind of in the details here. You’re kind of out there, Paul.

Right.

Yeah.

What is the team size these days? Like, how have you grown? How have you gotten to where you’re at? Obviously, you started from two founders, a couple of people… Where are you at now?

We’re at 85, and we’ve grown one at a time. So yeah, we try to hire only when we’ve really got a full-time role, a full-time problem, that’s kind of a hair on fire problem that no one in the team can solve. The thing that I usually tell people is that means we’ve had 85 hair on fire problems that we’ve had to hire around. We try to be very deliberate about who we hire. We are a global company, so we can hire literally anywhere in the world. I think we’re in 30 different countries. And we try to find the best person for any particular job. So if we’ve got that thing, we might spend – for example, we wanted to migrate to Nix all of our builds around Postgres. And I think that one took us seven months maybe, to hire the person…

That’s a long time.

That’s a long time. How do you go about hiring, then? I mean, you’ve got a pretty good personal brand in the marketplace… Supabase is cool… I think there’s a lot of things that go for you.

Meme game is on point…

Yeah, meme game is on point… You’re not taking yourself too seriously, but just enough… And you’re willing to pull back whenever you feel like it’s the wrong direction. How do you think you’re doing when you attract new folks? Is it pretty easy to get candidates? It’s probably hard to find the right candidate, not a plethora of candidates, right?

Yeah. And every role is different. I think we did a DevRel one, and we had like 1,000 people apply, or something like that. So some roles are very niche, and some of them are obviously much more conducive to our memes…

So yeah, what we do is just put a job out, put it on our social media… And we can also put it on Hacker News, because we’re a YC company, and that usually has some good eyeballs as well. We can put it out through the YC network.

We hire a lot, a lot of ex founders. I don’t know if this is still the case, but at one point I checked and we had 25% of the company were ex founders, so people who had started their own sort of venture-backed startup.

What do you think makes you gravitate towards that kind of person?

We don’t do management… So everyone has to be self-managed. And very competent. They need to – yeah, because we’re fully async, we don’t do a lot of face to face… So if you’re a product team, you actually only have to do one meeting a week, 30 minutes. That could be all the face time that you have to do in Supabase. Some people turn up to more, but that’s kind of the requirement.

So of course, with this little amount of feedback from people, you have to find your own feet within the company. And so… We’ve just found that ex founders are very good at this, especially when it’s a new product, new insight, something that we’re kind of launching.

I would think that ex founders would be good, but then they might turn, right? Because they obviously had had the itch…

They might get the itch again.

[00:39:49.03] I wouldn’t say failed, because you never know why they’re an ex. They could have exited and been like “You know what? Supabase is cool. I’m going here.” It’s not a point of failure necessarily to have ex founders… But I would imagine those folks tend to have the itch that doesn’t go away.

Yeah, there is that. I’m trying to think if we’ve had any ex founders churn… I think none of them have.

Oh, good for you.

I could be wrong. But because there’s another – this is a two-sided coin. The ex founders are the ones who appreciate our product-market fit more than the rest of the company, because they’ve been grinding on their own companies for the past however long; they know exactly how hard it is to get where we are. And this is not necessarily credit to [unintelligible 00:40:32.12] and to myself. A lot of it is just sometimes luck. We captured lightning in a bottle, and the timing was good… I could have launched this business five years ago, and it wouldn’t have done well. But there’s a lot of luck that played into it, and because of this, they see our traction, and they know that it’s a good thing. It’s not just something that they can reproduce themselves.

Are you a listener of this podcast, Paul?

Some, but…

I wanna recognize an episode for you…

I love when he just puts people on the spot like that…

I’m gonna recommend an episode for you; that’s why I asked you that. Because maybe you’ve listened, and you listened to episode 590, with Paul Orlando… We talked about “Good timing makes great products.” And we talked really about this whole timing mechanism. I think you’d enjoy that if you go back and – if you’re looking for one to listen to, let me go aheaed and recommend that one to you.

Cool.

There you go.

But you did mention product-market fit a couple times. You mentioned you believe you’ve got a good enough grasp on it to do - I don’t know what X might be, but you were kind of [unintelligible 00:41:29.21] that. So help us understand what is it that makes you feel like you’ve got product-market fit? What exactly has that been for Supabase, and what are you doing about it? How are you acting differently and growing differently and developing differently as a result?

Yeah, I think in YC they explain it like, you know, before product-market fit it feels like you’re pushing the boulder up the hill, and then after it feels like you’re chasing it down the hill. And that’s kind of the feeling. You kind of really know when you’ve got that feeling that things are growing fast enough on their own, that you’re struggling to keep up… And so I think we’ve got that feeling in Supabase, that we’ve got a lot of pull from our customers, our community, and various different profiles of customer as well. Some at the start that we had to say no to a lot, because we wanted to focus on a particular segment of the market to start off with. And now, of course, we grow into – as a company grows, you can focus on more and more parts of the market. So…

How do you say no to a free platform [unintelligible 00:42:30.28] How do you say no?

No, we said no to the big, attractive logos who might ask for a million things, and drag us around… So we tried to really heavily focus – okay, so the key insight. Let’s say you want to build a database company. There’s two ways you can think about it. You might want to go to the big enterprise and say Hey, that Postgres database that you’re hosting- don’t use that. Use mine.” And they’ll say, “Well, why? Why should we trust you?” And I think a lot of database companies have tried this strategy and failed.

The companies that I kind of most admire is MongoDB. They went kind of the other way round. They started on the developer, the community, and they captured this audience, and you’ll hear their CEO talk about it; new workloads, all the time. The idea is that you are the technology that a developer will choose, even before they really decide what they’re going to build. Then you become so good that they have no reason to ever scale off. Now, that’s a big bet. But so far, that’s the thing that we’ve focused heavily on, and why it took us so long to go to GA. We wanted to make sure that when we were ready for the enterprise customers to come in, that we’ll be ready to service also all of that profile of developer as well, while simultaneously servicing all of the enterprise customers.

[00:44:03.05] I like that strategy. I think there’s a certain humility to it. In fact, prior to this show Adam and I were talking and we were noticing sort of a lack of big logos on your website… Which is something that many service providers flaunt as if it gives them clout. And of course, it does, if Microsoft and Netflix and these companies are using you… That’s really impressive, and people might also trust you for that. But you leaned into the new business, the indie devs, the startups, you’re in YC, you have a lot of YC companies using you, so that’s cool… Also seems like a nice, easy sales path perhaps, when it’s like – I was gonna say “friends with benefits”, but that’s not what it is. Just like network folk; it’s kind of an insiders club.

Kind of. It’s kind of friends with benefits.

It works. It works. I mean, they’re starting software companies, you provide services to software companies…

They become the YC operating system basically, or part of that substrate that is today’s past, present and future YC companies.

Yeah.

Yeah. Which is cool.

Well, that’s kind of the goal. And it’s not to say we don’t have the enterprise logos…

I’m just saying they’re not on the website.

Yeah. I don’t think we put any logos on the website. [unintelligible 00:45:13.18]

Yeah, I noticed that. I was like “Wow, Jerod, there’s –” I mean, here on the homepage, above the fold, there’s only mention of “Build in a week and scale to millions”, “Start your project documentation”, what you offer, and the frameworks you work with; not at all – so very developer-focused. Not like sales, sales, buy, buy, marketing. It seems very focused on the pain, which is “Okay, if I’m using Vue, or if I’m using React - well, I see the logo right then and there, and I’m a developer, and I come there, and I’ve got a path where I feel like I’m at home, so to speak.”

There’s your logos.

Literally, all caps HOME, with a dollar sign in front of it.

Yeah. And honing that – I mean, you’ll see above the fold that all we talk about are the features that you get; literally, Postgres database, auth… It’s not trying to sell any benefits. It’s all tailored towards this developer profile. And that’s the thing that I think most people get a little bit too tempted to go too fast up market. And if you do that, of course, the first thing that happens is you lose focus on the ones like your community. So it’s been very tempting to do that. But we’ve been fortunate enough – I think this is one thing, that we’ve been lucky to have good backers, patient backers… And actually as well because Mongo forged this path before. There’s some prior art to show that it can be done.

I would say though this approach does leave room for, I guess, lack of marketing. I don’t know if that’s really the case necessarily. Like, there’s still that gap. It’s great that you have this approach and this lens you’re looking at things from… But at the same time, show me the product. Please. Don’t just show me the things you – like, the features, or the platform level, the product-level things, the database, authentication. Give me visibility.

And even when I go into, for example, the database page, you’ve got a graphic that shows a table, but it’s not the Supabse interface. It’s something that’s abstracted away from that. So I kind of still miss the “Show me really what’s behind the scenes there. Give me a real preview”, which kind of is marketing, and you’ve leaned towards anti-marketing, in a way… So I’d say there’s still a fine line there, where I still want to be shown and handholded, not just listed.

Well, if Johnny’s listening to this, there’s great product feedback.

[laughs]

Okay. I would talk to Johnny directly, and share more.

The correct answer is that that is actually being developed, a lot of this now, kind of more in the background. The way that we do everything at Supabase is this Kaizen approach, where we iterate on everything. So I think that database page probably hasn’t been touched in two years. And then what will happen is we won’t do an overhaul, ever. It will just be iterations, iterations, always iterations. We call it Kaizen, from the Toyota Production System.

[00:48:16.27] Never heard of it.

Just continuous improvement.

Yeah, never heard of it. Tell him, Jerod. Tell him.

Oh, we have a whole show called Kaizen, so we’re very well –

Oh, you do? Okay.

Yeah, yeah. It’s like a mini series.

We’ve adopted Kaizen as well, basically. Gerhard Lazu –

We’re fans. We are fans. But I do also confess that it puts you in this local maximum situation. Like, you’re just iterating on what exists, and it’s harder to say “Let’s throw that out and start brand new”, because you’re kaizening what exists, versus you have to kind of go up a level in order to Kaizen the entire business.

Yeah, that’s an interesting one, right? I was calling out Johnny on our product – I think that’s the thing that he gets most frustrated about. I just looked at one of his RFCs. We do RFCs internally, so I can comment on them. He did a video where he kind of overhauled the whole dashboard. And so I’m just picking the pieces that I like out of whatever he’s done, and I say “Okay, well, that’s good. That’s good.” Whereas I think he would love for us to do an overhaul, because even the dashboard kind of functions like it did at the start… And exactly as you say, we’re on this local maxima, which could probably be maybe five times better if we just went back to the drawing board.

Right. Yeah, it’s like, you could polish it up to like 99% awesomeness, but then, like you said, somewhere else there’s a different version that’s like 500% awesomeness, and you’re like “Oh, we never would have got there.” So… It does take balance, I think.

Yeah… Big sweeping changes are challenging. Are either of you Sonos users, or have Sonos in your house?

No.

Let me tell you, I love the platform, okay?

[laughs] Disappointment? Extreme disappointment.

Yes… [laughs] This is not a perfect one to one example, but this a recent example of major change that did not, in my opinion, go perfectly… And they have – they’re speakers, essentially, networked on your local area network.

Right.

And there’s an iOS app, or an Android app, or some sort of application that interfaces with the system that’s present on your network. And the application has traditionally been pretty good to use. It’s been kludgy in some cases, but they made a major change recently, which was visually seemingly better. They took away like core features. Core things I would do every single day in this thing. The sleep timer. I put music on in my kid’s room, and I don’t want that thing to play all day, and I come back the next day and the music’s still playing. That’s just silly. And I can’t even create a custom timer anymore. It’s just like silly things. They changed massively. So I kind of appreciate what you’ve done, where you sort of pick little parts, and you kaizen an interface, because a reimagining is sometimes good if what you had before totally was not good. But you’ve got to get some feedback. I don’t believe they got any feedback, because even to this day – Sonos, if you’re listening, the application, every time I launch it, it crashes first, then I have to relaunch it. So it’s like, come on, did you really fix anything? Did you just make more problems, and you took things away that was core? And I don’t see – sleep timers came back, but there’s certain things that are just gone forever. And I’m like “Why? Who did you test?”

Adam, you just got someone fired at Sonos.

I’m sorry…

You did… [laughs]

I don’t think so. Maybe…

Oh… Just spitting our bug reports into the sky, and hoping that they land in the right ears… I love it.

Yeah… Yeah. Well, that’s why Kaizen is good, right? You notice these small changes. And actually, it does work. I think it’s the least worst way of doing things. We’ve got this guy writing a book about Supabase actually, how to use it, and… A Supabase book. So he had links to this video that I did, a very embarrassing video from like April 2020, and where I’m demoing the dashboard… And it’s so starkly different from how it is today. And that’s only through just those incremental changes. So it does work, I think; it’s just that - yeah, you’ve got to be aware of the pitfalls.

You don’t see the change when you’re making the change, or you’re in the daily. It’s a lot like raising kids. I mean, you know your kids are getting older, because that’s what happens every day, but you don’t see the changes. But then somebody else who saw them this year, and then next year, they’re like “Holy cow, the change has been massive in the interim.” But when you’re just going through that daily iteration process, everything is just a minor change. So it helps to step back and do retros, and maybe congratulate yourself on progress, because it doesn’t feel like progress all the time, when you’re just making these minor, incremental improvements.

Break: [00:52:53.21]

Who do you see as your greatest competition right now? Because you have product-market fit, and you have adoption and stuff, but there’s also – I mean, Postgres is getting bet on big by lots of people. I’m excited about that. There’s lots of Postgres going on, and there’s the Postgres-alike or RDBMS world, which is close enough… And then there’s the NoSQL… But if you were to put yourself against competition, which I’m sure you’ve done your rounds of raising money and stuff or whatever, it’s like, who’s competing with you the most directly, and maybe even the best?

Well, the evolution of Supabase started as a Firebase alternative, and then kind of evolved more into a Postgres platform, and their positioning as well. So in the early days, when we started with this tagline, “The open source Firebase alternative”, there seemed like there was another startup basically every month using that same tagline. So yeah, we’re quite accustomed to competition. They didn’t really do it the same way that we did it, and so I think we sort of won that space largely because of our positioning, our earliness to the market, the way that we did the product…

Now, of course, around Postgres there’s a similar dynamic, in that Postgres kind of became the default database engine in the past four years, maybe even a little bit before we started… And so there’s a new Postgres company every month. So there’s a lot of competition in this space. Generally, we see this as a good thing. More developers in the ecosystem. There’ll probably be some consolidation at some point. Some come and go already.

But largely for us - yeah, our next focus, as I mentioned, MongoDB is a company that we kind of admire, and the strategy that they took. I think now that’s probably the next one that we’ve got our sights on. They’re obviously a very mature company, and they’ve done very well, not just from a product point of view. They have a phenomenal organization, their go to market machine is amazing… So yeah, we’ve got a lot of lessons that we can learn from them.

How do you stack up against Neon and folks doing serverless Postgres?

Yeah, so there’s a few others, some that have come and gone in this space as well, the serverless Postgres… And so yeah, Neon, a very interesting technology. They decouple the compute and storage. They do that by replacing the storage layer of Postgres itself. So that’s pretty cool.

So yeah, around this area we focused and we have been sponsoring and just recently acquired Oriole DB. We also have liked the idea of sort of offering different storage engines in Postgres. We like the table access method approach, if you’re familiar with this, in that – MySQL have this very cool thing called pluggable storage, where you can actually replace or use different storage engines for MySQL. And Postgres have something like this, and in fact some work was done many years ago, this thing Zheap, for Postgres. And the original work was done to add these table access method APIs for replacing the storage engine.

Now, Oriole DB is a Postgres extension that you can use, like a new storage engine that solves some of what Alexander, the creator of it calls “the wicked problems of Postgres.” But also, as a second piece of this, he has developed and submitted a bunch of patches to the Postgres core to develop the table access method, with the idea that pluggable storage can be one of the next big frontiers for Postgres.

[01:00:35.14] Yeah, that is cool. So do you know why the Neon folks are doing – because they’re actually patching, I think, core Postgres in order to replace the engine, like you said. Does Oriole get you eventually to where they are going with that complete decoupling of storage and compute? Are you able to get there with that? Or is there a reason why they’re not using this table – what do you call it, table access method?

Table access methods, yeah. Yeah, so we already have an experimental S3 backing with Oriole, and actually you can find – I’ve got a sort of thing where you can launch it on Fly, if you want, using Tigris as the storage for that. So that’s kind of cool. It’s already there if you want to play around with it. It needs a lot more work, and the way that it works in Oriole is that it’s more – it runs as a process, 20 processes storing the data from the local disk to the S3 store. And then as well when you fetch, it will kind of fetch all the data from S3 when you query it, and use that. And the reason why this is good with Oriole is because of the storage format. It’s a lot leaner, the amount of data, so less chatter between these two services.

The architecture in Neon is slightly different. They’ve got this kind of middleware service that they’ve got backing across all of that. So kind of like a cache. And so it’s a bit of a different model. In particular, I don’t know how much of that will ever been kind of upstreamed. It’s developed in Rust, so… Yeah, it’s a very cool technology. A bit harder for, I guess, a company like us to adopt as just kind of pure Postgres.

Another thought I had regarding Supabase, what you guys are offering, versus other ways of going about building things… It almost seems like you’re building an entire application framework on top of Postgres. You’re providing so many tools, so many layers, that of course are opt in or opt out, but work well together. And at a certain point, it seems like maybe your competition doesn’t become other database providers, but application frameworks like Ruby on Rails and Django. And I’m curious, just your thoughts on that first. Do you think that’s the case?

I’ve never heard it put that way. I actually think more that we are like a data cloud.

A data cloud. Say more.

As in what we would probably compete with is more cloud services on their data products. And you can use all of those; like Django, you can use it with us, and you can tie in… But our kind of overall mission is that if you’ve got data, it gets stored on Supabase. It could be OLTP data, or later on some OLAP data. We’re not fussy with how – for example, we’re very clean with our integrations. We’re very clean with our open source and protocol support. Our storage engine supports the S3 protocol, so you can plug anything on top of it, and then the services that we provide also work on top of that. So the idea is – for example, I’m a big fan of Iceberg, Apache Iceberg, the catalog format for OLAP. We’ll probably do some tooling around this inside our S3; I don’t know, so these are all futures where we’ll let our users drag us. But that’s where I can see some pull coming from our customers. They have a ton of data that they need to store, and it doesn’t always fit Postgres. So where are they going to put it? And we’ll help them solve that question.

[01:04:18.00] I see. So expanding beyond Postgres, with other services that are leveraging different kinds of backends, such as object storage, for instance.

Yup.

Versus layering on application logic. Maybe it’s the auth that throws me off, and some of the real-time stuff… But then you talk about workflows, and queuing, and background jobs…

This is great stuff, yeah.

…and these are all things that I’m thinking like “Well, my open source application frameworks provide these tools as well.” And so one thing is like “Well, do everything inside of Postgres.” And the other thing is like “Well, don’t make your database too smart, because now you are completely locked in, and subject to all the pitfalls of the database management stuff.” So it’s kind of like those two perspectives; that’s where I was kind of drawing the convention over configuration side, of like, you know, you could switch between MySQL and Postgres. I’m not saying let’s have that argument, but it seems like you could go that direction, or “Well, let’s use this awesome tool in every possible way.” That’s what I read from your guys’es blog, is like – the Supabase blog is like “Now we’re using Postgres to do this. Did you know you could – low-level security”, all this kind of stuff.

Yeah, that’s because we’re Postgres maxis.

Yeah, you are.

The way I think of our platform, and the way that people use it, there’s kind of like this spectrum. You’ve got people who are Postgres maxis, like us, and they love low-level Security, and they love all the things about Postgres. And so they get a real kick out of using Supabase. Then you’ve got all the “Use Postgres just as a dumb data store. We’ve already got our tools”, or maybe for legacy reasons they’ve already got their tools. So they might just use the database system, and sometimes they’ll use some extensions, or something. And then down the other side, like, the people who don’t even know how to get started with Postgres. And it’s funny, because the Postgres maxi and the Postgres newbie end up using the same set of tools. We’ve made the maxi tools so easy to use that actually when you’re prototyping with Supabase, you end up leaning really heavily into the stack. And sometimes people kind of merge more off the Supabase tooling… Which is fine, because maybe they find low-level security a bit harder at scale. But that’s cool, we’ve got flexibility there around our product. And yeah, those are the profiles that we see.

That’s interesting.

I think what you might be driving towards, Jerod, is there’s a lot of the platform that you can opt out of. You come for the database, you don’t have to use authentication, you don’t have to use storage, but it’s there, so why wouldn’t you…? But then even your framework may do some of these things, potentially better, but – I don’t know, you kind of lock yourself into it. What is it that makes people come to Supabase? Do they only come for Postgres, and they stay because they – is this a platform, I suppose, for Postgres maxis, as you said? …and if you’re a non-Postgres-maxi you’re still friendly, but like, well, you may have more fun elsewhere.

No, I think actually we’re more a platform for Postgres newbies. As I said, people who are getting started with their new project, greenfield projects, and they want to experience what Postgres could be. A lot of them actually – so we work very well with Vercel and Netlify, for example. JavaScript developers, they don’t really know how to use a database. Simple things like creating indexes might be a bit hard. So we’ve got a bunch of these advisors, like an index advisor, a security advisor, performance advisors… So you can do cool things like – I saw a tweet one day where someone just clicked… We’ve got this advisor that has hypothetical indexes. If you add this index, your query will be faster. And it will tell you a percentage how much faster.

[01:08:11.07] And I literally saw one day after we launched that product some dude had clicked the button and his query was immediately 98% faster… Just because he didn’t know that he was supposed to add an index to some query that it was running. And it’s all Postgres at the end of the day. We’re using the Postgres query planner, we use HyperPG, an extension, we wrap it, and we make a cool product on top of it… But it really tailors – we tailor the product especially to those type of developers. And because of that, you can still use it in a Postgres maxi type of way using PSQL, but the dashboard just makes it really, really simple.

And I think one thing to touch on on what you said - you said “Maybe you get locked in.” Actually, we’ve got a set of product principles in our docs; it’s one of the first pages that you read. Portability is one of those product principles. There’s two others that are kind of important here, in that we have – and they seem conflicting, but they work together. One is that everything is integrated, so it can feel like a single product, and then the second is that everything’s isolated, so you can use each product as a standalone tool. And the way that I typically describe this is a little bit like the Apple ecosystem. You can use your iPhone just as an iPhone, you can use your Mac just as a Mac, and you can use your Airpods. But when you kind of combine all of them together, you get this magical experience. So each tool, each of these things is kind of neat by itself, but combining them feels kind of cool.

There’s two other names, I suppose, for you, just to – tell me if they’re relevant or not. And you’re talking platform auth, databases storage… Appwrite is one of the names, and Convex is one of the names. I’m less familiar with all the permutations of Convex. They were both prior sponsors of our content, and I like both them very much… But they’re also kind of building this backend or this platform that has auth, databases, storage, functions, real time… I mean, you might even look at your feature list and theirs and be like “Well, that’s pretty much the same.” What they don’t say is “We’re open source”, that I’m aware of, at least for Appwrite… And they don’t proclaim Postgres.
As a CEO, as you’re leading, how do you, I guess, not get bogged down by the other options out there, and remain focused? Do you just simply listen to the developers that are building your platform? How do you not get distracted by others that are good players in the market, serve a good purpose? Because Appwrite is growing, and Convex is growing. I’ve talked to both of them before. They’re both respectable, doing great things. But you’re also winning, too. So how are you all winning? How do you keep winning?

Yeah, I don’t know. Well, more developers, I guess, is one of the answers… Yeah, I mean, honestly, we’ve got this lady on our board, Caryn Marooney; she’s amazing. And she says you should be – you know, driving a startup’s a bit like driving a car. You’ll focus most of your time on the road ahead, and then occasionally you look in your rear view mirror. And that’s kind of how we think of the competition. I mean, most of the time we’re thinking of, well, the people ahead of us.

So I don’t know, we don’t have a huge overlapping audience with those ones. I don’t see them often, at least, in some of the discussions. Appwrite we did early on, but at least it seems to have diverged. But largely for us we’re focused on the product that we can develop, not so much on the product that they can develop… And we know quite clearly where we want to be as a company, as a platform, and we want to make sure that we can deliver that. And it’s very – honestly, I don’t live in Silicon Valley. And when I go there, I walk away with a lot of fresh ideas, but also a lot of anxiety, because I hear all these things that people are doing, and I’m thinking “Oh, I need to do this as well.” And then after a couple of weeks away from Silicon Valley, I realize, “Ah, actually, not a lot of that was important.”

[01:12:29.05] And so the things that are really important kind of bubble up. You’ll see them… They bubble up to me without me having to hunt around, and even look at competitors. If they do something cool, someone will share it, so I’ll see it for sure. But it’s not like I spend time looking at their products or playing around with them.

Yeah. What about the teams out there that have chosen Postgres, they’ve generally hosted themselves? I’m describing us, by the way. They’ve sought after or longed for managed. We don’t want to deal with this anymore. We want somebody else to deal with all the problems of managing our Postgres. And they look at something like Neon, and you look at Supabase, obviously. When they compare those two – obviously, you’re doing more. The product direction is different. But you’re both Postgres. We understand that Neon is serverless, we talked a bit earlier about things you’re doing to go serverless, or potentially go serverless… How does someone choose between these two platforms? What are the things they look at or decide upon that makes them say “Well, Supabase is actually the better option for me”? What would make them say that?

Well, I can’t speak for all developers; everyone’s got different criteria. It might be feature set, as you said, different products, it might be directly some features within Postgres itself… For example, I don’t know whether this is true or not, but I believe that we can no longer run our real time engine on top of Neon, because it doesn’t have logical replication. I think they might have released it, so fact-check me on that one… But there might be some incompatibilities that developers need, so they could assess it on that.

The other things are just – I mean, honestly, vibes, community, marketing, support… We’ve got a really big community. And I think people like that. You can find content about Supabase everywhere across the internet. And sometimes the extra tooling helps. For example, we both offer PGVector; the ability to do embeddings in the edge functions I know is one of the reasons why people are switching to us, not just for PGVector workloads, but even from other vector databases. We see a lot of migrations over to Supabase for that.

I guess the question right back to you - I mean, how would you assess? I’m quite curious which criteria you would try pick a Postgres provider?

Yeah, sure. I’ll take the bait. I think that there’s some attraction to this idea of serverless with a database. I think when you think about price, that’s interesting. Now, I’m kind of biased, because I have a lens into the thought process, because they’re one of our sponsors… But at the same time, I don’t know more than the general public. I might just know more because I’ve investigated; I’ve done the research. And we’re also users of Neon.

I think the ideas they’re doing around developer workflows and branching is really – you know, Planet Scale kind of began this journey for that, but I think if you’re Postgres for life, you’re not choosing Planet Scale. But there’s good things happening around the tests, and there’s good things that’s happening around the core of Planet Scale… We’ve talked to a core team member of Vitess, and employee of Planet Scale… I think you can look at that and you say “Well, it’s managed, it spins to zero, I can branch it, it can work into my development environments…” I think those are the attractive things about Neon.

And then I think there’s something cool happening with Neon that I’ve learned recently by way of Retool. Do you know Retool well? Do you know what Retool is?

[01:16:06.27] No.

So the cool thing about Retool they’ve done recently - and again, these are both sponsors, and that’s why I personally have a bit more of a preview into this… And sorry that that’s the case, but Retool built – they wanted to get people to adopt Retool, obviously, faster. And the way to do that is to not have to connect to a production database to get value. That’s scary, right? They wanted you to be able to spin up your own database inside of Retool, and they had to build their own database platform. They didn’t want to have to build that platform from scratch, and so Neon has this thing called Fleets. And so you can be Retool, and say “I want Retool database, and I just want an API call-out to Neon and spin up servers ad nauseam.” Or I want to have warm databases on the fly. Now, that product is seemingly quite different from Supabase, despite the core substrate being obviously vanilla, not Postgres-compatible, but Postgres literally, as the substrate. But you’re both in similar markets, but the product seems to be uniquely different. And that’s kind of where I would draw the lines; you’re not trying – it doesn’t seem like you’re trying to do those kinds of things. You’re trying to be a platform that developers can build on from zero - like you mentioned, greenfield - and have all that tooling that can be isolated, but then also work very well together, but you’re not trying to be this serverless hero, or this branching hero that kind of works into workflows… But maybe that’s something that is on the future roadmap, because that’s kind of attractive as a developer. As a developer, I want to have my Git workflows, but I want my database and my schema, my things like that to kind of similarly fall in line with my Git workflows… Which is why I think they’re trying to aim for.

Well, that’s an easy answer, because we’ve got branching, too. So yeah, I think easy for developers these days to use – and credit to Planet Scale, as you pointed out. They kind of pioneered this. I think it’s a bit of a table stakes feature now, where you’ve got to be able to run your workloads inside GitHub. And your branching strategy has to work really nicely with a good workflow. We also have that.

I think the scale to zero is quite interesting. We’ve dabbled with offering it many times. The thing is that, typically, a database - you know, one of the things that we want to make sure, that is really important for us, is that people have a great experience. And we didn’t want any cold starts. And we’re not willing to offer a product where we couldn’t get the cold starts down to a point where it was not noticeable. And I think this is probably the key complaint around some of the serverless platforms around databases… Because they’re such a stateful workload. Now, on top of that, the reason why we’re less concerned with serverless is that once a sort of product starts scaling up, it actually doesn’t really need to ever scale to zero.

Serverless really only matters, in my opinion, because you branch. You want your branches to spin to zero, because you don’t want to spend the money on a development branch that doesn’t need to sit there and kind of be awake for months and you forget about it. Or there’s this unexpected bill. I think that’s where it really matters, because spin to zero only matters for, I think, in Retool’s case, because they don’t want these for users coming in, kicking the tires, and that database is spun for forever. Or it’s adding rows into this kind of like large database. Those databases get to be standalone, singular, spin to zero databases, which I think is a great thing for them, because they could have done all that with a single engineer. That’s what I think is pretty interesting there. And I think you’re right, for a production database spin to zero kind of doesn’t matter, because it’s going to be up, for the most part, forever.

[01:20:04.20] Yeah, and that’s how it works in Supabase as well. So the branching databases will spin to zero after not being used for a while, and that all runs on Fly; we have Firecracker, so it is quite fast. It’s not as fast as what we would want on a production system, so that’s why we don’t offer it on our production databases. Now, there is a future in that we might get single-digit latency cold starts on the database. And if we get that, then we’ll definitely look at scale to zero.

Yeah.

And also, we’re doing a lot of development around our proxy supervisor. So in this case, we can do some quite nifty stuff once that’s really stable. And so yeah, I can definitely see a future in that we’ll offer serverless Postgres, but it so far hasn’t been a concern about.

I didn’t recognize that branching was there, and I think when I’m on your product page, it says New. But you said this page hasn’t changed much in a while. I can’t imagine branching is literally new if that’s truth, if this page hasn’t changed much. When did branching get launched? Because I gapped that, I didn’t know you had branching.

I don’t know, maybe a year ago.

Gosh…! I slapped my face, you know what I’m saying? Come on…! Okay, so it’s not new-new, it’s new as of a year ago, then. Okay. I didn’t know you had branching, so I apologize. This is not a feature parity, like “Hey, how do you compare?” It’s more like – I think our line of questioning isn’t to put you on the hot seat of saying “Literally, how do you compare to all these platforms?”, but more so part of this show is helping developers sift through what matters and what should matter to them, and helping them find the direction to their choice.. What is your stance on how these things should work? You’re obviously both – when I say “you both”, it’s Neon versus Supabase; you’re both Postgres for life. And that’s a beautiful thing, because we bet on Postgres for life, not Postgres-compatible for life. And I’m not trying to knock Postgres compatible, it’s just generally not where we personally want to play, because we have different ideals as it relates to Postgres the database.

So these lines of questioning isn’t to say “Literally, Paul, how do you compare?”, but how do you help developers guide to the right thing that matters to them? They’ve got a greenfield product or project they have an idea for, or they’ve got an existing platform like ours that’s been in place for a long time. We were not starting from scratch. We already have auth in place, we already have storage in place… And I’m talking about Changelog.com as we. And we really was thinking “What’s the next thing for our database?” I didn’t know - and Jerod, maybe you knew… I didn’t know that we can use Supabase just as Postgres. I didn’t know that – it’s not clear to me, when I look at Supabase, that you can isolate the things that we don’t need necessarily, to just the thing that we do need, which is we wanted and desired to not have to manage our own Postgres. Plus, we love to play with cool tech, and so we often will reach out and do this kind of thing.

So that’s why our, our line of questioning is from that - or at least mine is - because it’s kind of framing from our perspective. But at the same time, our job here as podcast hosts is like “Hey, developers, what should matter to you? Let’s figure that out.”

Well, now you do know, because I’m on your podcast, telling you.

There you go.

So I think that’s all part of it, right?

Yeah. Well, there’s so many facets to telling your story, and one of those facets is to continue to tell your story as it evolves. So somewhere along the way you lost Adam in your real-time updates of brand new features… Even though you have your big launch week, which I think seems like – that deal’s caught on, Paul. Did you guys start launch week? Because now everyone’s doing a launch week. This is like a thing you do now. Is that your baby?

Well, I think the original credit for like “Do a big week of launches” goes to Cloudflare. But the concept of launch week, one feature every day for a week came from our early days, for sure.

[01:24:03.24] Yeah. That’s cool. I think it’s a great way of doing things, because it’s hard to make noise, and it’s easier to make a bunch of noise at once than it is to kind of squeak throughout the year, and to actually get some people’s attention. It also, I think, probably rallies your team around deadlines, which are all exciting… And because there’s different features each day, probably a different team on certain things, and everybody kind of has their moment to shine… And I think it’s just overall a good strategy. That is probably why everyone’s doing it now. By everyone I mean a handful of organizations have adopted launch weeks, and I credit it back to you, but now give it to Cloudflare. So you’ve convinced me it’s not a thing [unintelligible 01:24:46.07] It doesn’t matter who started it, it’s just cool, because I think that it helps you tell that story in a way that actually makes a splash, and maybe sticks with people. Every once in a while you lose someone on the way, but I didn’t know you were branching either, so…

Well, as much as anything, the launch weeks for us these days are kind of an internal forcing function. So we do three a year, and we don’t really do sprints, or anything. So the way that we can kind of organize the team - like, we’ve got one coming up… I don’t know when this podcast will come out, but probably around the time of another launch week. So now we’re about six weeks out, and I’m just going around the teams saying “Alright, what are you going to ship?” and sure enough, they know this deadline’s coming up, so they have some things that they’re going to want to work towards.

Interesting. So you sort of like set the deadline, or the date range, and they already know what they’re working on, so you just map to what’s in flow… Not “Oh, date’s coming up. Let’s build this thing.” It’s sort of like what you’re already in flow with.

Mm-hm. “Fixed timeline, variable scope” is the concept.

Very cool. Next week is when the show will ship, so…

Okay, well then in a few weeks from your listening to this, then we’ll do a launch week.

Is there a particular URL that you send folks to to kind of pay attention to that? Is it just your blog, or where do you point people to, say, developer week?

I mean, if you go to our site, then –

Just the homepage…

Actually, we own the domain launchweek.dev, and actually one of the community is like maintaining that, with all the launch weeks on it. So you can go there, I guess. But yeah, usually if you land on our website, you’ll see it. Or on our social media we’ll be pointing towards the future launches.

Well, let’s give you a little freeform. What are you excited about? We’ve asked you lots of questions, we’ve kind of grilled you, in some cases, we’ve pinned you against cutthroat competition, all that good stuff… What are you excited about in your own platform? What is most exciting that you’re doing, that you’ve enabled? What’s got you excited?

I’m most excited about the kind of conditions of the market. I mean, the last 12 months we’ve seen a lot of AI workloads… But in my opinion, they’re a little bit like the flashlight when the iPhone came out, and everyone built a flashlight, and everyone’s building the same thing. There were so many flashlight apps.

So we’ve seen a ton of this on our platform, I think… We’ve launched over a million databases now, and you can imagine how many of them are sort of AI-driven, and probably doing a lot of the same stuff. So I’m quite excited about where it goes from here: the product, the industry, what people are going to build… Our dashboard was very good at this; we’ve integrated a lot of AI. In fact, I spoke to a lot of these developers that don’t know how to use Postgres, and so they build on our dashboard just kind of chatting to our AI features, and building their database from there.

[01:27:55.24] So I’m kind of excited to see where all of this goes, and how good the AI can become to build things. Actually, we’ll launch something this launch week that’s kind of cool. We’re working with the Electric SQL team, if you know them; they’re developing this - the sync engine. But one of the cool things that they’ve developed is PGLite… Funnily enough, using some of Neons technology here, but it’s a WASM service. It’s like SQLite, but it runs in the browser using WASM. And it’s Postgres. So we’re experimenting “What does it look like when you can do that? …you can launch a lot of smaller databases like SQLite, and you can do them in the database.” And how does the experience feel when you can develop rapidly on top of something like this?

So yeah, I just saw a demo, actually, from one of our team yesterday, and it’s kind of mind-blowing, the experience that you can build with this when you combine Open AI as well, some of their tooling… So yeah, most of all I’m excited about the general trend, nothing too specific.

I think Oriole as well is going to be probably another big one. We’ll do some announcements around that for this launch week. The storage engine itself, pushing a lot of this hopefully into Postgres core… But Oriole already, if you compare it to just default heap storage, it’s four and a half times faster for reads and writes… So I think that’s kind of exciting for developers too, and we hope to make sure all of that’s available for the Postgres community.

How is Oriole achieving that? Is it just their storage format? Is it some sort of fanciness underneath the hood? Or how are they doing it?

Yes, it’s just the storage format. Actually, Alexander has some great talks on this. I won’t go into it, but… Yeah, it solves actually quite a few different problems with Postgres default storage. So yeah, it’s kind of a neat technology, and I think it’s something that’s needed to exist. I mean, obviously, I come at it from a Supabase angle, but we were sponsoring them for many years before this, and trying to upstream as much as possible… So it seems like it’s a thing that we’re putting our full weight behind, but not for ourselves necessarily. It’s really hopefully for the community.

Well, you’ve answered all of my questions at the moment. I’m sure I’ll have seven more after we hang up… But Adam, do you have anything else before we let him go?

I have one Plus Plus that I’m saving.

Oh, we’re saving it. Save the best, or maybe the worst, for after the official show…

We’ll see.

…ends for our hardcore Plus Plus, closer to the metal subscribers.

Yeah.

Cool. Well, Paul, it’s awesome, dude. Love what you’re up to. I think it’s super-cool, and I think the progress over two and a half years, as a person who stepped back, didn’t look at it for a while, and stepped back into it, you guys have gotten a lot accomplished through your continuous improvement. So keep polishing, keep working on it, and I’d love to catch up more often, so we’re not missing out on all the cool stuff you guys do.

Yeah. Cool.

Keep kaizening, you know? We’re a fan. Keep kaizening.

Yeah. Nice.

Thanks, Paul.

Yeah, thanks for having me on.