Supabase Security with Inian Parameshwaran
57:46 Share

Supabase is an open-source, back-end-as-a-service platform that competes directly with Google's Firebase. A key distinction between them is that Firebase is a document store, while Supabase uses Postgres, which is an SQL-based database management system. Software Engineering Daily last covered Supabase in 2020, when its founder, Paul Copplestone, came on the show, and a lot has changed since then.

The platform has continued to grow its feature set, and importantly, this growth has come with an expanded number of security considerations.

Enyan Parmeshwaran is head of product and engineering at Supabase and a former Y Combinator fellow. He started at Supabase when the platform was still in alpha and has been there for three years. He joins the show today to talk about the current feature set of Supabase and the various security challenges that he and his team work on, including how to handle crypto mining exploits, IP blocking, DDoS attacks, and more.

Gregor Vand is a security-focused technologist and is the founder and CTO of MailPass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.

Hi, Inean. Welcome to Software Engineering Daily. Hey, Gregor. Thanks for having me. It's good to be here. So, Inean, we've had Superbase on the podcast back in 2020. We spoke with Paul, who's the CEO. Today, we're going to be hearing about all the progress since then, and especially we're going to dive into some more of the security considerations. You know, this is running such a data-critical platform that is Superbase. And we're going to be hearing about some of the

So maybe to help our listeners, maybe you could give a quick recap of what is Superbase and also how did you get involved and, you know, what was your road to joining Superbase?

Yeah, sure. Since 2020. Okay, that's a long time to give a recap on, but I'll try my best here. Okay, Superbase is the open source Firebase alternative. We build the primitives that Firebase offers, but using an open source stack. And the main difference with Firebase also is that we use a relational database like Postgres and

Since we started off with the real-time engine, which streams your database changes to your client. We started off with that by building a real-time engine on top of Postgres. Since then, we have added storage where you can arbitrarily store files. We have added auth so that you can add authentication in your app in just a few lines of code and edge functions for running code in

in our globally distributed servers. And more recently, we have added vector database offering based on PG vector. So that's all the high-level products that Superbase offers. The general idea is that we want to make it as easy as possible for app

application developers to get started with their application and we prioritize the developer experience as much as possible, similar to what Firebase does. Firebase is super easy to get started. We want the same thing for Superbase where you can get started. In fact, our tagline is "Build in a week and scale to millions."

So we want the initial experience to be as simple as possible. But at the same time, we want to make sure that the architecture choices that we make help you scale to millions of users without much effort on your side. So that's Superbase. I've been with Superbase for a little more than three years now. And yeah, when I joined the company, they were in

in Alpha back then, and they were looking for someone to help with some of their infrastructure problems because they were planning to go to beta. And I remember they had this checklist of things to work through before they were comfortable calling themselves beta. So I joined the company and started working through that checklist to make sure that we could launch SuperBase beta. That was in December 2020, I think. Yeah.

So started off with a lot more of the infrasite first. And over time, once we had the infrastructure set up, once we had the database and the real-time engine set up, and since we also started calling ourselves open-source Firebase alternative, people started comparing ourselves with Firebase, obviously, and then started asking the other primitives that Firebase provides. So the next biggest thing that users were asking for is storage. So I helped launch the initial version of SuperBase Storage.

And

And after that, I also helped launch the initial version of Functions, which is the next thing that people were asking for. So for Superbase, most of the Superbase components can be directly used from the client side itself. And that's how our security model is also designed. So if you design your application correctly, you can call your Superbase APIs directly from your website or your mobile application. But there are still some aspects where you need to have your

your code running in a secure environment like a server. For example, you're processing webhooks or you want to integrate with Stripe where you need a secure context. So that's where functions comes in.

So after that, I have sort of my role has now changed to the head of product and engineering where I mostly help the other product teams prioritize the right things. So this is mainly by making sure we funnel the feedback from all the different places. We get a lot of feedback from our users, from Twitter, from Reddit, from Discord. So my job is essentially to make sure that we give all this information to the product teams and make sure that they have the right information

to build stuff that users are asking for. And yeah, so that's sort of how my role has changed at Superbase itself. Before that, I ran my own startup called TechSecure. Again, it is sort of in the DevTools space as well. I like DevTools in general. And yeah, we are building tools to make websites go faster. And before that, I did another project, our

startup which didn't really work out in the security lab of my university in Singapore. So yeah, that's sort of been my background. Most I like

DevTools security performance and yeah, here I am. Yeah, very cool. And I remember when we met, so we met in Singapore where we're both located at the moment and DexSecure, your last startup, still has quite a following, at least in the city, I believe, which is very cool. Okay, so what would you say, we've heard now a bit about sort of how the products evolved over the last three years and obviously security has played a major role

role in that given scaling to the user base that you have now so you know what would you say was like the first major security hurdle that super base had to overcome when growing from you know an early stage startup to a product that's used in production yeah i mean security is

very, very critical to us because we host user data in our databases, right? And customers trust us with their own data as well. So it's one of the top priorities to make sure that we are as secure as a platform can be. And there wasn't like one major thing that we did to improve our security. It's a lot of small decisions and product decisions and

improvements that we have made over the years. But I can probably give you a couple of stories from the early days, which made us rethink some of the practices that we were doing back then. So I remember when I first joined the company, like right within the first week or so, a customer who was using Superbase at that time said that, hey, my database is running slow. Can you take a look at why it is? I'm not running that many queries on it, but still the database feels slow.

So we ended up investigating his database to see what the issue was. And then we found his CPU was at 100% for the last 20 minutes or so. And because of that, his queries weren't running as fast. And I guess you might get from where I'm going with this. It turns out that his server had a Bitcoin miner installed somehow. The user didn't and somehow a Bitcoin miner got in there. This was again like three years ago. And then...

We started investigating how the Bitcoin miner got on the server. I mean, if you give compute, I guess people just try to figure out how to mine Bitcoin on it. So it turns out how the attacker had gotten is because this user had his Postgres password set to something super simple, like monkey123 or something like that. And because of that, they could just get into the front door, say, hey, this is your IP. I see a Postgres database running there.

And the immediate fix that we were able to do is to make sure that users use strong passwords before for any super-based database. So right now you can't launch a super-based database with a weak password like that. So that was the short-term fix. Then over time, we implemented fail-to-ban, which is a service which analyzes log files and is able to prevent brute force attacks from the same IP. So we automatically block

IPs which have been trying to guess passwords and they get it wrong after a certain threshold. And more recently, we have also launched network restrictions where you just don't put the database on the internet and you can only expose certain IP ranges to it. So those are the fixes that we have done over the time. But yeah, this was pretty early on where we had to figure out how...

to keep our own system secure, but also make sure that the users don't shoot themselves in the foot by having something like a weak password on their Postgres database. So that was one interesting story. And even there, one of the other components that the attacker needed to get the Bitcoin miner was the ability to execute

arbitrary code and turns out that postgres is pretty powerful like there is the copy command in postgres which lets you i mean usually it's used to copy say a csv file or something into your table but the copy command also has like this program attribute where you can pipe the standard output of a program also into the copy command so that pretty much lets you execute arbitrary programs

and one of the fixes here that we had to do is to let users

copy files like a CSV file but not execute program commands inside the copy command. Turns out there was no easy way to do this. What we did was we ended up building our own extension called Superutils. It's also open source that you can check it out on our GitHub. What this extension does is what I mentioned before, it lets you copy files but not execute programs.

on the super-based database. And the other reason why we went down this road is to make sure that we don't fork Postgres itself. Looks like some cloud providers actually fork Postgres to plug security holes like this, but we ended up going down the extension route because we strongly believe that

It should be just vanilla Postgres where possible. And since Postgres is so flexible that you get all sorts of hooks into the different lifecycle events in Postgres, we were able to fix this security hole with just an extension. So yeah, that's sort of like the various changes that we had to do just coming from this one issue that we observed.

when the company launched. So that's why I mentioned that it's not just one big thing. There is one problem, but there are multiple defenses that you can have to fix that one problem, which is what we ended up doing. And yeah, since most of our workload is on AWS, it's just making sure that our AWS security conflict is as bulletproof as possible.

Again, this is one of the systems that I put pretty early on was to analyze the audit logs inside AWS to figure out if something fishy was going on. And I remember, so AWS has this product called CloudTrail, which is audit logs for your AWS environment.

and you can pass the audit logs to figure out, yeah, something weird is going on. And we had alerts set up in Slack to when one of these conditions gets triggered. And what ended up happening one day was that we got an alert that someone logged in without two-factor authentication into our AWS account. And that started ringing alarm bells everywhere for me. And I was like, hey, who's logging in without 2FA? I thought we enforced 2FA across everyone in

and AWS. And then it turned out that someone was logging in to AWS from their Africa region. And at one point in time, again, this was pretty long time ago, if you log into AWS console from the Africa region, they didn't validate your 2FA at all.

So even if you have two, if a configure turns out they didn't validate, and then we ended up raising ticket to the security team. And of course now it's been patched, but again, that was another interesting incident that happened pretty early on where, yeah, it's like we are responsible for our own infrastructure, but also all our vendors as well. Right. Yeah. We have a lot of like interesting incidents like these, which makes it critical internally to show why security is important and

And also, yeah, we have implemented a lot of these features over time to improve the security of the platform. Yeah, that's super interesting. I mean, just hearing that anecdote about the AWS side, that kind of, I think, is a great example because you're showing how you have to sit. Well, you've chosen Superbase to sit in this middle part and actually you've got users potentially doing kind of work.

we'd call maybe slightly stupid things like creating passwords that are just very easy to guess. On the other side, you've also got these sort of third-party risks that

like AWS and you could never have predicted the Africa region piece at the time. So just bouncing back briefly to super utils, to me that kind of almost sounded like almost like an ORM for database management in a sense, or is that how to describe it or how would you term that? So it's not exactly an ORM. It's more that the, so usually Postgres is like the super user inside your Postgres cluster and you can,

do whatever is possible within Postgres as the Postgres user. And over time, we realized that we can't give super user access directly to our clients because we are running multiple Postgres databases of our customers in our environment. And as the Postgres super user, you can do a lot of different stuff. That copy command is one of the things, but you can do a lot of other stuff as well. Like even reading files, for example, I didn't know this

this before i joined the company that you can actually read files as from sql sounds crazy but yeah so what superutils does is that it lets you do certain operations without

being the super user yourself. So over time, what we have done is that initially when SuperBase started, Postgres was a super user. But since then, we have created a separate user called Postgres, but it's not the super user. But we still want users to do certain actions that a super user can. And that's where super utils comes in. It's not like an ORM, but it's sort of like, it's a Postgres extension, which analyzes the queries that are being run.

and decides to run certain queries, ask the super user if it's okay from our security model and

And it also, like the copy command before, yeah, it sort of allows copy commands, but only if the input is a file. It doesn't allow if the input is a program. So it's sort of like a firewall, if you want to make a vague analogy to it. And it's built as a Postgres extension. It's open source and it's running on all your super-based databases. Got it. That makes a lot of sense.

So if I'm a user thinking about Superbase, is it fair for me to say, oh, if I deploy my Postgres on top of Superbase, I don't need to worry about security as much? There are some aspects of security that are taken care of by Superbase, and there are some which is on you as the application developer. So we actually have a document called the shared responsibility model on our docs, which essentially says,

what are you responsible for and what is Superbase responsible for, right? So on Superbase, we promise to take care of like the infrastructure security, make sure our AWS is, and any cloud provider that we end up using is as secure as possible. We make sure that we give you DDoS protection on all your different APIs. And we make sure that, yeah, we have stuff like fail to ban, network restrictions, SSL enforcement. We give you all these different things.

things and some of it is enabled by default. So for example, all SuperBase projects come with a certain level of DDoS prediction. And if you're on the enterprise plan and stuff, we give you a higher level of DDoS prediction. We use secure defaults where possible. And again, we guarantee that your Postgres database is completely isolated from other Postgres databases that are running on our infrastructure.

So these are some things that we take care of on our site, but there are also stuff that you need to take care of from your site as the application developer. This again means that, okay, if we give you tools that you can use, for example, we give you the option to enable 2FA on your account.

So when you're developing, it's just a hobby project. Probably you don't care if Superbase has 2FA, if it's just a hobby project and you're just kicking the tires around. But if it is a production project that you are actually storing your users' data in, you want to make sure that it has 2FA enabled, it has SSL enforcement enabled, it has network restrictions enabled, all these different things, right? So that responsibility lies on you. And

Also, the security model of SuperBase depends on RLS quite a lot, which is row-level security. And there also, we give you the option to enable row-level security for all your tables. But again, it's on you to make sure that it's enabled on all the tables that you create and you write the proper policies which authorize users based on what kind of user they are.

And I could go on, but that sort of like gives the rough distinction between what Superbase is responsible for, which is everything on the infra side and making sure that the tenants are properly isolated and stuff like that. On your side, you are responsible for following the best practices and making sure your Postgres is properly protected, either through RLS or some other mechanism. And you use some of the other security tools that we give you, like network restrictions and so on.

Yeah, it's like anything in security where it's only as good as the person who's actually implementing, you know, you as the provider of super base, you can give a lot of tools and a lot of things like sensible defaults, etc. But it still is up to the ultimate end user who's in this case, the developer to still take advantage of that and not ignore things.

So, you know, given super base is entirely based around Postgres, what considerations, especially from a security and a data integrity standpoint, would you say were sort of key to choosing that, you know, Postgres over any other relational underpinnings or even say MongoDB? Yeah. Traditionally used Postgres was partly because

our founder coppel he was using postgres in his previous company and he needed some real-time capabilities on top of postgres which is how we built real-time engine and that sort of super way started from that so it might just be why postgres at that point is just coincidence i guess but over time postgres we have doubled down on postgres since then mainly because yeah it's

It's battle tested. It's being used at scale by multiple companies. It's been around since the 1980s, right? And it's gone through multiple iterations. And the Postgres community itself places a huge...

on making sure the database is as durable as possible. And you get all the other benefits of a transactional relational database as well, right? You get asset compliant transactions. You make sure that you as the application developer can push more of the logic to the database because you have

all these different capabilities that a relational database like Postgres gives you. So that's probably the durability and the focus on data integrity components, which has made us double down on Postgres. And we also like Postgres because of the flexibility, right? Like the extension ecosystem of Postgres is

incredibly vast. You can do very fancy stuff like PostGIS is one of the most popular extensions in Postgres and you can do a lot of interesting things with that.

You can build a time series database like Timescale has done on Postgres. I'm just constantly amazed by the different kinds of things that you can do with just an extension in Postgres. So that was another part of it, which we felt that gave us the right hooks into Postgres as we wanted to build

build more things with Postgres itself. So that's the other aspect on why we chose Postgres. On the security side of things, yeah, Postgres has a very granular and flexible permission model. Like you can say this user must be able to read the tables in this schema, but not in the schema, but he can read this table, but not update it. He can

call this function but not updated. Yeah, you can go as granular as you want, which is pretty nice. And it also has this concept of road level security, which we sort of use pretty much everywhere in Superbase across all our other products as well. So it gives you the right primitives to build a very secure, robust application on top. Yeah, some of those features that you're talking about, I think a lot of us forget that they do exist.

I've worked with Postgres a lot. Personally, I quite like a NoSQL database, so I'm quite into MongoDB for a lot of the projects I work on. With that comes, I'm sure a lot of people have heard of Atlas, which is the MongoDB hosted version of MongoDB. Would you say that Superbase is sort of in any way similar to what Atlas is maybe doing for their own product? Is that an analogy that we can use at all?

Yeah, I would say part of it, yeah. Like, for example, with Atlas and with Superbase, you don't need to think about the operational aspects of running Postgres or MongoDB. You don't need to think about, hey, there is a new version of Postgres out. How do I make sure I upgrade to the latest version? And do I know if all the extensions I run...

are compatible with the latest version, we just make it a one-click upgrade, right? So you don't need to think as much. You still need to think if there are breaking changes that your application needs to do. But in terms of actually doing the upgrade, rolling back in case something goes wrong at

Atlas and Superbase have nailed this down because we run hundreds of thousands of databases for our customers, and then we have built this capability over time. I think one capability that people like about Atlas also is that you can launch databases in multiple regions,

across different cloud providers. At Superbase also we support more than 10 different regions right now, and we are adding more cloud providers in the upcoming year. So I would say there are similarities in that sense between Atlas and Superbase, but at Superbase we also give you, it's not just a database, like Postgres is at the center of it, but we also give you the other primitives, as I mentioned, like storage, real-time,

vector database all this other stuff which makes it easy for you to build your application so yeah in that sense super base is not just a database it's probably a back-end as a service if you want to call it that yeah very interesting and then not really a topic for today but the vector database side that's clearly very interesting you know given where things are headed from a

AI perspective. So, you know, let's talk about a major feature of Superbase, which is the auth piece. So, you know, that's covering in this sense, both authentication and authorization. How is Superbase handling these for both your customers and their users? And what is Superbase adding over and above Postgres sort of vanilla in this regard?

Superbase, our auth server is based on the project called GoTrue. So initially, Netlify had this project called GoTrue and we based our auth servers on that. And the main reasons why we chose it was that we need something super simple to get started with for our users and

NetFi, I think they built this to use inside their own systems. Probably, I'm not too sure on the motivation there, but it fit our use case pretty well. It integrated with the Postgres database pretty easily. I think that was one change we had to do. Initially, it was meant to be used with MySQL, I think.

and we have since changed it so that our AuthServer is able to use Postgres. The reason why we need Postgres here is that our AuthServer is able to store all the metadata about your users right in your own Postgres database, which I think is very cool because if you want to find

say all the users who have signed up with a Gmail account in the last 24 hours. It's a simple SQL query. You do select star from auth.users and you match the email and you match the created at column and there you have it. You don't need to think about, hey, how do I call Superbasis auth API and how do I filter and sort? It's just SQL, right? So if you know SQL,

can do all these cool things really easily. And because the metadata is also inside Postgres, you can sort of link your user's ID to other items in your schema. So for example, you want to associate a particular user's ID with a file that they own or a

some other entity in your database, we make it super simple because it's again right there in your database. So that's GoTo. We have since forked it and we have added a lot more features that our users were asking for. On the authentication side, we let you

with very minimal configuration, have email password logins, magic link logins, and be integrated with more than 20 different social logins. This is like, say, if you want to add login with Apple, login with Facebook,

login with Discord, Telegram. There's just a bunch of different things that you can see in our docs. I think this is one of the simplest APIs that I've seen also. If you want to sign up or sign in with a particular provider, it's just a few lines of code. That's on the authentication side. More recently, we also added single sign-on with your org, so that makes it more viable for the enterprise use cases.

On the authorization side, once your user is logged in, you probably want to see what the user is capable of doing. We use row-level security to make sure that you can define what the user can do with just row-level security policies.

Yeah, so we have heard about row level security, RLS a couple of times so far in the episode. Maybe, you know, could you just describe that to someone who's maybe just unfamiliar with that concept in general? And, you know, is it actually is it unique to Postgres? Or do we find that in other places?

Okay, yeah. So role level security is, I don't know if it's unique to Postgres. I think probably SQL Server has it. But essentially what it does is that it lets you write your policies in SQL. And it's a way to do authorization at the database level itself. So as a user...

you can write a row-level security policy and this policy gets evaluated on each row of the database before the results are returned to

the user. So I think this is easier if I use an example to explain what RLS is. So imagine if you have a table called users and the primary column is ID and you only want a user to update his own user ID record. You don't want a user to update someone else's username, for example, right? So you can write an RLS policy which says,

which gives the user permission to read and update only his own user ID record. Even if in your application code to something like select star from users, if the RLS policy is enabled and enforced, the user will only see one user record from the user's table. Even if you have 100 users and ask the user if you do select star with no limit,

clause or anything, you still just see that one record. So that's the database enforcing permissions at the database level itself. And you on the application level don't need to say select star from users where user ID equal to the user's ID like that where clause you can sort of ignore if

if you have RLS enabled. So that's a way for you to push the authorization logic right into the database. And the other advantage of that is that it doesn't matter which client is querying the database since it all needs to come back to the database eventually. And since the permission system is enforced in the database, you can sort of be sure that once you write it properly, test it properly, any client that's accessing the database is going to do the permission checks in the right

Since it's all happening within Postgres, also it can be optimized extremely well and it runs very fast instead of having the application check being done outside the database, say in your application layer or something like that. RLS in general, it's a way for you to define your policies in just SQL. We use that authorization logic

across our different products to do authorization. Yeah, well, so yeah, thanks for being able to explain that in a way that I'm sure a lot of people can now understand a lot better. And at the end of the day, it's still a fairly complex process

to actually implement properly. So I think that's clearly somewhere where Superbase comes in and just takes a whole ton of time away. So which parts of Superbase is that concept implemented in? Yeah, so RLS can be a bit difficult to grok when

When you first come in and we are trying our best to make sure that's as easy as possible. So for example, in our dashboard, we have this super base AI integrated into the SQL editor where you can ask it to generate different queries. And we are making sure that that works well with RLS as well. We have this RLS editor again, which makes it easy to write RLS policies. And with the help of AI, we can make sure that it's

it's a good starting point for you to come up with all these different RLS policies and can just describe what exactly you want. And we are trying to come up with a policy that would be a good starting point for you to build more complex logic over if you want to. And

Yeah, so that's RLS policy and how it's used within Superbase. Mentioned before, like for Superbase auth, once you sign in using Superbase auth, you get JWT token with sort of the role of the user and the ID of the user and with...

RLS policies, you can take these roles and ID and use it in your own RLS policies. In the database for a particular table, you can say if the user has logged in with this domain name,

he can access this table. So stuff like that, it makes it simple to do. On storage side of things, we also use RLS. So there the main logic is that we didn't want to come up with yet another permissioning system to define who can read objects from a bucket, who can upload objects to a bucket, and so on. So again, we use RLS here.

Since the metadata for storage is also stored in your own Postgres database, so your Postgres database will have a table called objects, which has the name of the object, the size of the object, when it's uploaded, by whom, and so on. Since this is just another table in Postgres, you can write RLS policies for it, and then we map these RLS policies to API level operations in storage. For an example, if you are able to read

particular row in the storage objects table, it means that you can read the actual object in storage as well. So if you want to download an object, we tell the user, hey, give this, if you want a user to download an object, give that user select permissions for that particular row in the

the storage objects table. The same thing with update and delete. If you want the user to delete an object, make sure he has the delete policy in RLS on the storage objects table. That's how we use RLS in SuperBase storage. Real-time is similar where the main place where it's used is we stream. Real-time, it started off with a way to stream database changes to your client. Obviously, you don't want

the client to listen to all database changes. Again, the changes are filtered down based on what RLS policies are enforced for that particular user. If the user cannot see a particular table based on RLS policies, those changes to those tables won't be filtered through to that user.

And with vector database, it's again, the main advantage here is that if you use super base vector, which is built on extension called PG vector, all your embeddings are just stored in your database itself and with the rest of your transactional data, right? So again, you can do training on a subset of embeddings. You can do training

You can link these PG vectors to other parts of your database. So it's still everything is just Postgres and you can write RLS policies as you would do with any other data type in Postgres. So that's how RLS integrates with our vector offering. So that's a way for us to make sure we give users a consistent

authorization experience regardless of which SuperBase product they use. And if you are able to write SQL and you crock RLS, it gives away for you to have consistent authorization policies across our entire set of products. Yeah, wow. That's a pretty holistic coverage.

I mean, are there any other security mechanisms or integrations that Superbase is understandably not going around to quite yet? Or are they on the roadmap or sort of being discussed internally? So there are a lot of things that we launched recently. So one of the things that we launched was

the ability to have MFA on your SuperBase dashboard itself. Previously, when you sign in via GitHub, the recommendation used to be, "Enable 2FA on GitHub itself," but some of our users wanted the additional peace of mind that, "I don't know if my users are using MFA on GitHub. I want MFA enforced on SuperBase as well." We launched that feature, we launched SSO,

If you want to switch a single sign-on, it gives an easy way for you to have a single source of truth on what the users are in your Superbase dashboard. So we have all these different things.

things that we have implemented recently we launched audit logs again it's very important to know what's happening in your dashboard who changed what setting at what time so all this information can be found through our audit logs and stuff that we are working on i think one of the things that we are working on and we could probably get help with some feedback from some

of our listeners as well is that we are revamping like our permissioning system. So right now you get a certain set of roles when,

You are in your super-based organization. You can assign someone as the admin, as the owner, as the developer, or you can give them a read-only role. But some of our users have been asking for more granular permissions, a way to restrict users in a few other ways. So we are still figuring out what's the right way to do permissioning on our system, which we are looking at.

And on the auth side, since we discussed about that, we are looking at, say, for example, WebAuthn, which is a new standard that's come up to do sign-ins on your websites and your mobile devices. So that's one thing that we are looking on the auth side.

Yeah, very interesting. Yeah, WebRFN, obviously a lot of WebRFN passkeys, depending on how people look at it. But yeah, a lot being talked about there. And we have a few episodes on SE Daily covering that coming up, or perhaps passed by this point. So, you know, Superbase, if we just switch gears a little bit, you know, from the absolute internal how Superbase works to

If we maybe move more to, you know, compliance and, you know, more and more, whether it's a startup or, you know, sort of beta plus companies are fairly aware that, you know, being SOC 2 compliant is just a huge help for them. So Superbase is SOC 2, type 2 compliant is my understanding. You know, what was the process like for your size of company then?

to get that and how does it affect say your daily work or maybe it doesn't you know staying on top of this kind of compliance

So yeah, the main reason why we decided to get it was like it was a requirement for some of our customers to be even to trial Superbase or prototype with Superbase. It was one of the requirements that our customers were telling us, hey, if you're not SOC 2 compliant, we won't be able to use Superbase within our organization. So that's when we started thinking about, okay, let's get this certification in Superbase itself.

And it's also generally easier to implement as much of this earlier on in the company when we have a fewer number of employees. And then it's easier once you're pretty small and your surface area is also smaller.

smaller. So each new, say workload or new employee that we add to the company, they sort of like, hey, this is how we do it at Superbase. And it's sort of easy to scale from there. So that's why we also decided, another reason why we decided to do it a bit earlier on as well. So yeah, you mentioned type one and type two that we are Superbase is type two compliant with

with SOC 2, which means that an external auditor has verified that Superbase is following all our security policies for over a period of time. So type 1 is just making sure at a single point in time we are compliant and for type 2, it's an auditor coming and saying, hey, these guys are following the practices not just on this particular day, but also over an extended period of time. And yeah, in

In terms of what's changed, I wouldn't say that much has changed. It did take quite a bit of effort initially to make sure that we have all our policies in order. You are going through SOC 2. It's not just a technical thing. It's also you need to work with your people team to make sure that people are onboarded and offboarded correctly according to what our policy says. It's a bit of a legal thing to make sure anything that we have in our policies is

is valid, is we are willing to stand by from a legal perspective on. It's obviously a lot of technical things also. On the technical side,

We strongly believed and we also did a decent job of is to make sure that we don't implement something just for checking a box for auditor. So we wanted to not have any security theater in that sense. And everything that we did is like,

actually improves the security of the platform and it's not to make an auditor happy. So this again involved making sure that we're in discussion with our auditors to make and explain why this other way of doing things might be okay and is consistent with our policies instead of like the way that they might have seen some other companies do it, right? So that's a thing that we strongly believe in and that's the reason why on an ongoing basis,

It feels like we aren't doing that much just to keep our SOC 2 compliance. It's just business as usual. And these are things that we would have done anyway to protect our users. And the other thing that helped with our SOC 2 compliance

compliance journey is a lot of these tools which help monitor your cloud environments, all the SaaS tools that we use. So we use a tool called Vanta to monitor our environments and they basically alert you when something is going to fall out of compliance. And yeah, on a day-to-day basis, we just have a Slack channel with these alerts streaming in and then we

we are able to remediate it within the SLA. So that's SOC 2, Type 2. Yeah, it's making sure that our users' data is protected as best as possible. The writing the policies is probably what took time and making sure that everyone in the company is also on board that, hey, this is how we do things. It's also a communication problem in that sense.

And it has impact on the technical teams I've talked before, even support, for example. How do you make sure that the support team is aware of all the policies on how we treat customer data? What's okay? What's not okay? So it is pretty wide reaching in terms of the number of teams that need to be involved. But yeah, it's pretty important to get done, especially as we talk to more enterprise users who see this as...

sort of like table stakes these days for you to have, especially if you are a database company. And, you know, maybe this doesn't sort of work or sort of make sense, but it, you know, if a company,

Superbase and they're going for SOC 2 compliance, is the fact that Superbase is type 2 compliant, does that take a big chunk of work away for that company or does it not quite work that way? It's part of it, right? So one of the things that we had to go through when we were doing SOC 2 is also making sure that most of the vendors that we were using were also SOC 2 compliant or we have to send them some sort of questionnaire to

to make sure that they are aligned with our own policies that we commit to our users and our auditor. So by Superbase being SOC 2 compliant, it doesn't automatically mean that you are SOC 2 compliant, but at least the parts that you are using Superbase for, again, I'm not a lawyer, you should probably talk to your own auditor and stuff to double check what I'm saying. But yeah, if you're using Superbase specifically

as one of your vendors, that part, you need to make sure that our SOC 2 report matches with your existing policies. So if you are on the Teams plan of Superbase, you can request our complete SOC 2 report, and where we have detailed all our existing security policies, what encryption methods we use, how often we rotate our keys, all that stuff is documented in that report. And

And then once you get the report from us, as you are going through your SOC 2 process, you need to make sure, hey, Superbase is doing this and I am committing this to my auditor and it both matches up. So I think Superbase is okay. And you need to do that for all the other vendors that you are using as well. So it's part of the story, but not the complete story for you becoming SOC 2 compliant.

I want to just call out one of the things I really like about Superbase is just, you know, outward facing website is the, on the footer, you've got lawyers.txt, security.txt, these, you know, things that people need to find about Superbase and you've just put them super easy to find. I think it's a really nice way of doing it. I recommend people check that out and maybe take

take a leaf out of Superbase's book for their own companies in that sense. And, you know, Superbase is also HIPAA or, you know, H-I-P-A compliant. And that's, you know, relating mainly to health data. So what sort of drove that? Because that's, is that sort of customers using it for that purpose and you had to react or more proactive thing?

Yet this one was more customers asking if they could build healthcare apps on top of Superbase.

And yeah, so HIPAA is a regulation in the United States on how we need to manage healthcare data. And before we got the certification, we couldn't recommend you use the hosted platform of Superbase to build these applications. We used to tell them that, okay, you can host this yourself, you can self-host Superbase and make sure your environment is HIPAA compliant, but our

and hosted environment till we get this auditor to verify us. It's not yet. And once we started getting more of these requests, then we decided, okay, we have already gone through the software type two one. Let's see what it takes to get HIPAA one.

And yeah, once she did the type two, there's not that many more additional things that we needed to do for HIPAA. I mean, there were some policies that need to be changed on the technical side. It's the incident management process, which had to be tweaked a bit. If healthcare data is breached and we have business associate agreement, which

which is, yeah, it's the agreement our users sign with us if they want to be HIPAA compliant. And if we have a PA agreement with our users, there is a certain set of extra things that we need to do to make sure that they are notified in what time period are they notified, are

are we giving them the right information to give them enough information to make sure that they know what data is breached, when it was breached. So we sort of do these things already with our existing users if we find out there has been a data breach, but this sort of makes it more strict in terms of the timeline that we need to do stuff by and the format and stuff like that. So that policy needed tweaking a bit once

once we became HIPAA compliant. And there are a few other things which we already did, like just making sure your workstation or your computer has proper screen lock. It has, HIPAA seems to mandate some very specific things like, yeah, so we had to make sure that we have the evidence to show that we are already doing that. And

And the other big thing like SOFT2, like for SOFT2, we need to make sure all your vendors are SOFT2 compliant. For HIPAA, again, it's the same thing. We need to make sure our vendors are willing to sign the business associate agreement with us. And so that's basically going to like the cloud providers like AWS and all the other services that we use that touch healthcare data and signing business associate agreements with each one of them.

So yeah, that's basically what we had to do for HIPAA. We also have like a shared responsibility model specifically for HIPAA. We spoke about the generic question of shared responsibility before in the episode, but yeah, for specifically for HIPAA, you need to make sure that your point in time recovery turned on. You need to make sure that your

Network restrictions are turned on, so your super-based project is not completely exposed to the internet. So we have a separate set of requirements that are required for HIPAA that our users need to do. But overall, it was much simpler to get this certification once we already had the SOC 2 Type 2 certification in place. Yeah, very interesting. And there's no shortage of...

health tech and health startups, even today being created. And, you know, I think it's, it's often something that's, you know, probably slightly overlooked, even by some of the players where they start, and they say, Oh, we'll get HIPAA, you know, once we're clearly successful, and, and then realize, oh, we're gonna go back and try and make that possible. And that's, that's quite,

complicated so you know just use super base when you start you're gonna have as you say it's a shared responsibility model so it doesn't suddenly take care of all your responsibilities by any means but it is certainly going to help you know if there's any potential future ctos or ceos of health startups listening maybe you want to give super base a look especially from that

perspective so just before we kind of wrap up and we've covered a lot in this episode it's been pretty amazing just like to hear you know what are maybe some of the exciting features coming to super base soon and can you speak a bit about what those might be

Yeah, so I mean, we just had our launch week now and the big thing there is Superbase is GA. So we have been in beta for some time now and we are officially in GA so you can use Superbase for a more wider set of applications. People have already been using Superbase in production for a long time, but this is officially us coming out of beta and saying that, hey, we feel that it's stable enough, reliant enough, secure enough.

for any kind of workload. So that's the big one that we announced in our launch week. And we have a few other announcements that you can check out on our website. We have a launch week page that you can see what we have announced on each day of the week. So we do these launch weeks once every three months or so where we announce one big thing every day of the week.

And yeah, the other big ones that we have announced is that we have read replica support in SuperBase now. So if you have your primary database in one particular region and you want to have a replica of the database in a different region, either to reduce latency or to scale out better, you can add replicas in any one of the 10 regions that we support.

The other interesting announcement I think is we are now managing all the Postgres databases launched via Fly.io. Fly.io, if you haven't heard of it, is a super cool way to launch applications across the world with just a simple Docker file. You just give them the Docker file and they take care of deploying it in all the regions that they have.

They have had this Postgres offering and Superbase is officially taking over or managing the Postgres databases that you launch through Fly. You get the exact same stack with Postgres, with all the extensions that you support. The cool thing is now that Postgres database is on Fly next to your other applications that you might have running on Fly as well.

Currently, Superbase databases are on AWS. So if you're on fly, you might find this interesting to have your database also on fly. And there are a lot more things that we have announced this week. Probably take another entire episode to just go through all of that. But yeah, check out our website for other announcements that we made during this launch week. Yeah, very exciting. And yeah, hopefully we can catch up.

again and talk about all those at some point as well so in the end this has been a just a great

time to speak to you and you know so much has been covered i think it's a pretty jam-packed episode in a good way and just so many it feels like super basis has covered so many things in what that's about three years now things that are they're difficult things and yeah really excited to have seen what's happened so i just want to thank you again for your time yeah this was fun thanks for having me