Coffee and Coder - Chat with Paul Copplestone, CEO of Supabase

great it looks like we're live um welcome to coffee encoder everyone um super excited to super excited for this conversation um today we are joined by paul copperstone the ceo and co-founder of superbase um we're also joined by joe privy um who is our open source engineer at code server so um we'll have some interesting and it goes just in general about kind of working within an open ecosystem what how open source communities can help like building projects stuff like that so um without further ado paul um i'd love to hear as uh a new user i just signed up but i haven't created a project um what superbase is and why um why he created it yeah sure so super base is the uh 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 one-to-one mapping of firebase for those who don't know what firebase is it's basically a full back-end suite it gives you a database gives you auth gives you functions it gives you storage for file storage and we're building this full 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 um and we use various different open source tools to achieve exactly the same result but it's not an exact one-to-one mapping it's just really targeting the features of firebase yeah and that was something i noticed kind of with my limited research on superbase is that you use fully open source ecosystems and kind of leverage the communities behind that to do kind of the core of the product and then kind of stitch it together um and i i think a common criticism of open source is well there's a lot of like really good tools um there there aren'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 an 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 um i 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 reuses a lot of open source tools 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 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 um 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 they've got road 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 round a lot of developers and we said you know what do you think of postgres they said i love it and we'd say what are you using and they'll say firebase and we'd say why and they'd say well it was just so easy to get if i'm running so we just decided well we'll make postgres as easy or easier to use than firebase um that's okay i would love to hear maybe you talk a little bit more about the role of open source at superbase like yes it makes sense to use postgres um and it being open source but but why open source a lot of the tooling and services and features of superbase itself yeah well i mean it wasn't really much of a decision we just wanted to be open source my co-founder and i are philosophically just very much like that loved the model loves that um sort of philosophy of behind open source so i mean it wasn't a tactical it wasn't really a business decision you know a lot of people say oh should i do open source maybe for marketing it's just that we love that way of operating of building you know everything's in public uh of doing things so we try to open source everything that there are i must admit some things which are not um open source at the moment um our platform well our platform itself will never be open source 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 um 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 that's awesome yeah that's um that was one thing that i actually discovered as well was that um 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 um i'm curious like do people find and choose superbase because they want to sell post um solutions or is it just because they feel more comfortable working with open source components um what what is like what are some of the driving factors for people to use it yeah um self-hosting not really um to be honest probably uh first of all we've got no telemetry in our open source offerings for the self-hosting um 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 say in terms of like what the internal numbers of how many people are using it and just want to get started the idea behind super bass is you just want to get started fast right um less so 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 we're 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 thing though that they do want is the option to migrate away if things go wrong so you know the promise of firebase and firebase's 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 super bass you can use us until we break which hopefully we will never break um but if you wanted to you know pick a part part of our offering and host it yourself then you can right and and that's almost interesting as well because um you could use specific services from superbase and because it's open you could even like maybe if there's like a security risk or maybe some part of it doesn't necessarily scale for a team they could go and then post it themselves or just kind of have the security of being able to do stuff yeah correct and people do use specific parts i mean maybe like our author is now becoming very popular um everything stitches in with postgres it's got a lot of providers we've 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 for gdpr or californian regulations so um yeah even just specific parts of the stack um are great and then of course all the libraries that we provide to make it easy to use uh useful even on your self-hosted uh services yeah um something else that i like notice from from actually using firebase is that um well a lot of the services are cool they're very arbitrary right maybe like the way that that off works it's like the second you want to use off a different way or get the data it's their their own system for doing so um how with super base you kind of provide abstractions to make like things easier while still kind of using the the core components i know it's a little bit of a vague question but i'm curious like to hear like what your just general approach to that is yeah yeah actually um so we're in yc somewhat windy um and um what happened was we had this sort of accidental launch um 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 promoting and growing we just enter myself and 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 it a very specific way postgres has this thing uh row level security which is amazing um you can write you know very custom security rules around your um database and so we spend all our time trying to figure out how to make row level security work with another external tool netlife's go to server for authentication so um yeah in the end we figured out how to make it work um 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 author 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 we sort of map all your s3 buckets into your postgres database and you write access rules once again using row level security so everything is just part of the database now and it's great because once again it's just a pg dump if you want to migrate away right and you're kind of using different um different like features that kind of already exist in the in the open source products um kind of leading into the next thing because you're using all of these features that like maybe are from like an upstream um thing such as pos quiz or i saw that um i can't remember the name off-hand but what you're using for um like real-time database um things like that how um how is your team like able to like deal with or necessarily like contribute to or like understand problems upstream um this is something that we kind of see a lot at coder because we have a similar mentality where it's like um we don't want to build something that already exists and has already been implemented a lot better but maybe we're doing some kind of wacky use case on a feature that was um 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 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 or just a general like kind of methodology for for working kind of in those upstream communities yeah interesting um yeah it's a good question do you guys actually fork and keep uh maintain forks or how do you usually do it uh for the most part we don't know um just kind of contribute back upstream yeah yeah nice okay um so yeah a few different ways the the real time that one that you said was actually we developed it it was the very first repo actually that i developed even before super bass so that one's easy that was really uh sort of the start of super bass the real-time repo but um yeah some others that we've got we use postgrest um that one's easy because we employ the lead maintainer so that's always a good way to um 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 go through which is done by netlify because actually now our fork is diverging so far one big thing is that gothu was developed with mysql and we developed with postgres so they actually don't want to pull in a lot of their upstream code so we just tried to figure out we we now have to maintain a fork and we just try to figure out what we what they might want which is largely just security features um yeah so this one's an interesting one because if you think about um netlify they're not an auth provider um they have netlify identity which is what they use um go to 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 um which it is you know a lot more activity on um because it'll be a much more active repo um i i think that's the only sort of thing that i could say in in hindsight um otherwise it hasn't really been an uh too much of an issue we usually if we run into a problem do a fork temporarily um 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 we post rest we don't have a fork at all we upstream everything immediately and just use nightly builds um kong is an api gateway we don't have to do anything there um occasional patches but it's it's very small and um yeah so far it hasn't been an issue at all luckily so so kind of piggy piggybacking off that like you know if we look at some of these projects and we look at the languages that they're written in you know we've got elixir type scripts 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 and back and forth between languages yeah uh the engineering team is 20 so yeah it's 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 postgres postgres is written in haskell which is very hard to hire for right but um yeah but um you know he's he's one of the core maintainers so of course he he knows it um and likewise when people are contributing very heavily we've hired a number of times just people who are contributing to the code base 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 you know deeply skilled in a particular language they're always interested and people in our team are always uh 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 with enough time so um yeah yeah it's not really a huge issue cool um you were kind of discussing how it you're mentioning how easy it is kind of to discover the problem and maybe if it's not like a language you necessarily know or something like that given that like the product is open source do you ever find kind of community members or um users finding bugs and even fixing them in the in the code definitely yeah or even implementing features so i think someone wanted a um 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 one day later we had implemented it 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 closed source system then it'd be well almost well it's impossible because their code isn't there but um but yeah i mean that's the dream of of uh open sources 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 yeah i'd love to i i have to admit i'd be interested to hear your feedback on this i'd love to get more of that people are very good at reporting bugs of course but um the team does do most of the work i would love to somehow come up with them is that 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 are you guys doing anything there with the community yeah i can take this one ben um yeah it's it's interesting because it feels like it feels like um what's the word like it's almost like a tightrope you know 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 um and so like we try at least for on the code server side at coder um which for those who aren't familiar it's 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 in issues discussions and like if people want to contribute we are there and like we'll guide them um and ben does a great job like you know we'll partner together and be like oh this person submitted a pr to fix this bug like let's send them some swag so that's one thing you do but it's tough you know 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 a 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 for ways to improve yeah yeah yeah it's a tough one and yeah i mean it's a good point i mean you don't want it 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 [Laughter] makes it very easy to um contribute back so yeah okay good and swag actually i've noticed that um we just opened a discord people developers love swag so we try to give out t-shirts to anyone who uh contributes something meaningful and uh that goes over very well yeah 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 any issues they've run into um something else um 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 fork that has collaboration built in so that was very very exciting to see and as um it was great kind of to see that like we we had our plug-in architecture documented and and things like that so there's there's definitely some of that 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 um if you have to run a whole bunch of commands 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 yep yeah definitely the case 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 a trial of you know a few people a few cool people who have been contributing since um yeah quite a few months ago and um 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 an open collective for some of their libraries and i was chatting to saw one of the devs and he says actually it works very well for them because you know you can move a bit faster and open source when compared to like a big cumbersome um uh you know uh company even though stripe ships very fast it just means that yeah um 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 uh well our company can make open collective scale for all our contributors 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 bass t-shirt with the gold uh logo right yeah and it's it's literally listed for a million dollars has anyone accidentally clicked it no there's a few people that uh mentioned they were close to but um no it was uh a million dollars because it was one of our hackathon prizes so yeah it was a bit of a joke we didn't want you know i'm purchasing them but also our swag store was so empty we like custom design all our t-shirts 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 say all right we designed up this golden logo for the hackathon so it could film the swag store with one more item and now yeah we're getting them all printed and going to ship them off i'm just i i just it's uh funny because i feel like if you literally hit pay like it would literally take a million dollars out of your bank in overdraft does anyone have that i guess uh yeah yeah i'll uh hopefully slip that into zuck's email inbox see if he can have a slip of the phone that's funny um you mentioned that like you tend to get like a lot more issues than um kind of pr's and i think that's like very very common mean 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 prioritize those issues coming in especially because maybe some use cases might be 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 kind of triaging through these community issues yeah there's no real way the thing that we do is um you know as internally as a company we've got this thing ship and shout so basically we spend all months just building and then at the end of the month we sort of shout about it twitter on all the various channels then you know more broadly we come up with these sort of three-month 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 customers um 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 there might be some small things which creep in so you know it's got to 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 might be able to slip it in so there are people who are focused on auth as an example and you know if something comes up like a new provider um a new alt 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 so there's no methodology it's just we have the company strategy in mind and then we let the team decide um roughly what what we'll get in and what won't and um for the like the focus on stability reliability and performance kind of to what extent did community feedback or like user feedback have to do with that um i mean were you seeing a lot of like issues where people were like we're running into these things or is it something like oh we're before we're about to do this next feature we there's something you kind of already knew um how like did the the kind of open source ecosystem help or did it at all yeah actually this is one where being you know having open source but also having a hosted platform is helpful so we're more we're quite directly in touch with the customers the people using the product you know the hosted 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 um uh yeah we're you've essentially got two types of you know issues now it's um you've got your 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 are just yet another um 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 spike their traffic they'll upload you know a large amount and there's no rate limiting and you know we haven't given users 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 launch week we shipped a lot of features um and it was quite exhausting the whole team just when we got on a call we're like just wanted to focus on refactoring and stability and getting things a bit more um yeah robust now so okay so you've talked about launch week and i i've seen obviously 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 how did it how did it start 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 um 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 hooked the swag store and we announced the hackathon and on the monday was community day so actually we did a lot of things we upgraded to postgres 13 we uh co-released sort of postgres eight um we released a bunch of community features uh opened up our discord so it's just a way of announcing a lot of stuff together the idea of um launch week actually came from you know i mentioned when we're in yc it it happened that you know we had this big launch um at the start of uh yc which was kind of accidental someone else put us on hack news then we spent three months building at yc and we did another launch and that was you know 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 emulate that even outside of yc we'll always come up with this thing a fixed timeline variable scope so after yc we decided were 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 uh 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 well 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'll be another launch week or a launch event it might not be a whole week but it'll happen you know sort of around first of december where we'll um you know focus on stability and yeah that's just really how our team operate on these larger three month cycles that's awesome okay and so just to clarify you build the feature first you have it ready and launch week is when it gets announced or you like enable a featured flag 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's new and novel but um 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 um maybe a product on launch so it's one of these things where it's kind of like ship once shout twice you've got a release many times for people to actually come across it yeah okay that makes sense and then the other thing i wanted to ask about and like this is me digging into the docks i saw you got this super super squad what what is that exactly 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 uh do some writing so we came up with this idea of the super squad um where we can sort of recognize them as 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 we'll actually now try to bring on about 20 we'll expand it to 20 people and they'll be recognized within the community as core contributors and you know they can do anything they can be just um 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 work with them if they need anything from us we'll try to make sure they're unblocked and that's really it just trying to figure out a way to scale our open source contributors that's awesome how um you've said like this has been like a core group how have your open source contributors grown over time um has kind of been like linear to like the amount of um like users or like paying or free like users who are on the product or i'm kind of out it has been kind of a core group since the beginning or even um like earlier than that working on other dev tools that kind of led into super bass yeah it's a good question it's um i would have to answer it anecdotally anecdotally because um we don't actually really track um you know how many people were contributing or anything like that of course it scaled a lot more i mean now we um you know are just a lot more popular so by a lot 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 um changes in immediately now it's a lot harder we're getting so many you know discussions github 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 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 you know are making sure that everything's 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 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'll just be a nice to have yeah that makes sense and i mean another question which um i think like an anecdotal answer would probably be better and like really interesting is um twitter um this kind of coffee encoder happened because joe reached out on twitter i've been following you on twitter before that what role has coder had in in supervisor has um what role has twitter had um getting products mixed up here um and kind of what what have you kind of maybe learned from you learned about twitter um and kind of how you use that to interact with with developers yeah um actually twitter is one of our biggest growth channels so so in terms of like um absolute gross like events if someone comes on a very popular youtuber for example fireship 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 hack news um that as well is 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 um in terms of consistent people coming on to our platform um month over month twitter is actually the largest channel actually yeah another one is when we get on github trending that will add a lot of um new eyes to our repo not necessarily a lot of people um using using the product but a lot of people sort of coming into our repo but yeah in terms of sign ups and um people launching databases with us um 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 i can use you give very in-depth um technical blogs twitter is memes i mean we just like basically if you go through our twitter it's 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 haven't got no shortage of content to post there and um yeah that's that's really the strategy that's hilarious the main part um okay so i think we're coming close to the end so i think i'll ask a final question and and this is more kind of an open-ended one uh is there anything else that you want people to know about superbase or anything you wish we had asked you oh that's a um it'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 it's the absolute gem of open source the way the model whereby it works is amazing it's got no company behind it it's just a bunch of you know different companies and different contributors trying and building upon it so if you don't support super base absolutely fine there are alternatives firebase of course as an alternative but do check out postgres um make sure you use it check out as well um some of the other tools that we use postcrest 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 i just could not promote postgres enough yeah it's a great way to to wrap it up um try postgres and um i would encourage people to also try super bass because to me at least it looks like one of the the easiest ways to try postgres and kind of understand that experience for a little bit of a kind of ready to go start developing just get the project finished kind of way so um yeah i mean with that paul thanks for joining um hope we can do another one of you soon and i'm definitely looking forward to seeing more um memes on on the twitter [Laughter] thanks ben thanks jared thanks for having me

Channel: Coder

Views: 308

Rating: 5 out of 5

Keywords: cloud, ide, development, environment, coder.com, coder, Devops, DevSecOps, development environment, developers, software production, VS Code

Id: sHSS8nLSVUc

Length: 38min 58sec (2338 seconds)

Published: Thu Aug 12 2021