Supabase, the open-source Firestore/Firebase Alternative

The Case For Better Self-hosting Supabase Support

Supabase is an open-source Firestore/Firebase alternative. It is currently offered as a SaaS service, but there are some good reasons to consider self-hosting it.

Supabase is a Firebase alternative. It builds upon Postgres by adding a REST api (Pgrest), a real-time addon (Supabase realtime), and an auth/user management system. One of Supabase’s key attractions is that the code is open-sourced under liberal licenses (Apache2). So, users know what is under the hood. In fact Supabase also provides a docker-compose file to run Supabase locally. I love the fact that Supabase (the company) uses open-source technology but doesn’t hoard its own additions behind restrictive licenses (unlike say, MongoDB or Elasticsearch)

Off course, docker-compose does not apply to production. The Supabase community has stepped up to create basic Kubernetes Helm charts (disclaimer: I have contributed to these Helm charts as well). But I would call these community Helm charts “starting points” rather than production-ready manifests to self-host Supabase at scale.

Supabase (the company) has no on-prem or self-hosted Supabase product offering or an officially-published self-hosted version. Their focus is solely on growing the SaaS product; they are going head-to-head with Firestore. But Supabase SaaS falls short for some customer needs. Lets list these use-cases to start a conversation around building a compelling case for developing self-hosted Supabase.

Supabase SaaS is only hosted on a select number of AWS data centers.

1. Flexibility and Control — Supabase is more than just a database. There is a real-time component, a storage component, routing and ingress, auth and a REST api. For any sizeable application, an architect would like to have granular per-component control over scaling, redundancy and disaster recovery, monitoring and alerts and SLAs. Self-hosting Supabase gives the system architect that sort of flexibility. I am not saying Supabase SaaS is not architected well, I am saying it can’t be a one-size-fits-all!
2. Latency — Supabase SaaS is hosted exclusively on AWS; users need to choose which AWS region to spin up their own Supabase instance. That is big limitaton, latency-wise, for what is essentially a relational database. For example, what if my customers are in Africa (where there is no Supabase option) or what if my application code runs on a different cloud provider? We are potentially adding 100s of milliseconds of latency per database call due to this limitation. On the other hand, self-hosted Supabase could be spun up in the same cloud/region/VPC as the application, shaving off latency by a lot.
3. Limited Postgres Environment Control — Every application is different; Larger Postgres databases and the infrastructure hosting them can be tuned very effectively to specific applications. A user does not have that flexibility with Supabase SaaS. On the other hand, a self-hosted Supabase installation will give system architects access to hardware and OS optimizations. For example, a self-hosted Postgres database infrastructure can be built to use disks appropriate for the read/write patterns of the application.
4. Missing Analytics Link — Currently there is very limited capability to sync Supabase SaaS Postgres data into a data-lake solution (e.g. Google Bigquery or AWS Redshift). Even if the Supabase SaaS solution offered scripts to do this synchronization, the cost and slow speed of frequently syncing a large database to an external analytics solution would be prohibitive. For example, you could download a Supabase SaaS Postgres backup over the Internet and then upload this data into the Analyics system today, but that approach is a non-starter for a large database (10s or 100s of GiB or more). A self-hosted Supabase solution will make it possible to house the Postgres database close to the analytics solution. In my opinion, this is the biggest advantage Google-hosted Firebase has over Supabase SaaS today. Google Firebase can sync its data with Bigquery over a high speed intra-datacenter network.
5. Security — This one is easy — many types of sensitive data simply cannot be hosted on SaaS databases; although Supabase (the company) highlights SoC2 for its Enterprise plan, there are many use-cases across industry (HIPAA, Fedramp, ISO 27001, GDPR etc.) where a SaaS database, especially hosted by a smaller company like Supabase, will be problematic for any user.

Missing: Self-Hosted Supabase

So, where are the self-hosted Supabase how-tos, infrastructure-as-code repositories to stand it up, discussions and forums to run it in a production-like environment, and most importantly, the willingness of Supabase (the company) to champion self-hosted Supabase?

Missing.

But why?

1. Does Supabase (the company) think there is no real market for self-hosted Supabase and therefore, its not worth the investment?
2. Is it simply too complicated to run self-hosted Supabase and support it across different users? Maybe large enterprise Supabase customers who need self-hosted Supabase don’t exist in large numbers.
3. Does self-hosted Supabase present a threat to Supabase SaaS, disuading Supabase (the company) from investing and supporting self-hosted Supabase?

I’d love to hear thoughts from readers on why self-hosted Supabase is so irrelevant to Supabase (the company) and to the larger Supabase community in general.

Quo Vadis? Where do we go from here?

In my opinion standing up and running self-hosted Supabase is challenging, but not outside the realm of possibility of a team with a couple of talented systems engineers. And for this same reason, I don’t think Supabase SaaS is in any way threatened by self-hosted — the cost of hiring those talented systems engineers is the protective moat around Supabase SaaS.

BUT, there is significant value being left on the table by not promoting self-hosted Supabase. Hopefully, community efforts like the Supabase Helm charts will mature further to make production-level self-hosted Supabase a reality. Lets also hope that Supabase (the company) supports self-hosted Supabase in every way possible so that some of the limitations of Supabase SaaS I wrote earlier can be addressed by self-hosted Supabase.

The big battle is with Firestore/Firebase here, not with self-hosted Supabase! And the ability to self-host is the one superpower Firestore/Firebase will never have.