- Now, the connection between our API servers and the database was slow (a few hundred ms per query), so we moved to self-hosting Postgres which was pretty painful. We tried to use https://github.com/supabase/postgres, but the documentation was very lacking and we had to make a bunch of modifications to get it to work. After we got it working, it was pretty smooth though - pretty easy to implement backups, etc.
- Our latest issue has been around auth where the cookie name options change. We've spent hours debugging random cookie issues deep in the auth framework (they finally released `@supabase/ssr` which is pretty decent, but we're still thinking about moving to handling auth on our side so we know and can debug the logic).
One thing to mention: although our requirements didn't quite fit Supabase and we ran into these issues, we weren't locked into their hosting. We were able to completely move off of it over the course of a few weeks, but continue using the self-hosted version. This is a huge benefit over something like Firebase or Amplify. We're pretty satisfied with Supabase as an open source project, but not as satisfied with Supabase hosting.
I struggle to imagine projects that can do with a db latency of several hundred ms? Something fully async maybe, any human interaction would be incredibly slow
we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0])
we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in our journey, one of the best sources of product feedback [2]
the GA badge is mostly to signify organizational readiness. we're at a stage where we can take any profile of customer. we have a support team that works 24/7, and a success team that will help customers improve their postgres usage. we released our Index Advisor [3] yesterday, and we'll be releasing a few more products this week that helps customer with performance and security.
on a personal note: i read HN most days, and love going through the ShowHN's to see what devs are building. thanks for being an awesome community and my favorite place to lurk on the internet. i'll stick around to answer any questions
at the start, the "firebase alternative" positioning made it unclear to developers who thought we offered a NoSQL database. We always wanted to be "Postgres plus useful tools" so we started evolving the positioning over the past year
you'll still see "firebase alternative" on our site: I think the comparison is apt and the aspiration remains the same
My feedback on Supabase: I would like to see a separate PGS offering instead of it being bundled with your other services. I already pay Vercel for hosting and functions, so the problem is already solved there. I can't move my hosting and functions because of the first-class support for Next.js by Vercel (vendor lock-in is strong here).
I use Firebase for authentication, which is free for unlimited MAU.
The only thing I'm looking for is PGS. I know the current cost is not much even if your other services are bundled together, but that may not be the case in the future. A separate PGS offering makes more sense for users like me.
capital letters are atypical in many internet circles, particularly younger. so maybe it's a habit from frequenting those circles or a deliberate branding choice
I’ve just started dabbling so take this with a grain of salt.
Overall, it’s great. I recommend it to people. The high signal part is what I would work on:
- deeper integrations with common OpenID Connect providers, with a pretty foolproof “bail to browser view that looks like Kinde or Clerk”. there’s only so much you can do, but it’s not trivial to get wired up to a bunch of pick-and choose SSOs.
- prisma should be front and center, the auth/public schema split is not a breeze, Prisma slays at being an ORM, Supabase slays at other things. It’s not obvious whether or not to use realtime or Pulse.
- force the env footprint on e.g. next or expo or whatever, it’s a little glue, it’s a lot of people who don’t pop out of the funnel.
- chat / dm is a common enough use case to be in the wizard (like avatars), Postgres handles it fine for small to medium apps, and arguably for big ones
- have a pass through mode for the local deploy that’s easy to toggle, you guys are fast AF, it’s often sane to dev directly against the instance.
- I’m sure you’re already building the kind of anonymized training sets that let you spot bad configs a mile away.
Again, nitpicks on a great product. I love Supabase.
Congrats Supabase folks! I wish you every success.
I paid $20/mo for a while because of the free tier storage cutoff (500 MB), but have since stopped. I wish you had a $5/mo tier for "small projects" folks who need a database larger than that.
For example, Cloudflare's Workers Paid is $5 for D1 databases up to 10GB, with 5GB included and 75¢GB after. I know this is comparing apples and oranges to some degree and that your business model may be incompatible with this use case, which is absolutely fair.
I built a toy app using this, with a front-end only app and postgrest + RBS. The app was seriously two forms behind a login. It was a huge pain.
RBS is "insecure by default" meaning if you don't set it up right, all users can access all data. And, because it's SQL, it's really easy to write a valid and successful configuration that doesn't work. You have to test it. And for views, you have to do some real heroics to get them to respect RBS.
PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.
Yes, I know that I could make a direct SQL connection to the database, but at that point, it would've been easier to put a Rails app on Heroku and use their offering, which is far more mature.
The Supabase dev environment was pretty slick and worked well, though I had to docker implode a couple times.
I wish them luck, but I could not figure out what the use case was for their product, given that Heroku has an awesome managed Postgres and RDS is there if you have more knowledge and want more controls. I don't see how you could make a complex app that is front-end only with Supabase as your entire back-end.
A few things, RLS is secure by default, it's postgrest that's insecure by default.
RLS disables all operations on a table once enabled and is only operable once there's a passing policy unless you can bypass RLS.
When it comes to access control, you should probably always have tests for anything halfway important.
Views are a bit of a footgun when it comes to RLS, they bypass it by default. But getting them to play nice is as simple as defining "security invoker" in their definition; not what I'd call heroics.
> A few things, RLS is secure by default, it's postgrest that's insecure by default.
What makes you think that? PostgREST delegates all the authorization to PostgreSQL, which is secure by default. You have to explicitly assign privileges to roles for every operation.
> PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.
The PostgREST query grammar is basic on purpose, you're supposed to write SQL on views or functions[1] to extend its capabilities.
This isn't fair feedback. You have to be more specific about the "lock in". Supabase itself is just managed Postgres and can be self-hosted. The entire point is that everything they offer is open source and easily found elsewhere.
I can imagine they fall short in some aspects from that ideal and I would love to know your experience but even with your first sentence this is just a pretty damning write off.
Disclaimer: I'm NOT a Supabase employee, just a happy user.
If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers.
If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers out there, which confirms the pain the parent comment is describing.
We're using Supabase for a client project and even three sprints in, we're severely hobbled by having to play with a couple of architectural choices forced on us with Supabase and Supabase Auth. Any of the time savings benefits have been wiped out already just fighting the choices and also the subtle differences between the local dev environment, implementing RLS without good tooling.
On an architectural level, it is also terrifying to have your database exposed to the public internet just hidden behind authentication and RLS policies (which are much harder to reason about for most developers, and for which there is very immature tooling, a recipe for disaster).
Plus the local dev experience leaves a lot to be desired. We spent days trying to get file uploads working only to find that the issue was with local Supabase, and we had to create a remote Supabase database just to upload files successfully. But then we can't "reset" the database to run migrations.
The product is definitely much less smooth to develop on and I've had to provide dozens of hours of free client consulting work to untangle my recommendation of Supabase (didn't feel right to charge them to fix a product choice that I recommended to them).
Right now I'm in a strong "never again" view on this set of technologies. At least not for a long time until the tooling improves.
But it seems like there are some happy customers. So would love to hear a counterpoint of how they overcame all the issues we've faced:
- how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.
- Reliance on RLS for a public service seems risky because RLS quickly gets harder to maintain as you have to get more complex policies in place without much tooling to help you.
- how about the fact that some of your most important code, the RLS policies code, is hard to unit test with today's tooling? And they recommend pgTAP, which, who knows how big this community is?
That combination seems highly risky to me.
Our best bet right now has been to just install prisma and implement more traditional filtering on top of RLS, and just not rely at all on client side connections to postgres. So in a nutshell, moving away from Supabase specific architecture to more traditional architecture. The real "It's just postgres"
> how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.
Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!
I've used it for a couple uni/personal projects to get some experience, and firebase for the same. I'm concerned about getting locked in, what other providers do you recommend who can let me migrate more easily?
Supabase is one of the most portable platforms out there.
The whole stack is self-hostable and open source. All of the data are contained in Postgres. You're one pg_dump away from being able to switch to a different Postgres host. Or if you're switching to something else entirely, you can export the data to CSVs and take it anywhere. But we're confident you won't want to :)
supabase, directus and similar are just wrappers on top op postgres.
I just spin up local postgres instance for personal project and see no reason to get vendor locked-in myself.
They seem to heavily invest in their social media presence with things like the YouTube channel, but then also use social media indicators (likes/follows/subs/etc) as a measure of success. Seems a little circular.
The plot of Github Stars over Time: Supabase vs. MongoDB seems particularly silly (imo).
Not a hater by the way, I think their YouTube channel is actually pretty good, and I think it will become increasingly common for startups/businesses to have something like this for product/brand awareness, getting users up and running, etc.
I think if the goal of the post was focusing on platform maturation and growth, it might have been better to focus exclusively on the plots of database/users over time, and simply link out to the various social channels.
Overall though still cool to see, and congratulations to the Supabase team!
Awesome, the Index Advisor sped my slowest query 4x! Is there a way to run that across all queries in pg_stat_statements at once or do I need to click on each one?
In Studio you'd need to click on a query to get the recommendations but the most important queries to optimize are on several metrics like "Most time consuming", "Most frequent", "Slowest execution" are sorted worst-to-best in tab views.
But if you do want to scan all of your queries at once for possible indexes you can do it in SQL with
Happy Supabase user here, albeit on a tiny app I work on in my spare time. So no comment for larger or more complex orgs.
That being said, the Swift documentation could use some love. It’s not terrible but it’s also not great. There have been a number of times when I wanted to do something, ended up reading about it on the Supabase JS documentation, and then thought “well I assume it’s roughly the same in the Swift library.” It worked, but a pain to have to guess a lot.
I would add that it's gotten better since it was folded in for official support, but it could still use some love. So cheers for improvement, and stay at it. It's encouraging to see a community add like this folded in to the main.
Readit News
Here's our experience with Supabase at https://automark.io (Next.js + Supabase).
- First of all, Supabase let us launch fast which was amazing. Super powerful Postgres features without the pain of self-hosting (or so we thought).
- We started out using their hosted product for both our DB, storage, auth, and functions.
- Functions have a critical bug that prevent us from using in development so we decided to move to our own API servers: https://github.com/supabase/edge-runtime/issues/212
- Now, the connection between our API servers and the database was slow (a few hundred ms per query), so we moved to self-hosting Postgres which was pretty painful. We tried to use https://github.com/supabase/postgres, but the documentation was very lacking and we had to make a bunch of modifications to get it to work. After we got it working, it was pretty smooth though - pretty easy to implement backups, etc.
- Our latest issue has been around auth where the cookie name options change. We've spent hours debugging random cookie issues deep in the auth framework (they finally released `@supabase/ssr` which is pretty decent, but we're still thinking about moving to handling auth on our side so we know and can debug the logic).
One thing to mention: although our requirements didn't quite fit Supabase and we ran into these issues, we weren't locked into their hosting. We were able to completely move off of it over the course of a few weeks, but continue using the self-hosted version. This is a huge benefit over something like Firebase or Amplify. We're pretty satisfied with Supabase as an open source project, but not as satisfied with Supabase hosting.
As an open source company, we'll take that as a mark of success.
Thanks for the details, I'll jump into that GH issue with the Edge Functions team after this week
Do you guys spin up individual Postgres instances for people or use some multi tenant approach?
The server to database latency was very high(few hundred ms) whereas Planetscale DB in the same region gives sub 10ms.
Still great option for most projects that can do with these issues.
I have a toy project with a server on Fly.io and the DB on Supabase within the same city
When sending API requests to the server, my end user latency was around 25ms-100ms (depending on the endpoint and how many DB calls it was doing)
Now with Supabase on Fly, that API latency is down to 17ms-70ms. But Supabase on Fly is still in alpha so it's not relevant for production yet
we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0])
we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in our journey, one of the best sources of product feedback [2]
the GA badge is mostly to signify organizational readiness. we're at a stage where we can take any profile of customer. we have a support team that works 24/7, and a success team that will help customers improve their postgres usage. we released our Index Advisor [3] yesterday, and we'll be releasing a few more products this week that helps customer with performance and security.
on a personal note: i read HN most days, and love going through the ShowHN's to see what devs are building. thanks for being an awesome community and my favorite place to lurk on the internet. i'll stick around to answer any questions
[0] PostgREST: https://postgrest.org
[1] Launch: https://news.ycombinator.com/item?id=23319901
[2] HN journey: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[3] Index Advisor: https://news.ycombinator.com/item?id=40028111
at the start, the "firebase alternative" positioning made it unclear to developers who thought we offered a NoSQL database. We always wanted to be "Postgres plus useful tools" so we started evolving the positioning over the past year
you'll still see "firebase alternative" on our site: I think the comparison is apt and the aspiration remains the same
Overall, it’s great. I recommend it to people. The high signal part is what I would work on:
- deeper integrations with common OpenID Connect providers, with a pretty foolproof “bail to browser view that looks like Kinde or Clerk”. there’s only so much you can do, but it’s not trivial to get wired up to a bunch of pick-and choose SSOs.
- prisma should be front and center, the auth/public schema split is not a breeze, Prisma slays at being an ORM, Supabase slays at other things. It’s not obvious whether or not to use realtime or Pulse.
- force the env footprint on e.g. next or expo or whatever, it’s a little glue, it’s a lot of people who don’t pop out of the funnel.
- chat / dm is a common enough use case to be in the wizard (like avatars), Postgres handles it fine for small to medium apps, and arguably for big ones
- have a pass through mode for the local deploy that’s easy to toggle, you guys are fast AF, it’s often sane to dev directly against the instance.
- I’m sure you’re already building the kind of anonymized training sets that let you spot bad configs a mile away.
Again, nitpicks on a great product. I love Supabase.
Deleted Comment
I paid $20/mo for a while because of the free tier storage cutoff (500 MB), but have since stopped. I wish you had a $5/mo tier for "small projects" folks who need a database larger than that.
For example, Cloudflare's Workers Paid is $5 for D1 databases up to 10GB, with 5GB included and 75¢GB after. I know this is comparing apples and oranges to some degree and that your business model may be incompatible with this use case, which is absolutely fair.
RBS is "insecure by default" meaning if you don't set it up right, all users can access all data. And, because it's SQL, it's really easy to write a valid and successful configuration that doesn't work. You have to test it. And for views, you have to do some real heroics to get them to respect RBS.
PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.
Yes, I know that I could make a direct SQL connection to the database, but at that point, it would've been easier to put a Rails app on Heroku and use their offering, which is far more mature.
The Supabase dev environment was pretty slick and worked well, though I had to docker implode a couple times.
I wish them luck, but I could not figure out what the use case was for their product, given that Heroku has an awesome managed Postgres and RDS is there if you have more knowledge and want more controls. I don't see how you could make a complex app that is front-end only with Supabase as your entire back-end.
RLS disables all operations on a table once enabled and is only operable once there's a passing policy unless you can bypass RLS.
When it comes to access control, you should probably always have tests for anything halfway important.
Views are a bit of a footgun when it comes to RLS, they bypass it by default. But getting them to play nice is as simple as defining "security invoker" in their definition; not what I'd call heroics.
What makes you think that? PostgREST delegates all the authorization to PostgreSQL, which is secure by default. You have to explicitly assign privileges to roles for every operation.
Relevant previous discussion: https://news.ycombinator.com/item?id=38689294
The PostgREST query grammar is basic on purpose, you're supposed to write SQL on views or functions[1] to extend its capabilities.
[1]: https://postgrest.org/en/v12/references/api/stored_procedure...
Do not build out your MVP on supabase. If you need to scale and want a MSP do it after the MVP. Detangling the lock in is not fun.
Everything offered by supabase is easily found elsewhere without the MSP lock in.
I can imagine they fall short in some aspects from that ideal and I would love to know your experience but even with your first sentence this is just a pretty damning write off.
Disclaimer: I'm NOT a Supabase employee, just a happy user.
Off the top of my mind, PostgREST and go-true? https://github.com/supabase/auth
-
If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers.
If you leave Supabase, you'll lose the fully managed aspect of 99% of the Postgres providers out there, which confirms the pain the parent comment is describing.
On an architectural level, it is also terrifying to have your database exposed to the public internet just hidden behind authentication and RLS policies (which are much harder to reason about for most developers, and for which there is very immature tooling, a recipe for disaster).
Plus the local dev experience leaves a lot to be desired. We spent days trying to get file uploads working only to find that the issue was with local Supabase, and we had to create a remote Supabase database just to upload files successfully. But then we can't "reset" the database to run migrations.
The product is definitely much less smooth to develop on and I've had to provide dozens of hours of free client consulting work to untangle my recommendation of Supabase (didn't feel right to charge them to fix a product choice that I recommended to them).
Right now I'm in a strong "never again" view on this set of technologies. At least not for a long time until the tooling improves.
But it seems like there are some happy customers. So would love to hear a counterpoint of how they overcame all the issues we've faced:
- how are your security teams ok with exposing your PG server to the internet, relying mainly on RLS? And RLS isn't turned on by default, so full tables are exposed to the public internet by default, behind a rather nice REST API.
- Reliance on RLS for a public service seems risky because RLS quickly gets harder to maintain as you have to get more complex policies in place without much tooling to help you.
- how about the fact that some of your most important code, the RLS policies code, is hard to unit test with today's tooling? And they recommend pgTAP, which, who knows how big this community is?
That combination seems highly risky to me.
Our best bet right now has been to just install prisma and implement more traditional filtering on top of RLS, and just not rely at all on client side connections to postgres. So in a nutshell, moving away from Supabase specific architecture to more traditional architecture. The real "It's just postgres"
Tooling is improving constantly and security really is at the top of mind for us. We've got some cool announcements this week that will keep reminding you if you're doing something sketchy!
Supabase is one of the most portable platforms out there.
The whole stack is self-hostable and open source. All of the data are contained in Postgres. You're one pg_dump away from being able to switch to a different Postgres host. Or if you're switching to something else entirely, you can export the data to CSVs and take it anywhere. But we're confident you won't want to :)
disclaimer - Supabase employee
Deleted Comment
The plot of Github Stars over Time: Supabase vs. MongoDB seems particularly silly (imo).
Not a hater by the way, I think their YouTube channel is actually pretty good, and I think it will become increasingly common for startups/businesses to have something like this for product/brand awareness, getting users up and running, etc.
I think if the goal of the post was focusing on platform maturation and growth, it might have been better to focus exclusively on the plots of database/users over time, and simply link out to the various social channels.
Overall though still cool to see, and congratulations to the Supabase team!
But if you do want to scan all of your queries at once for possible indexes you can do it in SQL with
```sql
create extension index_advisor cascade schema extensions;
select ia., pss.query
from pg_stat_statements pss, lateral( select
from extensions.index_advisor(pss.query)) iaorder by (total_cost_after::numeric - total_cost_before::numeric)
limit 100;
```
That being said, the Swift documentation could use some love. It’s not terrible but it’s also not great. There have been a number of times when I wanted to do something, ended up reading about it on the Supabase JS documentation, and then thought “well I assume it’s roughly the same in the Swift library.” It worked, but a pain to have to guess a lot.
I'll let Guilherme know. feel free to reach out directly with any specific feedback