Coffee and Coder (Chat with Paul Copplestone, CEO of Supabase)

Discussing Supabase, OSS, and building in public with Paul Copplestone, CEO and Co-Founder of Supabase.

Paul's Twitter: https://twitter.com/kiwicopple Supabase: https://supabase.io/

BEN: Welcome to Coffee and Coder, everyone. I'm super excited excited for this conversation. Today we are joined by Paul Copplestone, the CEO and Co-Founder of Supabase. We're also joined by Joe Previte, who is an open source engineer at code-server. So we'll have some interesting anecdotes about working within an open ecosystem, and how open source communities can help with building projects, stuff like that. So without further ado, Paul, I'd love to hear as an a new user (I just signed up but I haven't created a project), what is Supabase and why have you created it.

PAUL: Yeah, sure. So, Supabase is the open source Firebase alternative. So everything we do is open source. And uh yeah, we're building basically the features of Firebase using open source tools. It's not a 1-1 mapping the Firebase for those who don't know what Firebase, it's basically a full banking suite. It gives you a database, gives you off, gives you functions that gives you storage for file storage. And we're building this film suite of products using open source tools. And the way we're doing it is slightly different. We're trying to use existing open source tools, especially ones that are very scalable, like Postgres, and we use various different open source tools to achieve exactly the same result, but it's not an exact 1-1 mapping is just really targeting the features of Firebase.

BEN: Yeah. And that was something I noticed with my limited research of Supabase was that you use fully open source ecosystems and kind of leverage the communities behind that to do kind of a the core of the product and then kind of stages together. Um and I think a common criticism of open source is: while there's a lot of really good tools, there isn't a lot of kind of, there isn't a lot of glue that allows you to have those tools work together. I'm curious. Um is this like from your perspective and entirely new business model or have you seen other companies kind of do this in the same way on kind of what made you decide to do it this way?

PAUL: Um I mean in terms of a business model, I feel it's actually a little bit dangerous as a business model. Um You know, we're always at risk of people saying well you're just reusing people's work, you know, like AWS sort of just free uses a lot of open source tools. Um So I don't know about it as a business model that wasn't really the decision making process. What I do know is that it's the promise, the original promise of open source to collaborate on things to make things very good. So we produce a lot of open source stuff ourselves, um and then we just try to make existing tools better, rather than reinvent everything. The other thing I know is that we just couldn't do better than Postgres. You know, we wanted to use Postgres, it's got 30 years or even longer of engineering behind it. There's no way we could actually reinvent a better system than what they've already got. e've got role-level security. So why would we even try? We just want to make Postgres as easy as possible and that's really how it started. We went around a lot of developers and we said, you know, what do you think Postgres? They said, I love it, and would say, what are you using? And they said Firebase, and we would say why? And they'd say, well it was just so easy to get up and running. So we just decided, well we'll make Postgres as easy or easier to use than Firebase.

JOE: Mm... I would love to hear. Maybe you talk a little bit more about the role of open source at Supabase. Like yes, it makes sense to use Postgres and it being open source, but but why open source?a lot of the tooling and services and features of Supabase itself?

PAUL: Yeah, Well, uh I mean it wasn't really much of a decision. We just wanted to be open source. My Co-Fouder and I are philosophically just very much like that. We love the model, loves that sort of philosophy of behind open source. So, I mean it wasn't a technical where it wasn't really a business decision, you know, a lot of people say "should I do open source maybe for marketing?" It's just that we love that way of operating of building, you know, everything in public. So, we try to open source everything that there are must admit some things which are not open source at the moment. Our platform, well our platform itself will never be open source is because it's a security risk um, to put, you know, a lot of things online. But in particular our dashboard is one thing which we are still opening up but otherwise, yeah, I mean the philosophy behind the company will be that absolutely everything that we can open source will be open source.

BEN: Yeah, that's um, that was one thing that I actually discovered as well was that the dashboard was kind of being transferred over if someone wanted to sell post, but other than that they could kind of still run all of the services. I'm curious people find Supabase because they like to self-host solutions or is it just because they feel more comfortable working with open source components? What are like, some of the driving factors for people to use it?

PAUL: Yeah, self hosting, Not really, to be honest, probably. Uh first of all we've got no telemetry in our open source offerings for the self hosting. A lot of the tools, we just wouldn't stitch them in. So um, it's hard to give the exact numbers of what percentage it is, but if I stay in terms of like what the internal numbers of how many people are using it and just want to get started the idea behind Supabase, you just want to get started fast. Right? Lesser that you want to have this open source offering. So 99% of people just want um, to use our hosted platform. So we've got it, you can sign up, you get a full Postgres database, it's free, it's got a free tier and almost everyone just wants that. Um, even when people say here that were open source, they say, well then you're not like Firebase because they haven't hosted offering and we have to clarify, yes, Well everything is open source, but we've got a hosted platform as well if you want to use it. So, um, yeah, most people want the easiness. The other things though, that they do want is the option to migrate away if things go wrong. So, you know, the promise of Firebase and Firebase is offering is amazing until sort of, it's not um, you know, it might not scale very well, so you might want to, you know, move some of your stack across and host it yourself or optimize it yourself so they can do that with Supabase. You can use us until we break, which hopefully we will never break. Um, but if you wanted to, you know, pick apart part of our offering and host it yourself, then you can.

BEN: Right. And, and that's almost interesting as well because, um, you could use specific services from Supabase and because it's open, you can even like maybe if there's like security risk or maybe some part of it doesn't necessarily scale for you and they could go and then posted themselves or just kind of have the security of being able to do that.

PAUL: And people do use specific parts. I mean, maybe like our auth is now becoming very popular, um, everything stitches in with Postgres, it's got a lot of providers who got Twilio integrations, uh, a lot of different things now. And the idea is that you hook it up to a Postgres database and you host all your user data. So it's great GDPR or California and regulations. So um, yeah, even just specific parts of the stack are great. And then of course on the libraries that we provide to make it easy to use useful even on your self hosted services.

BEN: Yeah, something else that I like notice from actually using Firebase, is that while a lot of the services are cool, they' are very arbitrary, right? Maybe like the way that auth works. The second that you want to use auth a different way, it's their own system.

So how do you with Supbase, you kind of provide abstractions to make things easier, will still kind of using the core components. And it's a little bit of vague questions that I'm curious like to hear, like what you're just general approach to that is.

PAUL: Yeah, actually, um so we're YC Summer '20 and what happened was we had this sort of accidental launch. We were only three months into building, someone posted us online, and it went very well. So it's very popular and everyone said, well, yeah, okay, I like the idea of Postgres but they don't have auth.

So we spend all all our time during YC when you're supposed to be, you know, um promoting and growing. We just enter myself in a couple of the team who are on board, spend all our time building auth. Um and in particular, we had to build, we wanted to build a very specific way. Postgres has this thing, role-level security, which is amazing. You can write, you know, very custom security rules around your database. And so we spend all our time trying to figure out how to make role-level security work with another external tool, Netlify's gotrue server for authentication. So um yeah in the end we figured out how to make it work using a few neat tricks and it means that yeah, if you wanted to migrate away for example is you do a PG dump and you take all your data, but you also take all of your auth rules with you, it's just all written into your database. So now everything that we do is central around the database, even for storage. Um we sort of mapped all your S3 buckets into your Postgres database, and you write access rules. Um once again using role-level security, so everything is just part of the database now. And it's great because once again, it's just a OG dump if you want to migrate away.

BEN: Right, and you're kind of using different um different like features that kind of already exist in the open source products. Umm kind of leading into the next thing, because you're using all of these features that like, maybe are from like an upstream things such as Postgres or I saw that, I can't remember the name offhand, but what you're using for like real time database, um things like that, how am how is your team like able to like deal with or necessarily contribute to or understand problems upstream. This is something that we kind of see a lot at Coder, because we have a similar mentality where it's like we don't want to build something that already exists and has not been implemented a lot better, but maybe we're doing some kind of wacky use case of a feature that was kind of implemented a couple of years ago, but hasn't been tested in a certain way. And all of a sudden we find ourselves like not blocked by something in our product, but actually upstream. So I mean it's led to a lot of great collaboration, but there's also like challenges associated. So I'm curious if you have any examples, there are just a general like kind of methodology for working kind of in those upstream communities.

PAUL: Yeah, interesting. Um yeah, it's a good question. Do you guys actually fork and keep maintain folks or how how do you usually do it for the most part?

BEN: We don't no. We just kind of contribute back upstream. Yeah.

PAUL: Okay. Um so yeah, a few different ways. The real time, that one that you said was actually we developed, it was the very first repo actually that I developed even before super basis. So that one is easy, but uh that was really sort of the start of Supabase, the real time repo but yeah, some others that we've got, we use PostgREST um that one's easy because we employed the lead maintainer, so that's always a good way to help out. It's great for us, but it's great for the community, I think like in the past year we've contributed, well, well, steve should I say has contributed a lot.

We do have um the hardest one is gotrue um which is done by Netlify um because actually now our focus diverging so far, one big thing is that go through was developed with MySQL and we developed with Postgres, so they actually don't want to pull in a lot of the upstream code. So we just tried to figure it out, we now have to maintain a fork um and we just try to figure out what we what they might want, which is largely just security features. Yeah, so this one is an interesting one because if you think about Netlify, they're not an auth provider um they have Netlify identity, which is what they use gotrue for, but it's not sort of part of their core business, so there's less sort of movement on this. So I'd say, you know, it's probably easier to choose services which, you know, has a lot more activity on because it will be a much more active repo. I think that's the only sort of thing that I could say in in hindsight. Otherwise, it hasn't really been too much of an issue. If we usually, if we run into a problem, do a fork temporarily run that in production and then once it's upstreamed, we fold it back in. But the other tools Postgres, we don't have to fork. It's just as stable as you can get. Um PostgREST, we don't have a fork at all. We upstream everything immediately. Uh, and just use nightly biuilds. Um, kong is an API gateway. We don't have to do anything. They're occasional patches, but it's very small and so far it hasn't been an issue at all, luckily.

JOE: So kind of piggy-backing off that. You know, if we look at some of these projects and we look at the languages that they're written, you know, we've got Exixr, TypeScript, Go, you know, like there's multiple, like there's so many languages and, you know, I can't imagine the engineering team being that big. And so how do you all balance jumping back and forth between languages?

PAUL: Yeah, the engineering team is 20, so yeah, it's really relatively small. Um and yeah, so, well, one of the things is that actually we just hire open source maintainers. So, for example, um, Steve, from PostgREST, PostgREST is written in Haskell, which is very hard to hire for. Right? But but, you know, he's one of the core maintainers, so of course he knows it. Um and likewise, when people were contributing very heavily, we've hired a number of times, just people were contributing to the code base. Um the other thing is that we have a culture of polyglots, so this is literally part of our onboarding is you know, I tell people what I love about our team, one of the things about our team is just everyone loves programming in lots of different languages. So even if people are not necessarily um, uh, you know, deeply skilled in a particular language, they're always interested and people in our team are always willing to help out if you know, anyone wants to get involved with Postgres development, we've got people in the team who will help them get involved, so yeah, it's just really um, well, you know, coding right? You can always figure out the problem within enough time, so yeah, it's not really a huge issue. Two, um, you were kind of discussing how you mentioned how easy it is, kind of to to discover the problem. Maybe it's not like a language necessarily know or something like that, given that like, the product is open source.

BEN: Do you ever find kind of community members or users finding bugs and even fixing them in the in the code?

PAUL: Definitely, yeah, or even implementing features. So I think someone wanted uh I think they wanted a Twitch provider actually, um in our auth service and I think they let us know three days later they developed it, and one day later we had implemented and put it into production and of course, you know, they were over the moon because imagine trying to do that on Firebase, um, you know, if there was no provider getting into a close source system, then it will be, well, almost it's impossible because the code is in there, but um but yeah, I mean that's the dream of, of open source is not only that you can get a future that you need, but you can the community can help patch bugs, which has been pretty good.

I'd love to I have to admit, I'll be interested to hear your feedback on this. I love to get more of that. People are very good at reporting bugs of course, but the team does do most of the work. I would love to somehow come up with a method whereby the community contribute a lot more and we've got a few things in place now which seems to be working, but I'd love to know how you guys doing anything with the community?

JOE: Yeah, I can take this one, Ben. Um Yeah, it's it's interesting because it feels like it feels like uh what's the word like? It's almost like a tightrope because on one side, you know, we have a paid product that benefits from any features, any bug fixes, any patches, the code base, right? And so like we try at least for on the code-server side and Coder, which for those who aren't familiar, it's VS Code in the browser. The thing that we try and do is have really good documentation. We try and being as transparent as possible, like issues discussions and like if people want to contribute were there and we'll guide them. And Ben does a great job like, you know, well, partner together and be like oh this person submitted to pr to fix this bug, let's send them some swag.

So that's one thing you do, but it's tough because it's like, you know, on one side, people could see it as like, oh you're just trying to get free labor and like that's not at all what we want to do, you know, like if someone wants to feature and it makes sense and they want to take their time to implement it. Um you know, either they're doing it in their free time, their employers paying for it, something like that. I think that's something that we're always looking for, ways to improve.

PAUL: Yeah, yeah, yeah, it's a tough one and yeah, I mean, as you could point, I mean you don't want to feel like it's just all free labor, ideally, people are solving their own issues, which makes it feel like, you know, it's there, I guess you hit the nail on the head, you need to make it very easy. Um I guess, and I guess coda could actually do that, I mean it makes it very easy to contribute back, so Yeah, okay, good. And swag, actually, I've noticed it, we just opened the discord people, developers love swag, so we try to give out t shirts to anyone who contribute something meaningful and that goes over very well.

BEN: Yeah, absolutely. I'm kind of just building off of what joe said. We definitely have seen people kind of submit prs for like specific things they wanted to fix. Um the issues they run into um something else like, interesting we've seen is um one of our users wanted kind of real time collaboration inside of inside of like code server and they actually created a fork and did that and now they're kind of maintaining this this sport that has collaboration built in. So that was very, very exciting to see. And as um it was a great kind of to see that like we we had our plug in architecture documented and things like that. So there's there's definitely some of them, but we're looking into ways to kind of like just kind of encourage it without free labor and kind of simplifying the the dub environment is definitely a big step because if you have to run a whole bunch of command and have a specific version of node and stuff like that, it's a lot more difficult to to contribute versus kind of popping right in and going yeah, yeah, definitely the case.

PAUL: We also um, so we just implemented open collective um which is like this sort of um community driven thing where you can sort of pay your contributors. So we're starting that off with the trial of, you know, a few people if you call people who have been contributing since um yeah, quite a few months ago and that seems to be very promising actually, I'd love to see that scale. Um and you know, hopefully we can pay people more regularly. Yeah, I got that one from stripe actually they have um, an open collective for some of their libraries and I was chatting to saw one of the depths and he says actually it works very well for them because, you know, you can move a bit faster in open source when compared to like a big cumbersome, you know, a company even though striped ships very fast. It just means that, yeah, some people who are external don't have to go jump through too many hoops. They can just get development going. So yeah, I'd love to see if I can. Well our company can make open collective scale for all our contributors.

JOE: Yeah, that seems like a really good approach. Um going back to the swag. Okay, so I saw when you launched the swag store and I went on it and you have the super based t shirt with the gold logo, right? It's literally listed for a million dollars. Has anyone accidentally clicked it?

PAUL: No, there's a few people that uh mentioned they were close to, but no, it was a million dollars because it was one of our hackathon phrases. So yeah, of course, a bit of a joke. We didn't want anyone purchasing them, but also our swag store was so empty. We like custom design, all our t shirt, we ship them ourselves so we don't want to just like throw out new new swag and just promise a bunch of things. So all we did was they all right? We designed up this golden logo for the heck it's on. So I could film the swag store with one more item and now yeah, we're getting them all printed and uh going to ship them off.

JOE: I'm just I just, It's funny because I feel like if you literally hit pay, like it would literally take $1 million dollars out of your bank overdraft. Like I guess uh hopefully slip that into sucks email inbox if he can have a slip of the phone.

BEN: Okay. Right. That's funny. Um You mentioned that like you tend to get like a lot more issues than um kind of PRs. And I think that's like very very common. I think that's I'd be surprised to like see an open source project another way. Um How do you as a team kind of prioritizing issues coming in? Especially because maybe some use cases might a little kind of niche, maybe others are more widely requested. Do you have a way of kind of telling like by popularity or what's kind of the way of triage impurities?

PAUL: Community issues. Yeah. There's no real way the thing that we do is um you know as internally as a company we got this thing ship and shout. So basically we spent all months just building and then at the end of the month we sort of shout about twitter on all the various channels. Then more broadly we come up with these sort of three months strategies. So we just finished a launch week, but three months prior to that, we sort of planned roughly what would go into the launch week. We just know the date and we think all right, maybe we'll have these things, some new things come up within those three months, depending on the customer's, well, the developers requests. So that's really how we do it. There's no formal thing in place. So for example, we just had our strategy meeting yesterday, the whole team and we decided, well the priority this time is stability, reliability, and performance. And that means now, you know, we'll definitely put that over and above anything else. We won't necessarily focus on any new features, Almost definitely will do a feature freeze. Um There might be some small things which creep in, so, you know, it's gonna fit into the broad strategy. Um that's really how we do it. And then we just try to let the team decide, you know, what might be easy, we can might be able to slip it in. So there are people who are focused on OAuth as an example. And, you know, if something comes up like a new provider, um and you also provider that someone wants, maybe a new SMS provider, and if someone contributed, it would almost definitely just put it in because it's, you know, stable. It's already there plugging in one extra provider is minimal work. Um So there's no methodology. It's just we have the company's strategy in mind and then we let the team decide um roughly what, what will get in and what won't.

BEN: For the like the focus on stability, reliability, and performance to what extent did community feedback or like user feedback have to do with that? How did the kind of open source ecosystem help or did it at all?

PAUL: Yeah. Actually this is one where being, you know, having open source but also having a host of platform is helpful. So where were quite directly in touch with the customers that people using the product, you know, we host the platform, people pay for it. And um a lot of the feedback from this one is from, you know, us triaging support tickets. Of course. Yeah. You've essentially got two types of, you know, issues. Now. It's um you've got you GitHub issues which are largely feature requests, um, a few small bugs on the libraries and then you've got your support tickets, which in my mind I just yet another way of submitting a bug, a bug report. So, you know what we see is that a lot of people um sort of, you know, do funny things with their database or, you know, they might um uh, spike the traffic, they'll upload, you know, a large amount and there's no rate limiting and, you know, we haven't given user's the tools to debug these services themselves so things might break on their service, which of course means downtime for them. Everyone gets their own Postgres database, so actually they can't really break someone else's architecture. But what we do want to do is make sure that, you know, we've made Postgres easy to use, we also want to make it almost unbreakable for them. So um yeah, I think the way that we came up with this one is more around the support tickets that we're seeing and the whole team, you know, we just spent um doing this large week, we shipped a lot of features um and it was quite exhausting. The whole team just when we got on a call with like I just wanted to focus on refactoring and stability and getting things a bit more. Yeah, robust now

JOE: [27:53] , so okay, so you've talked about Launch Week and I've seen obviously you've been following you on twitter, so I know a little bit about it, but for those who don't know like what is launch week? did it, how did it start?

PAUL: Yeah, launch week is um, well it's pretty simple. We ship one new feature every day for a week, so Monday, Tuesday, Wednesday, Thursday, Friday and actually both both times. Um, we've shipped usually more than one feature on one of the days, so friday.

We shipped, you know, some smaller things, it's always one more thing on friday. So last friday or two Fridays ago we shipped hooks, function hooks, um, the swag store and we announced the Hackathon um, and on the monday was community day, so actually we did a lot of things we upgraded to postgres 13. We, uh, cocoa released some sort of post crest eight, we've released a bunch of community features, opened up our discord. So it's just a way of announcing a lot of stuff together. The idea of launch week actually came from, you know, I mentioned when we're in YC it happened that, you know, we had this big launch at the start of YC, which was kind of accidental, someone else put us on HackerNews, then we spent three months building at YC, and we did another launch, and that was quite a good way of doing it. And the the timeline actually was great for the team. You know, we knew we had demo day coming up, everyone was shipping towards this big date, and so what we decided was let's try to emulate that even outside of way, See will always come up with this thing, a fixed timeline, variable scope, so after YC, we decided we're going to come from Alpha to beta, and we said, we'll do it on December 1st, and we'll just ship everything we can to make the platform stable, and then, you know, December 1st came around, we announced it, and after that it was really successful, a lot of growth. After that, we, you know, met in a room, we're all exhausted and for some reason we decided, well that was good, but can we do it even better, what's better than shipping one thing, one big feature is was shipping one thing every single day. So our first launch week was March of this year, and, you know, we've released storage, we released a bunch of new features and it was good, worked very well, and so we just decided, well let's keep it up. So as part of our ship and shout strategy, we just kind of plan what the next three months, three or four months is going to be, we don't really know exactly what will fit in, but we just know the date will ship something. So likely there will be another launch week or a launch event. It might not be a whole week, but it will happen, you know, sort of around first of December, where we'll focus on stability and yeah, that's just really how our team operate on these larger three month cycles.

JOE: That's awesome. Okay. And so just to clarify, you build the future first you have it ready and launch week is when it gets announced or you like enable a feature flag?

PAUL: A bit of both. Um, so sometimes it's yeah, re announcing and we'll just ship sort of one headline thing so that it is new and novel. But yeah, a lot of the stuff we've already shipped and we just wrap it up into maybe a lot more documentation, a blog post, maybe a ProductHunt and launch. So it's one of these things where it's kind of like ship once, shout twice, you gotta release many times for people to actually come across it.

JOE: Yeah, Okay, that makes sense. And the other thing I wanted to ask about and like this is me digging into the docks, I saw you got this SupaSquad, what is that exactly?

PAUL: Yeah, So that's the one that I was mentioning. Um, you know, there's a few people who have been contributing to our open source, um, since the very start and we wanted to sort of formalize this, you know, thing and you know, some of them are maintainers, some of them just help on our discord. Um, some of them, you know, do some writing. So we came up with this idea of the super squad where we can sort of recognize them as a sort of official contributors or something, maybe in the future. Some of the maintainers well, we're already paying some of the maintainers and we decided, well, how can we make this scale? And well actually, now Try to bring on about 20, will expand it to 20 people and um they'll be recognized within the community as core contributors and you know, they can do anything, they can be just Developer Advocates, they can be help with our docs, help with translations, help with maintenance, and then we'll work very closely with them, give them some swag as well, of course, um work with them if they need anything from us, we'll try to make sure they are unblocked and that's really it. Just trying to figure out a way to scale our open source contributors.

BEN: You were saying like this has been like a core group, how have your open source contributors grown over time? Has it kind of been like linear to some extent, like users of like paying or free, like users who are on the product or has some kind of core group, since the beginning, or before than that working on other dev tools before Supabase?

PAUL: Yeah, it's a good question. I would have to answer anecdotal anecdotally because we don't actually really track um you know, how many people were contributing or anything like that? Of course, it's scaled a lot more. I mean, now we um you know, just a lot more popular. So by law of numbers, it's going to happen that we've just got a lot more people contributing. Um, and the thing is though, of course, things slow down. Our team can't, you know, at the start, one person contributing. We get their changes in immediately now, it's a lot harder. We're getting so many discussions, get up discussions, so many different ideas, feature requests. It's just more than our team can actually handle. So um yeah, we get a lot. The truth is we don't track it because we know that um you know, really it's going to have to come down to a lot of the team, the people who were paying to develop a lot of this stuff. Um And that is fair. It really is fair if people are paying us, as you said, we should be the ones who are making sure that everything is progressing. And we've got funding to make sure that that is happening, so we're not going to expect that, it would be great if it happens. Um and we'll try to put mechanisms in place to make sure that happens, but but yeah, it's unlikely that we'll make that one of our metrics um it would just be nice to have.

BEN: Yeah, that makes sense and have another question which I think like anecdotal answer would probably be better and like really interesting is twitter um this coffee encoder happened because Joe reached out on twitter, I've been following you on twitter before that. What role has Twitter had in Supabase getting product feedback here um and kind of what, what have you kind of things maybe have you learned from Twitter um and kind of how you use that to interact with developers?

PAUL: Yeah, actually Twitter is one of our biggest growth channel, so so in terms of like absolute growth, like events, if someone comes on a very popular Youtuber for example, fire ship, um I think did a video of us and they, you know, in a single day, added more than any other event just because it's, you know, exactly our audience. Um if we get to the top of HackerNews um that as well as some sort of one of these one off events which will add, you know, top of the funnel, a lot of new people signing up a lot of reactivation as well, but in terms of consistent people coming onto our platform month over month, twitter is actually the largest channel. Um Actually, yeah, another one is when we get on get up trending that will add a lot of new eyes to our repo not necessarily a lot of people using using the product, but a lot of people sort of coming into our report, but yeah, in terms of sign ups and people launching databases with us, twitter is just the most consistent um So yeah we've it's a different strategy I think, you know twitter, you can think tweets have a half life of sort of six hours so the focus is not great, you've got to be there front and center all the time with the type of content, which is very different avenues. You give very in depth technical blogs. Twitter is memes. I mean we were just like basically if you go through twitter is just like a bunch of programming memes and we you know Sprinkle a bit of you know, coding content in in between but people if you look at the interactions, people just love um the memes that we generate. So luckily our team also love generating memes and coming up with them, so we've got no shortage of content to post there and yeah, that's, that's really the strategy that's hilarious, the main part.

JOE: Um, okay, so I think we're coming close to the end, so I think I'll ask a final question and this is more kind of an open ended one. Is there anything else that you want people to know about Supabase or anything you wish we had asked you?

PAUL: Oh, that's a good one. No, I think the only thing to re emphasize is that, you know, we're just Postgres and we started this company to evangelize Postgres. So if you haven't already used Postgres, it's just a phenomenal tool. It's just like the absolute gem of open source, the way the model whereby it works is amazing. Um, it's got no company behind it. It's just a bunch of, you know, different companies and different contributors trying building upon it. So, if you don't support Supabase, absolutely fine there are alternatives. Firebase, of course, as an alternative, but do check out Postgres, make sure you use it check out as well. Um some of the other tools that we use Postgres, which builds an API on automatically on top of Postgres, it's just these tools are phenomenal, so do check them out, try them out and uh yeah, I just could not promote Postgres enough.

BEN: Well, that's a great way to wrap it up. Try Postgres and I would encourage people to also try Super Bass because to me, at least it looks like one of the easiest ways to try Postgres. I can kind of understand as I experienced for a little bit, and is great way to start a project and get going. So, um, yeah, I mean with that, Paul, thanks for joining, I hope we can do another one soon, and I'm definitely looking forward to seeing more memes on twitter.

PAUL: Thanks. Thanks. Thanks for having me, Yeah.