EPISODE 1614

[INTRODUCTION]

[0:00:01] ANNOUNCER: 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 PostgreSQL, 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.

Inian Parameshwaran 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.

[INTERVIEW]

[0:01:32] GV: Hi, Inian. Welcome to Software Engineering Daily.

[0:01:35] IP: Hey, Gregor. Thanks for having me. It's good to be here.

[0:01:39] GV: Inian, we've had Supabase 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. This is running such a data-critical platform that is Supabase. Maybe to help our listeners, maybe you could give a quick recap of what is Supabase and also, how did you get involved and what was your road to joining Supabase?

[0:02:11] IP: Yeah, sure. Since 2020, okay, that's a long time to give a recap on, but I'll try my best here. Okay, Supabase is the open-source Firebase alternative. We built the primitives that Firebase offers, but using an open-source stack. The main difference with Firebase also is that we use a relational database, like PostgreSQL. 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 PostgreSQL. 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 our globally distributed servers. More recently, we have added vector database offering based on PG vector.

That's all the high-level products that Supabase offers. The general idea is that we want to make it as easy as possible for application developers to get started with their application. We prioritize the developer experience as much as possible, similar to what Firebase does. Firebase, it’s super easy to get started. We want the same thing for Supabase, where you can get started.

In fact, our tagline is ‘build in a week and scale to millions.’ We want the initial experience to be as simple as possible. 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. That's Supabase. I've been with Supabase for a little more than three years now. Yeah. When I joined the company, they were an alpha back then, and they were looking for someone to help with some of their infrastructure problems, because they were trying to go to beta.

I remember, they had this checklist of things to work through before they were comfortable calling themselves beta. I joined the company and started working through that checklist to make sure that we could launch Supabase beta. That was in December 2020, I think. Yeah.

Started off with a lot more of the infra site first. Over time, once we had the infrastructure set up, once we had the database and the real-time engine set up. 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.

The next biggest thing that users were asking for is storage. I helped launch the initial version of Supabase storage. After that, I also helped launch the initial version of functions, which is the next thing that people were asking for. For Supabase, most of the Supabase components can be directly used from the client side itself. That's how our security model is also designed. If you design your application correctly, you can call your Supabase APIs directly from your website, or your mobile application. But there are still some aspects where you need to have 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. That's where functions come in.

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. 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. My job is essentially, to make sure that you 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. Yeah, so that's how my role has changed at Supabase itself.

Before that, I ran my own startup called Dexecure. Again, it is in the dev tools space as well. I like dev tools in general. Yeah, we are building tools to make websites go faster. Before that, I did another project, our startup, which didn't really work out in the security lab of my university in Singapore. Yeah, that's being my background. Most, I like dev tools, security, performance. Yeah. Here I am.

[0:06:48] GV: Yeah, very cool. I remember when we met. We met in Singapore, where we're both located at the moment. Dexecure, your last startup still has quite a falling, at least in the city, I believe, which is very cool.

Okay, so what would you say, we've heard now a bit about how the products evolved over the last three years. Obviously, security has played a major role in that, given scaling to the user base that you have now. What would you say was the first major security hurdle that Supabase had to overcome when growing from an early stage startup to a product that's used in production?

[0:07:25] IP: Yeah. I mean, security is very, very critical to us, because we host user data in our databases. Customers trust us with their own data as well. It's one of the top priorities to make sure that we are as secure as a platform can be. There wasn't 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. I can probably give you a couple of stories from the early days, which made us rethink some of the practices that we're doing back then.

I remember when I first joined the company, right within the first week or so, a customer who was using Supabase 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.” We ended up investigating his database to see what the issue was. Then we found his CPU was at 100% for the last 20 minutes or so. Because of that, his queries weren't running as fast. 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, three years ago.

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. It turns out, how the attacker had gotten is because this user had his PostgreSQL password set to something super simple, like monkey123, or something like that. Because of that, they could just get into the front door, say, “Hey, this is your IP. I see a PostgreSQL database running there.”

The immediate fix that we were able to do is to make sure that users use strong passwords before for any Supabase database. Right now, you can't launch a Supabase database with a weak password like that. 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. We automatically block IPs, which have been trying to guess passwords and they get it wrong after a certain threshold.

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. Those are the fixes that we have done over the time. 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 PostgreSQL database. That was one interesting story.

Even there, one of the other components that the attacker needed to get the Bitcoin miner was the ability to execute arbitrary code. Turns out, that PostgreSQL is pretty powerful. That is the copy command PostgreSQL, 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 this program attribute where you can pipe the standard output of a program also into the copy command. That pretty much lets you execute arbitrary programs.

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 super utils. 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 Supabase database.

The other reason why we went down this road is to make sure that we don't fault PostgreSQL itself. Looks like some cloud providers actually fault PostgreSQL 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 PostgreSQL where possible. Since PostgreSQL is so flexible that you get all hooks into the different lifecycle events in PostgreSQL, we were able to fix this security hold with just an extension.

Yeah, that's the various changes that we had to do just coming from this one issue that we observed when the company launched. 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. Yeah. Since most of our workload is on AWS, it's just making sure that our AWS security config is as bulletproof as possible.

Again, this is one of the systems that I've put pretty early on was to analyze the audit logs inside AWS to figure out if something fishy was going on. I remember, so AWS has this product called CloudTrail, which is audit logs for your AWS environment. You can pass the audit logs to figure out, yeah, something here is going on. We had alerts set up in Slack to when one of these conditions gets triggered. What ended up happening one day was that we got an alert that someone logged in without two-factor authentication into our AWS account. That started bringing alarm bells everywhere for me. I was like, “Hey, who's logging in without two-FA? I thought we enforced two-FA across everyone in AWS.”

Then it turned out that someone was logging in to AWS from their Africa region. At one point in time, I think this was a pretty long time ago, if you log into AWS console from the Africa region, they didn't validate your two-FA at all. Even if you have two-FA configured, turns out, they didn't validate and then we ended up raising ticket to the security team. Of course, now it's been patched. Again, that was another interesting incident that happened pretty early on, where, yeah, it's like, we are responsible for our own infra, but also, all our vendors’ infras. 

Yeah, we have a lot of interesting incidents like these, which makes it critical internally to show why security is important. Also, yeah, we have implemented a lot of these features over time to improve the security of the platform.

[0:14:12] GV: Yeah, that was 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 the Supabase to sit in this middle part and actually, you've got users potentially doing – 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 third-party risks, like AWS, and you could never have predicted the Africa region piece at the time. Just bouncing back briefly to super utils, to me that almost sounded like, almost an ORM for database management, in a sense, or is that how to describe it, or how would you turn that?

[0:14:56] IP: It's not exactly an ORM. It's more that the – usually, PostgreSQL is like the super user inside your PostgreSQL cluster, and you can do whatever is possible within PostgreSQL as the PostgreSQL user. Over time, we realized that we can't give a super user access directly to our clients, because we are running multiple PostgreSQL databases of our customers in our environment. As the PostgreSQL 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 before I joined the company that you can actually read files as from SQL. Sounds crazy, but yeah. What super utils does is that it lets you do certain operations without being the super user yourself. Over time, what we have done is that initially, when Supabase started, PostgreSQL was a super user. Since then, we have created a separate user called PostgreSQL, but it's not the super user, but we still want users to do certain actions that a super user can. That's where super utils comes in.

It's not like an ORM, but it's a PostgreSQL extension, which analyzes the queries that are being found, and decides to run certain queries as the super user, if it's okay from a security model. Also, the copy command before, yeah, it allows copy commands, but only if the input is a file. It doesn't allow if the input is a program. It's like a firewall, if you want to make a vague analogy to it. It's built as a PostgreSQL extension, it's open source, and it's running on all your Supabase databases.

[0:16:47] GV: Got it. That makes a lot of sense. If I'm a user thinking about Supabase, is it fair for me to say, oh, if I deploy my PostgreSQL on top of Supabase, I don't need to worry about security as much?

[0:16:59] IP: There are some aspects of security that are taken care by Supabase, and there are some which is on you as the application developer. We actually have a document called the shared responsibility model on our docs, which essentially says, what are you responsible for and what is Supabase responsible for.

On Supabase, we promise to take care of 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 data protection on your all your different APIs. We make sure that we have stuff, like fail to ban, network restrictions, SSL enforcement. We give you all these different things. Some of it is enabled by default. For example, all Supabase projects come with a certain level of data protection. If you're on the enterprise plan and stuff, we give you a higher level of data protection. You set your defaults where possible. Again, we guarantee that your PostgreSQL database is completely isolated from other PostgreSQL databases that are running on our infra.

These are some things that we take care on our site, but there are also stuff that you need to take care 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 two-FA on your account. When you're developing, it's just a hobby project. Probably, you don't care if Supabase has two-FA, 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 user’s data and you want to make sure that it has two-FA enabled, it has SSL enforcement enabled, it has network restrictions enabled, all these different things, right? That responsibility lies on you.

Also, the security model of Supabase depends on RLS quite a lot, which is role level security. There, also, we give you the option to enable role level security for all your tables. Again, it's on you to make sure that it's enabled on all the tables that you create. You write the proper policies, which authorized users based on what kind of user they are. I could go on, but that gives the rough distinction between what Supabase 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 PostgreSQL is properly protected, either through RLS, or some other mechanism. You use some of the other security tools that we give you network restrictions, and so on.

[0:19:50] GV: Yeah. It's like anything in security, where it's only as good as the person who's actually implementing. You as the provider, Supabase, 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 is, in this case, the developer, to still take advantage of that and not ignore things.

Given Supabase is entirely based around PostgreSQL, what considerations, especially from a security and a data integrity standpoint, would you say were key to choosing that PostgreSQL over any other relational underpinnings, or even say, MongoDB?

[0:20:31] IP: Yeah. The decision to use PostgreSQL was partly because our founder, Copple, he was using PostgreSQL in his previous company and he needed some real-time capabilities on top of PostgreSQL, which is how we built real-time engine. That's Supabase started from that. It might just be why PostgreSQL at that point is just coincidence, I guess. Over time, PostgreSQL, we have doubled down on PostgreSQL since then, mainly because yeah, it's battle tested. It's been used at scale by multiple companies. It's been around since the 1980s, right? It's gone through multiple iterations, and the PostgreSQL community itself places a huge focus on making sure the database is as durable as possible.

You get all the other benefits of a transactional relational database as well, like 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 PostgreSQL gives you. That's probably the durability and the focus on data integrity components, which has made us double down on PostgreSQL. We also like PostgreSQL because of the flexibility. The extension ecosystem of PostgreSQL is incredibly vast. You can do very fancy stuff, like PostGIS is one of the most popular extensions in PostgreSQL, and you can do a lot of interesting things with that.

You can build a time series data, a database like Timescale has done on the PostgreSQL. Yeah, I’m just constantly amazed by the different kinds of things that you can do with just an extension in PostgreSQL. That was another part of it, which we felt that gave us the right hooks into PostgreSQL as we wanted to build more things with PostgreSQL itself. That's the other aspect on why we chose PostgreSQL.

On the security side of things, yeah, PostgreSQL has a very granular and flexible permission model. You can say, this user must be able to read the tables in this schema, but not in the schema, but we can read this table, but not update it, can call this function, but not updated. Yeah, you can go ask granular as you want, which is pretty nice. It also has this concept of pro level security, which we use pretty much everywhere in Supabase across all our other products as well. It gives you the right primitives to build a very secure, robust application on top.

[0:23:11] GV: 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 PostgreSQL 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 Supabase is in any way similar to what Atlas is maybe doing for their own product? Is that an analogy that we can use at all?

[0:23:41] IP: Yeah. I would say, part of it. Yeah. For example, with Atlas and with Supabase, you don't need to think about the operational aspects of running PostgreSQL on MongoDB. You don't need to think about, hey, there is a new version of PostgreSQL out. How do I make sure I upgrade to the latest version? Do I know if all the extensions I run are compatible with the latest version? We just make it a one click upgrade. 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 was wrong, Atlas and Supabase 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 Supabase, also, we support more than 10 different regions right now and we are adding more cloud providers in the upcoming year. I would say, there are similarities in that sense between Atlas and Supabase. At Supabase, we also give you – it's not just a database. PostgreSQL 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. Yeah, in that sense, Supabase is not just a database. It's probably a backend as a service, if you want to call it that. Yeah.

[0:25:22] GV: Very interesting. Then not really a topic for today, but the vector database side, that's clearly very interesting, given where things are headed from a AI perspective. Let's talk about a major feature of Supabase, which is the off piece. That's covering in a sense, both authentication and authorization. How is Supabase handling these for both your customers and their users? What is Supabase adding over and above PostgreSQL vanilla in this regard?

[0:25:57] IP: Supabase is, our odd server is based on the project called GoTrue. Initially, let's say, if I had this project called GoTrue, and we based our odd servers on that. The main reasons why we chose it was that we need something super simple to get started with for our users. Netlify, 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 PostgreSQL database pretty easily. I think that was one change we had to do.

Initially it was meant to be used with MySQL, I think. We have since changed it so that our odd server is able to use PostgreSQL. The reason why we need PostgreSQL here is that our odd server is able to store all the metadata about your users right in your own PostgreSQL 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, where you do select star from odd users and you match the email and you match the created at column. There you have it.

You don't need to think about, “Hey, how do I call Supabase’s auth API and how do I filter and start?” It's just SQL, right? If you know SQL, you can do all these cool things really easily. Because the metadata is also inside PostgreSQL, you can link your user’s ID to other items in your schema. For example, you want to associate a particular user’s ID with a file that they own, or some other entity in your database, you make it super simple, because it's again, right there in your database. That's GoTrue.

We have since voted 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 we integrated with more than 20 different social logins. This is 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. Yeah, that's on the authentication side. More recently, we also added single sign on with your org. That makes it more viable for the enterprise use cases.

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

[0:29:01] GV: Yeah. We have heard about role level security, RLS, a couple of times so far in the episode. Maybe, could you just describe that to someone who's maybe just unfamiliar with that concept in general? Is it unique to PostgreSQL, or do we find that in other places?

[0:29:20] IP: Okay, yeah. Role level security is, I don't know if it's unique to PostgreSQL. I think, probably, SQL Server has it. But essentially, what it does is that it lets you write your policies in SQL. It's a way to do authorization at the database level itself. As a user, you can write a role level security policy and this policy gets evaluated on each row of the database before the results are returned to the user. I think this is easier if I use an example to explain what RLS is.

Imagine if you have a table called users and the primary column is ID. 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? You can write an RLS policy which gives the user permission to read and update only his own user ID record. Even if in your application code do something like, select start from users, but 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 a 100 users and ask the user if you do select start with no limit, clause or anything, you still just see that one record.

That's the database enforcing permissions at the database level itself. You on the application level don't need to say, select start from users where user ID equal to the user's ID like that. Where clause, you can ignore if you have RLS enabled. That's a way for you to push the authorization logic right into the database. The other advantage of that is that it doesn't matter which client is wearing 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 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 way.

Since it's all happening within PostgreSQL, also it can be optimized extremely well and it runs very fast, instead of having the application being done outside the database, say in your application layer, or something like that. That's 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.

[0:32:06] GV: Yeah. 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. At the end of the day, it's still a fairly complex thing to actually implement properly. I think that's clearly somewhere where Supabase comes in and just takes a whole ton of time away. Which parts of Supabase is that concept implemented in?

[0:32:29] IP: Yeah. RLS can be a bit difficult to grok when you first come in and we are trying our best to make sure that's as easy as possible. For example, in our dashboard, we have this Supabase AI integrated into the SQL editor, where you can ask it to generate different queries. 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. With the help of AI, we can make sure that 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.

Yeah. That's RLS policy. How it's used within Supbase mentioned before, like for Supabase auth, once you sign in, using Supabase auth, you get JWT token with the role of the user and the ID of the user. 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. Stuff like that, it makes it simple to do.

On storage side of things, we also use RLS. 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. Again, we use RLS here, since the metadata for storage is also stored in your own PostgreSQL database. Your PostgreSQL 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 PostgreSQL, 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 a particular row in the storage object stable, it means that you can read the actual object in storage as well. 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 and the storage object stable.” 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 object stable. That's how we use RLS in Supabase storage.

Real-time is similar where the main place where it's used is we – real-time, it started off with a way to stream database changes to your client and 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.

With vector database, it's again, the main advantage here is that if you use Supabase 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? 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. It's still everything is just PostgreSQL and you can write RLS policies as you would do with any other data type in PostgreSQL. That's how RLS integrates with our vector offering.

That's a way for us to make sure we give users a consistent authorization experience, regardless of which Supabase product they use. If you are able to write SQL and you clock RLS, it gives a way for you to have consistent authorization policies across our entire set of products.

[0:36:57] GV: Yeah. Wow, that's a pretty holistic coverage. I mean, are there any other security mechanisms, or integrations that Supabase is understandably not going around to quite yet? Or are they on the road map, or sort of being discussed internally?

[0:37:16] IP: There are a lot of things that we launched recently. One of the things that we launched was the ability to have MFA on your dashboard, Supabase dashboard itself. Previously, when you sign in via GitHub, the recommendation used to be, okay, enable two-FA 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 Supabase as well, so we launched that feature. We launched SSO, if you want to, which is single sign on. It gives an easy way for you to have a single source of truth on what the users are in your Supabase dashboard.

We have all these different 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. All this information can be found through our audit logs. 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 our permissioning system.

Right now, you get a certain set of roles. When you are in your Supabase organization, you can assign someone as the admin, as the owner, as the developer, or you can give them a read-only tool. Some of our users have been asking for more granular permissions, a way to restrict users in a few other ways. You're still figuring out what's the right way to do permissioning on our system, which we are looking at.

On the odd 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. That's one thing that we are looking on the odd side.

[0:39:15] GV: Yeah, very interesting. Yeah, WebAuthn, obviously a lot of WebAuthn pass keys, depending on how people look at it. 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. Supabase, if we just switch gears a little bit from this of the absolute internal how a Supabase works, if we maybe move more to compliance and more and more, whether it's a startup, or beta plus companies are fairly aware that being SOC 2 compliant is just a huge help for them.

Supabase is SOC 2, type two compliant is my understanding. What was the process like for your size of company to get that and how does it affect, say, your daily work, or maybe it doesn't stay on top of this compliance?

[0:40:10] IP: Yeah. The main reason why we decided to get it was it was a requirement for some of our customers to be even to trial Supabase on prototype with Supabase. 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 Supabase within our organization.” That's when we started thinking about, okay, let's get this certification in Supabase itself.

It's also generally easier to implement as much of this earlier on in the company when we have a fewer number of employees. Then it's easier once you are pretty small and your surface area is also smaller. 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 Supabase,” and it's easy to scale from there. That's why we also decide – another reason why we decided to do it a bit earlier on as well.

Yeah, you mentioned type one and type two, that yeah, Supabase is type two compliant with SOC 2, which means that an auditor, external auditor has verified that Supabase is following all our security policies for over a period of time. Type one is just making sure at a single point in time, we are compliant. For type two, 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.”

Yeah. 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 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 our auditor. We wanted to not have any security theater in that sense. Everything that we did is actually improves the security of the platform and it's not to make an auditor happy. 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 the way that they might have seen some other companies do it.

That's a thing that we strongly believe in. That's the reason why an ongoing basis, it seems like we are doing that much just to keep us up to compliance. It's just business as usual. These are things that we would have done anyway to protect our users. The other thing that helped with us up to compliance journey is a lot of these tools which help monitor your cloud environments, all the SaaS tools that we use. We use a tool called vantar to monitor our environments. They basically alert you when something is going to fall out of compliance.

Yeah, on a day-to-day basis, we just have a Slack channel with these alert streaming. Then we are able to remediate it within the SLA. 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 onboard, that this is how we do things. It's also a communication problem in that sense. It has impact on the technical teams have talked before, even support, for example, like, 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?

It is pretty wide reaching in terms of the number of teams that need to be involved. Yeah, it's pretty important to get done, especially as we talk to more enterprise users who see this as table stakes these days for you to have, especially if you are a database company.

[0:44:48] GV: Maybe this doesn't work, or make sense, but it if a company uses Supabase and they're going for SOC 2 compliance, is the fact that Supabase is type 2 compliant, does that take a big chunk of work away for that company, or it does not quite work that way?

[0:45:07] IP: It's part of it, right? 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 questionnaire to make sure that they are aligned with our own policies, that we commit to our users and our auditor. By Supabase being SOC 2 compliant, it doesn't automatically mean that you're SOC 2 compliant. But at least the parts that you are using Supabase for.

Again, I'm not a lawyer. You should probably talk to your own auditor and stuff to double check what I'm saying. Yeah, if you're using Supabase as one of your vendors, that part, you need to make sure that our SOC 2 report matches with your existing policies. If you are on the teams plan on Supabase, 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.

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

[0:46:37] GV: I want to just call out one of the things I really like about Supabase is just outward facing website is there on the footer, you've got lawyers.txt, security.txt, these things that people need to find about Supabase 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 a leaf out of Supabase's book for their own companies in that sense. Supabase is also HIPAA, or HIPAA compliant. That's relating mainly to health data. What drove that? Is that customers using it for that purpose and you had to react, or more a proactive thing?

[0:47:22] IP: Yeah. This one was more customers asking if they could build healthcare apps on top of Supabase. Yeah, so HIPAA is regulation in the United States on how we need to manage healthcare data. Before we got the certification, we couldn't recommend you use the hosted platform of Supabase to build these applications. We used to tell them that, okay, you can post this yourself. You can sell for Supabase, and make sure your environment is super compliant. But our hosted environment till we get this auditor to verify us, it's not yet.

Once we started getting more of these requests, then we decided, okay, we have already gone through the software type 2 one. Let's see what it takes to get HIPAA one. Yeah. Once you did the type 2, 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 instant management process, which had to be tweaked a bit. If healthcare data is breached and we have business associate agreement, which is, yeah, it's the agreement our users sign with us if they want to be HIPAA compliant.

If we have a PAA agreement with our users, there is a certain set of extra things that we need to do to make sure that they are notified and what time period are they notified, 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. We do these things already with our existing users, if we find out there has been a data breach, but this makes it more strict in terms of the timeline that we need to do stuff by and the format and stuff like that. That policy needed tweaking a bit once we became HIPAA compliant.

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 perceived to mandate some very specific things. Also, we had to make sure that we have the evidence to show that we are already doing that. The other big thing, like SOC 2, for SOC 2, you need to make sure all your vendors are SOC 2 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.

That's basically going to, like the cloud providers, AWS and all the other services that we use that touch healthcare data and signing business associate agreements with each one of them. Yeah, that's basically what we had to do for HIPAA. We also have a shared responsibility model specifically for HIPAA. We spoke about the generic question of shared responsibility before in the episode. Yeah, 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 Supabase project is not completely exposed to the Internet.

That we have a separate set of requirements that are required for HIPAA that our users need to do. Overall, it was much simpler to get this certification once we already had the SOC 2, type 2 certification in place.

[0:50:54] GV: Yeah, very interesting. There's no shortage of health tech and health startups even today being created. I think, it's often something that's probably slightly overlooked even by some of the players where they start. They say, “Oh, we'll get HIPAA once we're clearly successful.” Then realize, “Oh, we've got to go back and try and make that possible.” That's quite complicated. Just use Supabase when you start. As you say, it's a shared responsibility model, so it doesn't suddenly take care of all your responsibilities by any means. It is certainly going to help if there's any potential future CTOs, or CEOs of health startups listening. Maybe you want to give Supabase a look, especially from that perspective.

Just before we wrap up, I mean, we've covered a lot in this episode. It's been pretty amazing. Just like to hear, what are maybe some of the exciting features coming to Supabase soon, and can you speak a bit about what those might be?

[0:51:59] IP: Yeah. I mean, we just had our launch week now. The big thing there is Supabase is GA. We have been in beta for some time now, and we are officially in GA. You can use Supabase for a more wider set of applications. People have already been using Supabase 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 workload. That's the big one that we announced in our launch week.

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. We do these launch weeks once every three months or so, where we announce one big thing every day of the week.

Yeah, the other big ones that we have announced is that we have read technical support in Supabase now. 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 PostgreSQL databases launched via Fly.io. Fly.io, if you haven't heard of it, it's 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 PostgreSQL offering and Supabase is officially taking over, or managing the PostgreSQL databases that you launched through Fly. You get the exact same stack with PostgreSQL, with all the extensions that we support. The cool thing is now that PostgreSQL database is on Fly next to your other applications that you might have running on Fly as well.

Currently, Supabase databases are AWS. If you're on Fly, you might find us interesting to have your database also on Fly. There are a lot more things that we have announced this week. Probably, take another entire episode to just go through all of that. Yeah, check out our website for other announcements that we made during this launch week.

[0:54:29] GV: Yeah, very exciting and yeah, hopefully, we can catch up again and talk about all those at some point as well. Inian, this has been just a great time to speak to you, and 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, Supabase has just covered so many things in what that's about? Three years now, things that are difficult things. Yeah, really excited to see what's happened. I just want to thank you again for your time.

[0:54:59] IP: Yeah, this was fun. Thanks for having me, Gregor.

[END]