This is not a negative statement against Supabase, but heed my warning:
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.
hey hn, supabase ceo here
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
Why do you not use capital letters in the typical way?
It is a little bit painful to read. Capital letters exist for a reason (to make reading easier)
what exactly do capital letters make easier to read? i dont think readability is why they are used for proper nouns, names, nor the pronoun I. and obviously ALL CAPS isnt a readbility improvement either. presumably just as delineation of one sentence to the next? (forgive my ironic non-use of caps to start sentences haha).
Look how nicely davetron5000's comment below can be read. Proper capitalization makes text much more readable.
Correct. The dileneation of one sentence to the next, which is somewhat an indicator of the end of one thought - or fragment of thought - and the beginning of the next.
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
Well I'm not that young. I guess it just helps me to write fast when I'm not thinking about punctuation/grammar. I'll make more effort to capitalize.
When did the positioning of Supabase changed from a "Firebase alternative" to a "Postgres hosting"?
we're constantly evolving it.
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
Congrats to the Supabase team! You've all done some impressive work to be proud of.
thanks for the kind words
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.
this is all great, actionable feedback. Thanks for this - really nice list
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.
Congrats on the launch!
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.
Tried Supabase but currently only use their Auth.
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.
How far was the server from the Supabase instance?
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
same aws region as supabase instance using a single query.
Same region, different provider. Also, their JS API has to do a round trip every time you set auth credentials on the backend, so it's at least 2 round trips for a single query.
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
And functions often have multiple db calls not just one. The latency would be a deal breaker no?
We're pretty satisfied with Supabase as an open source project
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
Hi.
Do you guys spin up individual Postgres instances for people or use some multi tenant approach?
Yes, it’s a full Postgres database.
Oh cool. Are each database instance on its own instance or shared instance?
I’m just curious, how does it work
on AWS: each a separate instance
on Fly: each in an isolated Firecracker instance
I'm not supabase client, so I guess my wishes do not matter much, but I'm self-hosting it and the experience was not pleasant. They just gave me some huge docker-compose with barely any documentation about it and that's about it. My approach to self-hosting software is carefully learn about every service I'm going to run, disabling everything not needed for my use-case. That was not possible with supabase without significant time investments.
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.
one golang binary which embeds everything supabase offers
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...
Look at Grafana Loki. They have single binary which serves many different roles. You can launch it with different flags for scalable setup, so each instance would serve a different role. Yet you can just launch one instance and it'll do it all by default. I'm using it with this approach and it works just fine for my log volume. And I have the way to scale if I would hit limits. May be it's not elegant to have multiple services in the one binary, but disk space is cheap and code does not take much amount.
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'm talking about docker/volumes/logs/vector.yml
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
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.
we just took over official support for swift: https://supabase.com/blog/supabase-swift
I'll let Guilherme know. feel free to reach out directly with any specific feedback
Ha, the timing makes it look like you did this in response to my comment. :D Very excited about this!
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.
Curious to see how many of those million databases are from free users.
Feels like we're living in the golden age of free platform offerings.
Wonder when the shoe will drop.
I am happily using the free tier to help launch my startup. It is invaluable to me. I am a big fan of it, and have no regrets with this decision (only 9 months in). I admire what I am allowed to have for the low price of 'free now, pay when you need to'.
thanks for building with supabase. good luck with your startup!
Curious to see how many of those million databases are from free users.
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.
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.
Relevant previous discussion: https://news.ycombinator.com/item?id=38689294
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.
[1]: https://postgrest.org/en/v12/references/api/stored_procedure...
Any news on the integration with Fly.io going GA?
it's progressing! we'll have some news on friday
From a recent post by a fly.io employee in their forums [1], in response to being asked "do you expect it to be ready for production use this year?"...
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...
I also know appwrite. It looks quite similar to me, has it the same target audience?. Is there any comparision chat? Thanks.
I've tried briefly both, but mostly selfhosted versions. If you're interested only in managed versions then skip this comment.
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.
Supabase is great - I use them now and they and would be my choice for a new project today - but I have to say I am not a huge fan of how they communicated the whole auth-helpers and ssr situation, and I am not the only one with this comment by a long shot. This is, I think, a part of wider issues with their documentation; it seems like whoever's doing documentation at Supabase is intelligent but stretched thin. Particularly for Sveltekit, the documentation and examples are incomplete, there isn't any guide to migration or how to modify your code, and if you Google things or follow any links or examples you quickly end up in a web of deprecated repositories where it's unclear what to do next or replace them with. One example: https://github.com/supabase-community/auth-ui
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.
They're still the best, it's a very powerful and impressive product
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
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
```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;
```
I have to say, I tried it but at that time the self hosted offering was too limited, and the good stuff, the useful stuff was behind the cloud subscription paywall.
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.
the good stuff, the useful stuff was behind the cloud subscription paywall
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...
The acquisition of Oriole is very interesting. Getting that to a GA product would be a game changer for a lot of workloads.
I'm excited for more OrioleDB patches to land in upstream. Sounds exciting.
Interesting how they posted a self-host guide just a few hours before announcing this. https://www.youtube.com/watch?v=FqiQKRKsfZE Perhaps expecting criticism and preemptively creating a response that shuts people down?
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.
the video has been available on our self-hosting docs (https://supabase.com/docs/guides/self-hosting/docker) for months (see comments age). I just noticed that it was "unlisted" instead of "public" when I was making this GA page so I made it public. There isn't anything sinister here
"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.
I've been trying out Supabase for an MVP but while the hosted postgres part is quite nice, the C# SDK recommended (but not maintained) by Supabase falls quite short, leaving me to trace down all sorts of obscure issues that turn out to be a 2-year-old bug in the SDK that's still not fixed. It is kind of nice for a community effort but definitely not good enough at all for professional adaptation by .NET developers.
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.
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
I'm a full stack developer and still don't know what supabase does other than being a firebase replacement...
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".
It's not serverless it's a postgrest API over a DB. Which is plenty of backend for many of my purposes. Postgres's RBAC is sophisticated enough to use as your entire auth layer if you know what you're doing with it. After that it's a free rest API.
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.
How it compares against neon.tech?
Congrats! Happy supabase user here
I like supabase very much, but their network latency in China is too high. I have tried nodes in Singapore and Tokyo. It doesn't matter as a personal blog, but I can't consider it for business purposes. I had to host it myself on Alibaba Cloud, but I had to face many complexities. I like the simplicity of supabase. Maybe, when will they be able to host within China?
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!
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.
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.
People keep writing this, doesn't Supabase rely on spinning up additional services to leave, meaning you can't leave to another managed offering?
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.
this is no different than running, say, Rails on a managed service. You can take the service and you run it somewhere else: each individual service is wrapped into a docker image which should make it easy.
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...
This just sidesteps what I said?
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.
You're suggesting a hosted Postgres offering isn't "as portable" as a very standard solution?
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.
Is having your frontend hook directly into to your database without a backend a standard? I almost exclusively saw it in locked in BaaS platforms over the years (like Firebase)
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
I'm guessing a "managed postgREST" would look like a docker container deployed to AWS App Runner or Google Cloud Run with the standard Postgres RDS hocked up to it.
let me have another run at it:
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
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.
Sorry, confused by the wording: what does 'spinning up' mean here?
Configure and begin running
Better step away from your keyboard then, until you start to use something and getting locked in.
Point is that if you need to be free, the barrier is lowER.
You can just take the Auth server, run it yourself with an AWS RDS instance for example, keep up with updates and be good to go.
Yes you get a good UI with Supabase, and even much of that can be hosted yourself.
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 :)
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.
we know of many, many companies using Supabase self-hosted or with an external database.
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)
I self host a couple supabase instances.
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.
That does not track with anything I've ever seen out of using Supabase
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?
You can use supabase simply as a Postgres provider. Supabase is just postgres, and you can choose to use any tool we provide (or not)
I've so far found the most value in authentication, so thank you for a great self hostable product
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.
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"
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!
An access-simulator where you can check if a user (or anon) has some type of access would be helpful.
we actually have this:
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:
https://github.com/supabase/splinter
Good to hear, thanks.
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.
Kinda sounds like "client side connections to postgres" was the poor decision at root of your security concerns, not the choice of provider
Client side connections and RLS are the Supabase blessed path in the getting started docs
Don't go to production with what's in "getting started".
But that is the path that Supabase strongly recommends if you use their tech stack.
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.
What were the troubles you faced?
If it's postgres with easily available plugins, then where is the lock in?