We are moving to General Availability
supabase.com
supabase.com
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?
I’m just curious, how does it work
on Fly: each in an isolated Firecracker instance
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.
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.
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
Not in my experience. The documentation and infra is just not there to make it easy to use an external postgres db.
if you have any problems, feel free to reach out to me directly. We want this to be simple (and you can see that there are non-supabase commentors in this thread who are self-hosting, so it's not just lip service)
That said it feels like every other week there's an update that breaks the self hosted compose, looking through the GitHub issue tracker shows a few issues where the suggestion is "oh yeah the latest X image doesn't work, regress the version to get it running"
I really like supabase, but stability on the self hosted images is my biggest gripe with it currently.
If you target Postgres, just about any Postgres instance works the moment you enter a connection URL.
You can hop from one managed Postgres offering to another in 10 minutes and lose no functionality. Everything from auth to programming (and even RLS implemented in the query space) will work instantly: no additional software needed.
Are you claiming that's the case with Supabase and its JWT auth/RLS entanglement?
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!
I really am trying to provide constructive criticism (even if my tone is not great because the pain I'm continuing to feel with the platform is still fresh).
I do think you guys are in a great position to actually improve all that tooling around RLS. Tools that can analyze your policies, that can visually map the recursive nature of policies that run, etc.
https://supabase.com/blog/studio-introducing-assistant#user-...
and you can expect to see another related launch this week with some more in-depth tooling:
I fully agree that some of the issues (like poor RLS tooling) doesn't necessarily fall on Supabase's shoulders. But this is the path that Supabase strongly recommends.
So you kind of can't have it both ways and say "Supabase is just Postgres" but then say "this is not our problem, it's postgres", right?
I actually think Supabase is in a GREAT position to actually build some of this missing tooling. They're probably now the single largest beneficiary of more people using RLS.
So I do think they will tackle this problem, it is a smart team. I just think that because of these issues, as a cohesive platform, it definitely doesn't feel fully baked (or "generally available" status) yet.
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.
Yes you get a good UI with Supabase, and even much of that can be hosted yourself.
You can use as many or as few of the services as you want - its designed it that way:
https://supabase.com/docs/guides/getting-started/architectur...
Supabase is most attractive to those without the skills to run an unmanaged service
A bespoke solution, even if it's open, doesn't mean it's as portable as a very standard solution.
If you want portability, the parent comment was right: don't embed Supabase deeply into your application.
> If you use Postgres you're "locked" into Postgres: a technology with a laundry list of providers.
Supabase is just a Postgres platform, and you can use it like that so that you can migrate away to any one of those laundry list. We _also_ provide some tools which are nicely integrated but importantly: they are optional
> doesn't Supabase rely on spinning up additional services to leave,
No, not if you don't use those other services. If you _do_ decide to use another service, then yes, you need to spin it up to leave (or migrate to something else). Hence my comment: this is no different than running, say, Rails on a managed service.
This isn't DynamoDB here, this is about as standard as it gets. I'm failing to find the supposed lock-in being talked about here.
I've barely even seen PostgREST offered managed: is even one managed Postgres provider with the right combination of PostgREST and go-true to let you move over today?
Edit: I also don't get why this is such a point of contention...
Since when is BaaS not just a trade off between initial velocity and later stage lock-in? The former is not worthless, but like most tools you should understand the tradeoffs involved
Point is that if you need to be free, the barrier is lowER.
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)) ia
order 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
Both have docker based setups and getting them up and running is documented clearly enough.
The biggest difference right off the bat (ignoring PosgtreSQL vs MariaDB) is that Supabase selfhosted just gives you default project and that's it. If you want to host several projects you either spin up new instance or make use of table prefixes. With Appwrite you can create new projects that are independent of each other, including auth. You can have organizations -> projects -> databases granularity. For sideprojects that's a huge win for me.
Supabase gives you a way to run raw SQL on your tables via web interface which I really like, it gives a better way to gain insights into your data without wrestling with client side queries which may or may not do what you need. Appwrite doesn't have that, you have to make do with their queries.
Documentation is fairly fragmented in both, code snippets and examples have not been updated for changes, some new features are only discoverable via search but not via documentation menu e.g. Appwrite's SSR documentation. Most complete documentation in both seems to be for Javascript. I managed to get auth working, but it may require some head scratching, especially if you want to use something different than their default examples.
Appwrite gives you shell scripts for backup/restore right there in the documentation, Supabase does not. It's not anything fancy, but it's nice to have. There are no ways to generate backup from Supabase web interface either so you have to write your own scripts.
Appwrite gives you basic dashboard of stats for your databases and simple charts for traffic and requests, Supabase selfhosted lacks that. Managed version has reports so they're clearly withholding this in purpose.
The thing that made me not want to go with selfhosted Supabase in the end though was constant CPU usage when idling. Some usage is expected, but even on my workstation the load stays around 5-8% and is frequently peaking up to 12% or more. In contrast Appwrite stays between 0.6-3%. On my VPS idle peaks are up to 25% which is wild. The culprit seems to be Supabase analytics and health check which logs agressively and spams console several times per second. IIRC there was open issue about it but the response was "maybe disable health-checks then". This coupled with just having one single project makes it not suitable for self hosting for me. Haven't used functions or realtime in neither so can't comment on that. Overall Appwrite's self hosted solution is more polished, but YMMV.
On paper, Supabase really has all the ingredients I should need to make my application. In practice, I still end up struggling a lot with the development model. I wish there was an easier, safer way to create RLS rules that doesn't need me knowing (to me) obscure Postgres syntax. This is especially grating since the rest of the tooling seems to try to take me away from SQL a lot by using Postgrest.
You're actually encouraged to write SQL with PostgREST, see this other comment https://news.ycombinator.com/item?id=40046710
Ultimately I just see the same pattern in Supabase as in many of these "easy scaling" solutions: lock in. I think the future is something like those platforms are offering but we're definitely not there yet. Also it's not like I'm an old person refusing to accept new tech. I'm young and looking to create things but I recognize that these services are (currently) doing the complete opposite of giving me freedom.
> "easy scaling" solutions: lock in
This has been hashed through in a few comments on this post: Supabase is Postgres. We offer tools on top which you can _optionally_ use. Some people love those tools (especially Postgres maxis). Some people prefer to just use the database with Django/Phoenix/Rails/etc. You choose your own level of comfort.
Feels like we're living in the golden age of free platform offerings.
Wonder when the shoe will drop.
A LOT! Probably most.
But Supabase is committed to the free tier and it's not going anywhere. It's crucial to helping demonstrate all the features and the DX to developers.
So my wish would be for supabase to provide some kind of minimal bare-bones configuration and careful documentation for their monstrous docker-compose configuration with explanations why all parameters were set to non-default values. I don't think that I need all those services if I don't use any of them except database and sometimes admin UI.
Also I think that I even had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs.
Right now I've set up supabase for our developers but asked them to migrate to plain postgres as soon as possible, so I could move production workloads to our standard setup.
My ideal setup would be one postgres instance which I can install myself from plain docker library image; one golang binary which embeds everything supabase offers turned off but with some envs to enable and that's about it.
I understand the sentiment here, but truthfully we chose an architecture that scales, then made it as easy as possible to run. Each service has very different scaling requirements: connection poolers, auto-generated APIs, Auth servers, etc. Putting them in a single binary would trade one problem for another (IMO, bigger) problem
> Also I think that I even had to edit some configs for api keys or something like that. It should not be like that, everything should be passed down via envs.
I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs?
[0] https://supabase.com/docs/guides/self-hosting/docker#securin...
> I think you're referring to the "Securing your services"[0] section right? These are all stored as env vars - perhaps that's not clear from the docs?
I'm talking about docker/volumes/logs/vector.yml. There's "api_key=your-super-secret-and-long-logflare-key" which is supposedly should be replaced by the actual logflare api key value. The guide does not instruct to change LOGFLARE_API_KEY but I guessed this key is there for a reason and should be changed.
I've flagged this to the Logs team to fix immediately
> Look at Grafana Loki
I'll check it out thanks. My gut is that running Postgres + 4/5 other services (many different languages) is a harder beast than Loki, but understand the sentiment and we'll see what we can do here
edit:
we've fixed the yml file: https://github.com/supabase/supabase/pull/22860#pullrequestr...
thanks for flagging this. If anyone else spots things like this please feel free to open a GH issue so we can amend it asap - given enough eyeballs, all bugs are shallow
>Coming very soon, we’ll be moving to public alpha (which in our world, comes after private beta :smiley:).
[1] https://community.fly.io/t/supabase-managed-postgres-in-priv...
Like seriously are they seriously trying to sell us how difficult is to setup a simple nginx server? Not sarcastic just an old developer that hasn't get this new fad of going "serverless".
I'm not like a supabase diehard or whatever but I have used it to great success in a handful of projects, especially early or proof-of-concept stage ones. For me it's not a replacement for nginx it's a replacement for rails.
If you produce a product for developers, you really need to have 1) quality, readable documentation with an introduction that noobs and pros alike can follow, 2) multiple complete, cloneable examples on how to integrate and use your product in several different libraries, 3) obvious migration guides and timelines whenever you deprecate something. Supabase lacks all three, which is extremely frustrating and means there's always a giant caveat when I recommend them. They're still the best, it's a very powerful and impressive product, and the possibility of self-hosting is amazing.
first, thanks for these kind words - it's encouraging (as a maintainer, not just a team member) when we know we're on the right track
sorry about the frustrations, especially around the ssr/auth-helpers. We definitely could have handled that migration better (and the comms in particular). To address some of your other points:
> 2) multiple complete, cloneable examples on how to integrate and use your product in several different libraries
Yesterday we made it even easier to do just that with "supabase bootstrap"[0]. We'll be adding all of our quickstarts[1] which cover most of the key (frontend) frameworks
> 3) obvious migration guides and timelines whenever you deprecate something
Agreed. We actually developed this internally after the auth-helpers/ssr. We'll do better in the future.
[0] bootstrap: https://supabase.com/blog/supabase-bootstrap
[1] quickstarts: https://supabase.com/docs/guides/getting-started
The initial experience was easy to get going, but the devil was in the details. Much of the logic should be server side also for security reasons and that wasn't possible when I tried it.
People like to hype things that are easy to get started with but don't go much further so the initial impression remains.
I think the appeal is to people who like doing frontend but don't like doing backend.
can you share more? everything is open source, the code available, and all OSI-compliant
> Much of the logic should be server side also for security reasons and that wasn't possible when I tried it.
This is possible in very many ways:
1. Write an RPC function and use PostgREST
2. Use Edge Functions
3. Use whichever frontend framework you are developing with (they all integrate well with supabase)
4. Connect a server directly to the Postgres data ase in a 3-tier architecture
Perhaps! We also have a large number of customers using us as a traditional Postgres host. And we have a lot of "Postgres maxis" who love the RLS + PostgREST combo. You choose your level of comfort with Postgres: https://supabase.com/docs/guides/platform/shared-responsibil...