The Supabase team is releasing pricing today. This is our first launch of Launch Week[1]. Supabase is an open source Firebase alternative. We are building the features of Firebase using scalable, open source products [2].
If you don’t care for the details, here is the pricing [3]. The linked blog post goes into depth around our decision-making process.
The key takeaway is that we will stick with (what we feel is) a generous free tier. This was critical for many of our users who are still in the "build" phase of their project/business.
Another key takeaway is predictability. We've talked to too many devs who have been caught out by Firebase's usage billing.
Usually this is due to rogue API requests, which have a habit of spiking without any good debugging tools. To circumvent this, our usage pricing is centered around more "predictable" mechanisms (like storage), avoiding usage-billing on items like API requests.
Even on our free tier you're able to make millions of requests per day (we have developers doing this already!). In the future we will introduce "usage caps" on our top tier, which will allow you to specify maximum spends. Finally, we're starting with soft-tiers, so nobody will be "unexpectedly" upgraded.
We're a startup ourselves, so we want to build a sustainable business. Even though we are offering a free tier, we're confident in our ability to support it long-term with the enterprise features we are building (SSO, multi-cloud).
If you aren't confident in our business model though, we're open source. You can host it yourself[4]. Even better, everything we build is centered around Postgres, so you can pretty much `pgdump` your database and take it to your favourite Postgres platform.
We'd love to hear your feedback for the pricing. Also look out for a few more things we're releasing this week: Storage, a CLI, and some other Postgres-related items.
Thanks for the feedback. We chatted to a lot of devs to figure out the pricing, and the vast majority of them wanted predictability over anything else.
Bit late to the party, but if anything this pricing makes me nervous that you won't be sustainable as a business (ie; pricing is too low, leaves you vulnerable to a few customers costing you way more than they pay).
In particular, I'm nervous that you could get charged through the nose for bandwidth from people who make absurdly too many DB calls or have an insane number of simulconnected realtime channels.
I'd much rather see limits that seem to me "functionally unlimited" than the world "unlimited" which means to me "there is a limit but we won't tell you what it is". Maybe you just have sane rate limits documented somewhere else which would probably do the trick.
It's also slightly unclear what timeframe the billing is for these (I assume $0.125/GB/mo for storage, 200GB storage transfer limit per... day?)
Great project and looking forward to the mystery release at the end of the week.
I've been waiting really for one major feature request to be more comfortable with Supabase. It is SSL/TLS when connecting to the postgres database. I feel perhaps paying for something you're forced to use unsecured/plaintext connections is quite risky, especially with your core data and logins too! My 2c anyway..
I absolutely agree. Connecting via Postgrest happens already over SSL. But to secure direct connections to the database, this is critical.
We have the basic infrastructure for this in place already and will be rolling this out to all projects by the end of the next week :)
8 comments
[ 0.73 ms ] story [ 26.5 ms ] threadIf you don’t care for the details, here is the pricing [3]. The linked blog post goes into depth around our decision-making process.
The key takeaway is that we will stick with (what we feel is) a generous free tier. This was critical for many of our users who are still in the "build" phase of their project/business.
Another key takeaway is predictability. We've talked to too many devs who have been caught out by Firebase's usage billing. Usually this is due to rogue API requests, which have a habit of spiking without any good debugging tools. To circumvent this, our usage pricing is centered around more "predictable" mechanisms (like storage), avoiding usage-billing on items like API requests. Even on our free tier you're able to make millions of requests per day (we have developers doing this already!). In the future we will introduce "usage caps" on our top tier, which will allow you to specify maximum spends. Finally, we're starting with soft-tiers, so nobody will be "unexpectedly" upgraded.
We're a startup ourselves, so we want to build a sustainable business. Even though we are offering a free tier, we're confident in our ability to support it long-term with the enterprise features we are building (SSO, multi-cloud). If you aren't confident in our business model though, we're open source. You can host it yourself[4]. Even better, everything we build is centered around Postgres, so you can pretty much `pgdump` your database and take it to your favourite Postgres platform.
We'd love to hear your feedback for the pricing. Also look out for a few more things we're releasing this week: Storage, a CLI, and some other Postgres-related items.
[1] Launch week: https://supabase.io/new/blog/2021/03/25/launch-week
[2] Open source products: https://supabase.io/docs#how-it-works
[3] Pricing: https://supabase.io/pricing
[4] Docker: https://github.com/supabase/supabase/tree/master/docker
In particular, I'm nervous that you could get charged through the nose for bandwidth from people who make absurdly too many DB calls or have an insane number of simulconnected realtime channels.
I'd much rather see limits that seem to me "functionally unlimited" than the world "unlimited" which means to me "there is a limit but we won't tell you what it is". Maybe you just have sane rate limits documented somewhere else which would probably do the trick.
It's also slightly unclear what timeframe the billing is for these (I assume $0.125/GB/mo for storage, 200GB storage transfer limit per... day?)
I've been waiting really for one major feature request to be more comfortable with Supabase. It is SSL/TLS when connecting to the postgres database. I feel perhaps paying for something you're forced to use unsecured/plaintext connections is quite risky, especially with your core data and logins too! My 2c anyway..
SSL/TLS is coming - one of the team (inian) will drop some details here soon