Can the US Government Access Your Supabase Data?
What are the common security, privacy, and hosting issues when using this popular platform? This is the first post in a series that discusses hosted versus self-hosted.
At a high level, Supabase is an open-source backend platform built around PostgreSQL that provides the common building blocks needed for typical modern applications. These building blocks include database, authentication, APIs, realtime updates, storage, edge functions, and developer tooling. Supabase consists of two offerings: the hosted version known as Supabase Cloud which is the managed SaaS version, where Supabase operates the infrastructure for you, and an Open-source Supabase which is the self-hostable platform made up of Supabase’s core components, which teams can run on their own infrastructure for more control, customization, or compliance needs.
Supabase Cloud is the managed SaaS version, where Supabase operates the infrastructure for you. The key point of Supabase Cloud is that your backend is built around Postgres, while Supabase manages much of the infrastructure and operational work so teams can focus more on product development. You give up control of the management of that backend and how its hosted so you can achieve velocity of your product. Supabase cloud is hosted in AWS. More on that later.
Open-source Supabase does not have all the out-of-the-box bells and whistles that the hosted version provides. Of course you have to manage your own infrastructure and provide an authentication layer to its studio dashboard. Here you must configure and operate the surrounding pieces: SMTP/email delivery, OAuth providers, JWT secrets, callback URLs, security settings, user management, upgrades, monitoring, and production hardening.
But there is one thing that the self-hosted open-source version provides that Supabase cloud can never provide.
And that one thing is data sovereignty. Supabase Cloud offers speed and operational convenience. But for sensitive or regulated data, the provider’s jurisdiction may matter as much as the selected hosting region.
Think about that for a moment. Regardless of where your data, or your customers data resides in the world, if the company hosting it is a U.S. based company, then the U.S. government can gain access to it so long as the follow a “process”.
Okay. I know what you are thinking. There is a valid legal process that must be followed in order to compel these providers. But given that the US Department of Homeland Security (DHS) asked Google to provide personal information on a Canadian because they were critical of the Trump administration on social media [1] suggests that the process is not as robust as it should be.
The challenge to that “process” is that we have seen the American judicial system weaponized for political ends and subverted to attack political enemies. Therefore, how is it possible to ensure that your data, or your customers data, is safe from any political whim and a process that is not fit for purpose.
There are three concepts to consider when designing your data storage:
Data location: the physical or logical region where data is stored.
Data residency: a requirement or commitment to keep data within a particular geography.
Data sovereignty: the laws and authorities governing the organisations that possess or control the data.
For some systems, managed Supabase is entirely appropriate. For higher-risk datasets, self-hosting may provide an important additional layer of organisational and jurisdictional control but only when the surrounding infrastructure is designed accordingly.
When assessing a cloud platform, does your threat model consider the provider’s jurisdiction or only the location of its data centre? Yes, self-hosted open-source Supabase is more work. But you will need to balance that work with the risk profile of the data you maintain.
And to be fair, this also applies to any managed database in an American cloud provider’s infrastructure.
