The Changelog: Software Development, Open Source - It all starts with Postgres (Interview)

Episode Date: July 11, 2024

Paul Copplestone, CEO of Supabase (the meme-lord himself), joins the show to take us on the journey of Supabase leading Postgres for life, and how it all starts with Postgres as the base-layer substrate for the entire Supabase platform. They're laser focused on the drive ahead, not the rear-view mirror. Disclosure: Adam and Jerod are angel investors in Supabase.

Hey friends, quick note before the show today, Jared and I are both angel investors in Superbase. As you may know, we are long on Postgres. Postgres for life, as they say. Here we go. What's up, friends? Welcome back. This is the Change Log. We feature the hackers, the leaders, and those who are leading Postgres for life. We're here with the meme lord himself, Paul Copplestone, CEO of Superbase. And we're diving deep into the latest advancements of the Superbase platform. What's going on with Postgres?

Why it is winning? The state of Postgres platforms out there to choose from. Thank you. Fly.io. That is the home of changelog.com. You can launch your apps, your databases, and your AI all on fly near your users with no ops. Learn more at fly.io. Let's do this. what's up friends i'm here with a new friend of mine jasmine cass's product manager at century she's been doing some amazing work her and her teams over many years being at century and her latest thing is just awesome user feedback you can now enable a widget on the front end of your website, powered by Sentry, that captures user feedback. Jasmine, tell me about this feature. Well, I'm Jasmine. I am a product manager at Sentry and I'm approaching my three-year anniversary. So I've spent a lot of time here. I work on various different customer-facing products. More recently, I've been focused on this user feedback widget feature, but I've also worked on session replay and our

dashboards product with user feedback. I am particularly excited about that. We launched that a few weeks ago. Essentially, what it allows you to do is it makes it very easy to connect the developer to the end user, your customer. So you can immediately hear from your, basically who you're building for, for your audience. And you can get, basically have a good understanding of a wide range of bugs. So Sentry automatically detects things like performance problems and exceptions,

but there are other bugs that can happen on your website, such as broken links or a typo or permission problem. And that is where the user feedback widget comes in and it captures that additional 20% of bugs that may not be automatically captured. I think that's why it's so special. And what takes it a step level above these other feedback tools and these support tools that you see is that when you get those feedback messages,

they're connected to Sentry's rich debugging context and telemetry. Because often, I've seen it myself, I read a lot of user feedback, messages are cryptic. They're not descriptive enough to really understand the problem the user is facing. So what's great about user feedback is we connect it to our replay product, which essentially

basically shows what the user was doing at that moment in time, right before reporting that bug. And we also connect it to things such as screenshots. So we allow, we created the capability for a user to upload a screenshot so they could highlight something specific on the page that they're referring to. So it kind of removes the guesswork for what exactly is this feedback submission or bug report referring to. Now, I don't know about you, but I have wanted something like this on the front end pretty much since forever. And the fact that it ties into session replay, ties into all your tracing, ties into all of the things that Sentry does to make you a better developer and to make your application more performant and amazing.

It's just amazing. You can learn more by going to Sentry.io. That's S-E-N-T-R-Y.io. And when you get there, go to the product tab and click on user feedback. That will take you to the landing page for user feedback. Dive in, learn all you can. Use our code CHANGEL to get a hundred bucks off a team plan for free. Now, what she didn't mention was that user feedback is given to everyone. So

if you have a Sentry account, you have user feedback. So go and use it. If you're already a user, go and get it on your front end and if you're not a user well then hey use the code changelog get a hundred bucks off a team plan for three-ish months almost four months once again sentry.io we're here with paul copplestone from super base back again pa 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 out that week, Jared. And to this day, it's got double the listenership and reach of a normal Changeelog 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 fake 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 on in the time square as part of the infrared 100 this is red points kind of top 100 info companies the funny thing is like 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 caught 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 Change All 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, Jared 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 would like this headline. They'll get that it's a joke. They won't be upset, that it's a joke. They won't be upset, but it'll be fun. And so it was kind of click-baity because we literally said, we put the flame emoji and said, Superbase quietly went public today. And that's what happened.

Nice. Well, for those listening, Superbase does not take itself too seriously. So this is basically how we operate on social media all the time. Yeah. And 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, Jared, you're a really good reuser and I guess take her backer, if that's even a phrase of the memes that you put out that others have tried to take from you. And I think you've like put them into the memes that you put out that others have tried to take from you. And I think you've put them into the newsletter and put them on LinkedIn more to be like,

this is mine. Yeah. I was the OG of this one. 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 going to really react to that but i'm just going to go ahead and start reposting some of my old ones because you know they're still kind of funny and why not reuse them if somebody else is going to so that bug one though that bug one looking into the mirror was like, that was so cool. Just since I mentioned it,

give context, please. What is the, what does the mean 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 that just happened to be like on, somehow it's on two legs and it's like in front of a mirror. And I was pondering what it might be thinking about, you know, and i assume that's like 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 like he's like at the dinner table with his wife and he's saying like 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 do at the end of his day well Well, he's reviewing how well he did that day. Like how many failures did he cause?

Did anybody find him? You know, because bugs are out there to cause trouble. You know that, Paul. Yeah. I'm going to find that meme and I'm going to repost it without changing at all. And I'm going to take credit for it. That's great.

If you could repost it onto the Times Square Jumbotron, that would be spectacular. I would allow it. Well, speaking of big, let's laser in on this tagline. I know 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 going to 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 Superbase and gets to build and deliver on this promise of building 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 Superbase, zero users and scaled to over a million users on Superbase. 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 um now we're quite comfortable with that it's it's really what we wanted to deliver on and we're quite happy that we've been able to so the last time i 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 Superbase is all in on Postgres. You were all in on Postgres. It seems like you are still all in on Postgres, maybe even like, can you go more than all in? I don't know. You're given 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 on open source still? Are you rethinking those decisions now? No, there's never been a second thought on the open source. I think the thing is, I don't know if I 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 that around, can you commercialize? But we've de-risked 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 we think the future of Postgres could, it could be useful to have in the future of Postgres. So is the entirety of Superbase open source? Like could AWS stand up Superbase as a service and do what it has done to many other offerings in the past? Yeah. So the way that Superbase 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. And 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. And with the Auth product, it stores the users in the database. With the file system, if you want to store images, it'll store it to S3, but it'll 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 Post-grants tooling. It's kind of smart that way. Yeah. That was kind of like, your question was kind of my question, Jared, in a way, but more benign. I was going to say, like, if you were to not, like, with the whole rug pull not cool situation that's happening over and over again,

you know, 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 okay 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 So what you're saying is as long as you're in the seat, open source for life.

Yeah. Good. Okay. So, I mean, 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, you know, let the competition come. What about on the self-hosting side? Are there opportunities? Are there people

self-hosting Superbase? Because that's an enthusiast market. It's not a scary, giant, crush-you market. Are you servicing that? Because that seems like you make it harder for AWS not because you want to, but because of the nature of what Superbase is, you also might make it harder for self-hosters.

Well, a ton of people self-host Superbase. I just literally got off a call before this, chatting to a guy who's self-hosters yeah well a ton of people self-host super base i just literally got off a call before this chatting to a guy self-hosting on gov cloud for example and we don't have gov cloud so okay this is the the beauty of open source i mean it's cheap enough 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, like our lowest tier where 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. But actually, that's fine. I mean, it's not like we would have made money off them. We'd rather that they use the product, they contribute back to open source. And so it's part of the community. We can give them things for free and we can support them and they can support us back in different ways. 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 Superbase, if you wanted to?

Just to tickle... I don't know if I like that word. Just to appease those who are... Don't tickle us don't know if i like that word just to just to appease those don't take it i made myself laugh on that one just to appease those out there who are thinking you know what i want to tinker with this i just want to play with how to self-host it not to literally do it but like 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, which is really easy. I do it on a digital ocean server,

which is obviously installed, has Git installed. Could you change that to a Fly server? Yes, yep, yep. In fact, we work with Fly. That's why I said that. Yeah, 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 you enumerated a couple of them but how many docker containers are there and what are the individual services that you 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 post-GIS. BG-Chron, 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. Or, yeah, 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 into your Postgres server is useful is because for the auth service, the way that we do authorization or Z is we lean really heavily into row 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 the access. So now you can see all of these services

kind of start fitting together, even though they are individual services. The next one is an existing open source tool called Postgres, and this has been around since the start. It auto-generates 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, it'll 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 run 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 PG vector 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 a really heavy compute. Cool stuff. So the PG vector, is that something that you've added

in response to market pressures of late? Or is 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. And so how do you make those decisions?

And specifically, we could focus in on PG Vg vector which seems like cool and even existed prior i think pg vector was around but now i'm sure there's probably people saying well if i can't do ai i don't want to i don't care yeah so pg vector is the brain child of andrew king and he's a phenomenal engineer and he's been the one developing PG Vector for, I think it has been around for three or maybe even more years. I don't know exactly. The story for Superbase 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 PG Vector. 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 like 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 it was we're really embarrassed that you know 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 joke and um sure enough it was a big hit and so greg the person who emailed me originally, now works at Superbase 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. What's up, friends? I'm here with Michael Abbott and staff software

developer at 1Password. Michael, I want to talk about how 1Password helps. Secrets management, secret sharing with teams, with orgs, with production even, really easy. Even so much so that when you spin up a new person onto a team or you add new people to a team or you, even if you take away people from a team, you want to focus on access and you also want to focus on security. So if you want to remove somebody, you want to make sure they no longer have access to your secrets. And then the flip side is when you add somebody to a team, you want to make sure they have access to their secrets. So help me understand how 1Password helps teams

be efficient with secrets management. So when you have a dev team storing their secrets in 1Password, then it makes it really easy to bring new people on. They already have so much to do and so many new things to learn. You don't need them to have that extra burden of creating a dozen different accounts to be able to access your payments or your errors or your monitoring. You can have that all set up for them already within 1Password. And each of those particular services gets pulled into your local application, your production application at runtime through the 1Password CLI.

From there, you have your new developer downloading the repo. They don't have to spend time setting up their environment. All of the different services are ready to go because they're already stored in 1Password. All they have to do is use the 1Password CLI to spin up and run the application and it's ready to go. It's like developing in the future. Well, we must be in the future, Michael, because we use 1Password just like that. All of our team secrets, all of our personal secrets, all of our application secrets, they're all in 1Password and we're using exactly this process to make our lives easier. So friends go to

1password.com slash changelogpod. They've given our listeners an exclusive extended free trial to any 1password plan for 28 days. It should be 14 days, but no, it's 28 days. But make sure you go to 1password.com slash changelogpod to get that exclusive signup bonus or head to developer.1password.com. Of course, to learn about 1Password's amazing developer tooling, the 1Password CLI, 1Password for SSH, and get CICD integrations, service accounts, and so much more. Once again, 1password.com slash changelogpod. I love when you laser focus in on the pain. I have so many conversations with sponsors, let's just say, and sometimes turn partners to work with us. And that's where I focus.

Like, where's the pain? You know, the way you get somebody's attention, the way you get the marketplace's attention is to focus on the pain. What is the pain? And in this case, like, well, 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 you know you're responsive as a ceo also where the platform needed to go what was coming up and obviously it's pg vector it's already out there but how can we leverage it

to do this vector database stuff for the burgeoning ai things came coming around the corner that's it's a good 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 but i assure you for for for every one that i got right i've got a few few wrong. Well, there's only so much of our time to go around. That's true. But at the same time, the story was cool. And AI

has taken over a lot of cases. And back to the framing of Jared's question was, did you add this as a result of market pressure? And it was a bubble up. You listen to your community. And I think back to even your hearkening to the desires of open source for you and that for

for Superbase to not be open source focus would have to be you being removed as CEO. Like that to me is that's how you focus on great product as 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, it's actually an extension and it ties together. Like I talked about how it used etched 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 etched 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 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 like we could do queues inside postgres but also because we've got these background workers the edge functions they can be used to for the queues another really good one we're doing a lot of content around maps at the moment post gis 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 got 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. What are some other second order primitives that either you're chasing or currently exist or, or in the back of your mind as potential things? One that I, well, it's always good because I told one 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. Really good example is 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 Superbase. So we acquired LogFlare, I think we talked about this last time, and 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 the failure, but I didn't hear what the failure was. Can we

focus in on your failures, Paul? Yeah, yeah. You want to really dig into that? Just a little bit. 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 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, 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, when the F are you guys going to, going to launch functions. And so I didn't want to do functions because we're a Postgres company, right? I could see that people, our community were using, they were using Vercel and Netlify.

They've got functions or people can use Django. They 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 mapped exactly the same to the 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 there's just 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 did people for had they forgotten about it did they care yeah people still say hey when are you launching that workflow service that you announced? And what do you say to them? Maybe never? Yeah, exactly. I say, check out this functions thing

that we've done. All right, this is also cool. It's over here. So what'd you learn from that? Yeah, there's a ton of things. I think like, 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, you know, I learned that we've already got, in my opinion, product market fit, right? So when you're a founder at the start, a lot of it's your vision and you have to put something out to the world. And yes, your vision helps, but the 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. The other thing is that our team is really competent now. And yeah, 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, than me at most of this. So I can just rely on them to tell me what is, 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. We're going to do our own thing over here. We're kind of in the details here. You're kind of out there, Paul. Right. What is the team size these days?

How have you grown? How have you gotten to where you're at? Obviously, you started from two founders, a couple 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 problem. That's kind of a hair-on-fire problem that no one in the team can solve. So 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 like 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 got a pretty good personal brand in the marketplace. Stupid Base is cool. You know, 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? Is it pretty hard to find the right candidate, not a plethora of candidates, right? Yeah, and every role is different, right? I think we did a DevRel one and we had like a thousand people apply or something like that.

So, I mean, 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 and we can put it out through through the yc network we hire a lot a lot of ex-founders i think 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 had started their own sort of venture-backed vc uh venture-backed startup what uh 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 some if you're a product team you actually only have to do one meeting a week 30 minutes that could be all in the face time that you have to do in super base some people turn up to more but that's kind of the requirement so of course with this little amount of feedback from from people you have to find your own feet within the company and so we've just found that x founders are very good at this especially when it's a new new product new insight something that we're kind of launching i would think that x founders would be good but then they might churn, right? Because they obviously had had the itch.

They might get the itch again. I wouldn't say failed, because you never know why they're an X. They could have exited and been like, you know what? Soobase is cool. I'm going here. It's not a point of failure necessarily

to have X 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, Jim. I think none of them have. Oh, good for you. I could be wrong.

But I think because there's another, this is a two-sided coin, right? The ex-founders are the ones who appreciate our product market fit more than the rest of the company, right? 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 Ant and 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, you know, a good thing. It's not,

it's not just something that they can reproduce themselves. Are you a listener of this podcast, Paul? Some, but I'm going to recommend an episode for you. I love when he just puts people on the spotlight. That's why I'm going to, that's why I. I love when he just puts people on the spotlight. I'm going to 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 ahead and recommend that one to you. There you go. Cool. 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 elucidating 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 Superbase 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 Superbase that, you know, 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. How do you say no to a free platform you can join, though? How do you say 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 company that I kind of most admire is MongoDB. They went kind of the other way around. They went, 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're 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'd be ready to service also all of that profile of developer as well, while simultaneously servicing all of the enterprise customers. I like that strategy. I think there's a certain humility to it. In fact, prior to the 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 cloud. 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 uh you're nyc 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 you know i was gonna say friends with benefits but that's not what it is just like you know network folk you know it's kind of an insider club it's kind of fun it works it works i mean that they're they're starting software companies you provide services to software companies they become the ysc operating system basically or part of that substrate that is yeah today's past present and future yc YC companies. 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. I'm not too sure. I noticed that. I was like, wow, Jared, I'm here on the homepage. And above the fold, there is 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 seemed 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 forward. I feel like I'm at home, so to speak. There's your logo. 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, like 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, you know, 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, right? So, yeah, 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, you know, actually as well, because Mongo have forged this path before,

it's not like 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. 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 features or the platform level features or the platform level, like the product level things, the database authentication.

Like give me visibility. And even when I go into, for example, the database page, you've got a graphic that shows a table, but I don't, it's not, you know, the soup base 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 hand-holded, not just listed. Well, if Johnny's listening to this, there's great product feedback. 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 Superbase 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 like is we won't do an overhaul ever. It'll just be iterations, iterations,

always iterations. We call it Kaizen from the Toyota production system. Never heard of it. Continuous improvement. Never heard of it. Tell him, Jared. Tell him. Oh, we have a whole show called Kaizen, so we're very well. Yeah, it's like a mini-ser have a whole show called Kaizen. So we're very well. Okay. Yeah, yeah, yeah. It's like a mini series. We've adopted Kaizen as well, basically.

Okay. Gerhard Lazou. We're fans. We are fans. But I do also confess that it puts you in this local maximum situation, right? 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 Kaizen-ing what exists. Versus you have to kind of go up a level in order to kaisen the entire business yeah that's an interesting one

right i mean this happens i think this is you know 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 like we do rfcs internally so i can comment on them he did a video where he kind of overhauled the hong 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 you 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 in this local maxima which could probably probably be maybe five times better if we just went back to the drawing board.

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. 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. It's an appointment. Extreme disappointment. Yes. This is not a perfect one-to-one example, but this is a recent example of major change that did not, in my opinion, go perfectly. And they have their speakers essentially networked on your local network. 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, like core things I would do every single day in this thing. The sleep timer. Like 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 is still playing. Like that's just silly. And I can't even create a custom timer anymore. Like it's just like silly things they change massively so I kind of appreciate what you've done where you sort of pick little parts and you kind of send 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, so 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. I'm like, why?

Who did you test? Adam, you just got someone fired. That's forever. I'm like, why? Who did you test? Adam, you just got someone fired. That's honest. I'm sorry. You did. I don't think so. Maybe. Just spitting our bug reports into the sky and hoping that they land in the right years.

I love it. Yeah. Well, that's why Kaizen is good, right? You notice these small changes. And actually, it does work. I think it's the the least worst way of doing things i saw we've got this guy writing a book about super base actually how to use it and the super base book so he had linked 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 all through just this incremental changes right 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. Hey friends, I'm here with Brandon Fu, co-founder and CEO of Paragon. Paragon lets B2B SaaS companies ship native integrations to production in days

with more than 130 pre-built connectors or configure own custom integrations. Brandon, there's a certain level of pain that a product team or an engineering team has to endure to, let's just call it, rolling your own integrations. Help me understand that pain, that angst for those teams. Help me understand that true pain of delayed integrations for a product, not integrating or having to roll your own integration, this seemingly slower route to integrations. I think for context, one of the reasons we started Paragon is that today, the average company uses over 130 different software applications. So that means if you're a B2B software company selling into the

market there's over 130 of your customers applications that you probably need to connect your tool to because customers today expect that any product they buy is going to work seamlessly with the hundreds of other applications that they're using. Of course, we see this when companies come to us and they say, hey, we have a backlog of 10 or 20 or 50 integrations that, you know, our sales team has told us we're losing deals because customers are asking us to integrate with all these different apps and we can't deliver on those integrations or maybe our competitors are integrating with these tools. And the problem that that results in for product and engineering teams, of course, is how do we build and maintain these integrations

in a way that's scalable, that we can not just satisfy what customers are asking for us today, but we can maintain those integrations in a way that's scalable for the next hundred customers, the next hundred integrations that we need to build. So for engineering, one of the challenges, obviously the backlog and prioritizing time for certain features or integrations.

But then there's this other side where you got to really learn every single API and everything is hand rolled, custom, maintained. And over time, that kind of gets, I got to imagine, kind of taxing on teams. What do you think? So most engineers know that, engineers know that every API is completely different, can be completely different in terms of how they handle authentication, in terms of how they deal with different record types. And so it becomes this problem for engineering teams to basically have to become experts in other people's APIs and what could be dozens or hundreds of different APIs. And to build those integrations,

we've seen can take as much as three to six months per integration for a developer to write the code, to build that integration. And it depends on the use case, of course, and the type of product that you're integrating with. But of course, that becomes a massive challenge at scale when you're looking at how do we scale our product to support 10 or 20 or 50

different integrations. So again, Paragon was really designed to solve that problem and to distill the complexities and the nuances and the differences between hundreds of different SaaS apps into a single connecting platform, into a single SDK that your engineers can install in your app, and then easily connect your products to all these different SaaS applications in the market. Okay. Paragon is built for product management. It's built for engineering. It's built for everybody. Ship hundreds of native integrations into your SaaS application in days or build your own custom connector with any API. Learn more at useparagon.com slash changelog. Again, useparagon.com slash changelog.

That's U-S-E-P-A-R-A-G-O-N dot com slash changelog. 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 a lot of postgres going on then there's the postgres alike or you know rdbms world which is like close enough and Then there's the Postgres alike or, you know, RDBMS world, which is like close enough. And then there's the NoSQL. But like, if you were to put yourself against competition, which I'm sure you've done in 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 Superbase 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. And 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 yeah so there's a few others um some that have come and gone um in this space as well the serverless postgres um and so yeah neon a very interesting technology they decouple the compute and storage so they do that by replacing the storage layer of postgres itself so that's pretty cool and so yeah around area, we are focused and we have been sponsoring and just recently acquired AureolDB. We also like 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 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. In fact, some work was done many years ago, this thing, Z heap for Postgres. And the original work

was done to add these table access method APIs for replacing the storage engine. Now, OrionDB is a Postgres extension that you can use like a new storage engine that solves some of the, what Alexander, the creator of it, he has developed and submitted a bunch of patches to the Postgres core to develop the engine like you said is does aureole 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 when you call it table access method or table access methods yeah yeah yeah so i think the well we already have an experimental s3 backing with Aurel. 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 Aureole is that it's more, it runs as a processor, 20 processors backing, 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 it. And the reason why this is good with Aurel is because of the storage format. It's a lot leaner, the amount of data, so it's 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 them, 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 be kind of upstreamed. It's developed in Rust.

And 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 superbase 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 like 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're like a data cloud. A data cloud. 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 comes it gets stored on superbase there could be oltp data or later on some olab data we're not fussy with how like for example we're very clean with our integrations we're very clean with our open source and protocol support so 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 like, for example, I'm a big fan of like 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. I see. So expanding beyond Postgres with other services that are leveraging different kinds of backends,

such as object storage, for instance, 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. 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 database management and stuff

so there'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' blog. It's like, the Superbase blog is like, now we're using Postgres to do this. And, you know, you could low-level security, you know, like all this kind of stuff. Yeah, that's because we're Post postgres to do this and you know you could low level security you know like all this kind of stuff yeah that's because we're postgres maxis like the way i think of think of our platform and the way that people use it there's kind of like this spectrum right you've got people who are postgres maxis like us and they just you know they love row level

security and they love all the things about postgres. And so they get a real kick out of using Superbase. Then you've got all the, you know, use Postgres just as a, you know, 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 mix like use some extensions or something. And then down the other side of like, the people who have like, 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 super base you end up leaning really heavily into the stack and sometimes people kind of merge more off the super base tooling which is fine because maybe they find row 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 jared is like there 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 like even your framework may do some of these things potentially better but not like i don't, you kind of lock yourself into it. What is it that makes people come to Superbase? Like, 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 say 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 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.

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 he was running. And it's all Postgres at the end of the day. We're using the Postgres query planner.

We use HypoPG at 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 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. Here'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 of 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 not aware of, at least for AppRite. And they don't say is we're open source that i'm not aware of at least for app right 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 like how do you not get distracted by others that are good players in the market serve a good purpose because app right's growing's 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, Karen Marooning. She's amazing. And she says you should be driving a startup. It'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 rearview 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, right? And so I don't know, like we don't have a huge overlapping audience with those ones. I don't think, I don't see them often, at least in some of the discussions. At Bright, 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 kind of like, 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 realized, oh, actually, not a lot of that was important. 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. And 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 they look at Superbase, obviously. When they compare those two, like 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, Superbase is actually the better option for me? What would make them say that? Well, yeah, I mean, 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 cannot run a 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 you know, 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, you know, we've got a really big community. And I think people like that. you can find content about superbase everywhere across the internet and like sometimes that extra tooling helps a lot of for example we both offer pg vector the ability to do embeddings and the edge functions i know is one of

the reasons why people are switching to us not not just for PG vector workloads, but even from other vector databases. We see a lot of migrations over to Superbase 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 the 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, like 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, PlanetScale kind of began this journey for that. But I think, you know, if you're Postgres for life, you're not choosing PlanetScale. But there's good things happening around Vitesse and there's good things that's happening around the core of PlanetScale. We've talked to a core team member of Vitesse and employee of PlanetScale. We've talked to a core team member of Vitesse and employee of PlanetScale. I think you 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 more so. 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? Nope. So the cool thing about Neon that I've learned recently by way of Retool. And do you know Retool well? Do you know what Retool is?

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 purview into this. And sorry that that's the case, but Retool built, they needed to have a, 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 retoolool database, and I just want an API callout to Neon and spin up servers at Nauseam, or I want to have warm databases on the fly. Now that 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 line. 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 what I think they're trying to aim for. Well, that's, I mean, an easy answer because we've got branching too. So yeah, I think easy for developers these days to use and credit to Planescale,

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 Git workflow. So 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, 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's 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 only really matters, in my opinion, because you branch. You want your branches to spend 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 free users coming in, kicking the tires and that database is spun forever or it's adding rows into this kind of like large database. Those databases get to be standalone, singular, spin to zero database, 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. 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. Yeah, and that's how it works in Superbase 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, you know, 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. And 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's so far hasn't been a concern of ours. I didn't recognize that branching was there. And I think when I'm on your product page, it says new. 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, slap 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 parody 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 like 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. Right, what is your stance on how these things should work? You're obviously both, you know, when I say you both is Neon versus Superbase, 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. And so these lines of questioning isn't to say, you know, literally, Paul, how do you compare? But like, how do you help developers guide to the right thing that matters to them? They 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, right? 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 were saying, what's the next thing for our database? I didn't know, and Jared, maybe you knew, I didn't know that we can use Superbase just as Postgres. I didn't know that the, it's not clear to me

when I look at Superbase 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 line of questioning is from that, 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. Yeah, well, now you do know because I'm on your podcast telling you. 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 thought of, 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, right? That's right.

And 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, 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 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. Yeah. That's cool 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 like you know 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 different team on certain things, everybody has their moment to shine. 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 I'll give it to Cloudflare.

So you've convinced me it's not your thing. 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 along the way, but I didn't know you had branching either.

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, right? 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. And so now we're about six weeks out and I'm just going around the time of another launch week. And so now we're about six weeks out

and I'm just going around the team saying, all right, 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 it's sort of like what you're already in flow with fixed timeline variable scope is the concept very cool next week is when the show ships so it's okay well one week well then in a few weeks from you're listening to this then we'll do a launch week is there 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 homepage. Actually, we own the domain launchweek.dev and actually one of the community is 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 yeah, on our social media,

we'll be pointing towards the feature launches. Well, let's give you a little free form. 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, you know, 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 conditions of the market. I mean, the last 12 months, we've seen a lot of AI workloads, right? But in my opinion, they're a little bit like the flashlight. When the iPhone came out and everyone built the flashlight and everyone's building like 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 is very good at this. We've integrated a lot of AI. In fact, you know, 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.

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 sync engine. But one of the cool things that they've developed

is PG Lite. Funnily enough, you're using some of Neon's technology here, but it's a Wasm service. So it's like SQLite, but it runs in the browser using Wasm. And it's Postgres, right? And so we're experimenting, well, 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 and 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 can build with this when you combine open ai as well um some of their some of their tooling so yeah most of all i'm excited about the general trend, nothing too specific. I think Aureol as well is going to be like, yeah, probably another big one. We'll do some announcements around that for this launch week.

But, you know, the storage engine itself, pushing a lot of this hopefully into Postgres core. But I mean, Aureol 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 Aurel achieving that? Is it just their storage format?

Is it some sort of fanciness underneath the hood or how are they doing it? Yeah, it's just the storage format and so you know if you actually alexander has some great talks on this um i wouldn't go into it but yeah it solves actually quite a few different problems with with postgres default storage and 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 super base 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, you got anything else before we let them go? I have one plus plus. I'm saving. Oh, we're saving it. Save the best or maybe the worst. We'll see. After the official show 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 step 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 kaisening, you know, we're a fan, keep kaisening. Nice. Thanks, Paul. Yeah, thanks for having me on.

Okay, so we're long on Postgres. That's obvious. What are you long on? My SQL? SQL on? MySQL? SQLite? NoSQL? What is your for life database? I know we're Postgres for life.

We bet on Superbase and we're angel investors. We made that clear. But what are you long on? What are you thinking? Where is Postgres going? What thoughts do you have? Hop in Slack. It is free to join changelog.com slash community.

And yes, there is a bonus on this episode for our plus plus subscribers. Learn more at changelog.com slash plus plus. It's better. You know what? It is better. 10 bucks a month, 100 bucks a year. Directly support us, drop the ads, get closer to that cool changelog medal, and also a sticker pack shipped directly to you if you share your address.

And, of course, bonus content. It's awesome. Once again, changelog.com slash plus plus. Of course, a massive thank you to our friends and our sponsors for this episode, Century, 1Password, and Paragon. And of course, to fly.io, the home of changelog.com. Learn more at fly.io. That's it. The show's done. We'll see you again on Friday. what is the backstory with your relationship with fly like we are fly. I would say Fly for life. Fly lovers. When I say Fly, I mean Fly.io. You know that. But what's the story there? Why did this happen? I know that I've talked to Kurt behind the scenes and their pre-Superbase Postgres was necessary. It wasn't managed.

It was hosted, of course. But what's the story with your partnership? What can people expect? I know it's, I guess, seven-ish months old, this partnership, if I understand correctly. It may be eight. Because it was like, I'm sure, preceded December 15th blog post timeframe. What's the story? Yeah, so first of all, Kurt's awesome.

Yeah, Kurt is awesome. So I love catching up with him. That's part of it. The other thing is, of course managing a postgres service is a lot of work and so we've been working with them for doing managed postgres if you launch fly postgres right now it launches on their machines using their kind of open source operator but of, like when you running Postgres is not just about launching, you run into some problems and you need to solve them.

You also need a fairly hefty support or success staff when using Postgres. And a lot of the tooling that we build is to make sure that, you know, we can cut down on the amount of...