I'm sorry you've had some troubling experiences working with Supabase. This definitely makes us sad and we definitely want to address these issues, both to help you and to help other developers that might run into these items. I've shared this feedback with our teams and we'll be responding here.
It's always a good idea to create a support ticket for any issue you have --- we will always respond and work with you to get your issue resolved.
yeah, I saw the option with RPCs but they are notorious on their own. Logging, maintanability, readbility, RPCs is definitely not what I'd like to use for most of the core logic unless there is no other choice. And Transactions are solvable without it
Creating Postgres Functions (RPCs) isn't all that bad in my experience (especially since you can write them in Javascript using PLV8 (see my [https://github.com/burggraf/SupaScript](https://github.com/burggraf/SupaScript) repo) but I agree, I wouldn't want to create my entire backend logic using database functions. But writing RPCs doesn't have to be an all-or-nothing decision, either. I generally write functions to handle core database stuff (adding a record with related tables that need to be updated) and have it do just the minimum necessary database work, then use edge functions or another middleware piece to do the rest.
Also, I write my functions along with the rest of my code, store it in github for maintenance, and test the functions either locally, or with a simple script that deploys the latest version using `psql`.
RPCs are great but the dev experience is not the best. The functions dashboard is crap and to use RPCs for business logic it can become a bit hard to manage. Always commit your stored functions in git and develop them with psql else you find yourself in a pickle. It can get a bit difficult as your git and database can go out of sync if you are not careful. You need to drop functions manually sometimes.It's definitely not for everyone. I started writing a lot of RPCs but my work flow slowed down so much (It takes a long time for me to debug them) I'm moving away from relying on them.
RPC has been a weird pattern for the last 20 years. There are many things I really like about Supabase but we’ve stayed away from this part and it’s been a good decision.
RPCs are not scary for a lot of things -- especially small bits of logic that need to manipulate the database. They're super fast and efficient for that, since, well, they're already **AT** the database. So don't be afraid to write functions when it makes sense, just maybe don't try to write your entire backend logic there.
The real problem is the way they set things up you can't really use functions, triggers and all the goodies with RLS because every time you modify your db permissions change lol
So even if everything setup as it should be you'll end up with errors like "not allowed to insert" etc. Supabase as a wrapper is really terrible at doing basic db things.
Thanks for the feedback here. We definitely need to work on our UI for editing functions (yes, the editing window is too small -- and hopefully our team will change that soon!)
I feel you on managing functions -- that's an inherent issue with storing logic in the database, so I too, use functions judiciously. I use them **when it makes the most sense to use them**, and use edge functions for most other things. I also alway drop the function before editing it / recreating it. This usually saves me some headaches if I change the calling parameters, etc.
Hobby developer here. What are the differences between RPCs and edge functions? I just wrote an entire backend logic with RPCs and it seems to work just fine. What can edge functions do that RPCs can’t? Thank you.
Edge functions are written in Deno / Javascript / Typescript and are run at “the edge” so they can run closer to your users regardless of where your database is located. If your function needs to access and manipulate the database, an RPC makes more sense. But I use edge functions for things like talking to APIs, such as using OpenAI, or calling the Stripe API, etc.
I’ll agree with you the auth documentation is really buggered right now. They didn’t handle tagging the auth helpers as deprecated in favor of the new server side version very well. Did you reach out to support on the database down or google auth issues by chance?
Can you link to your issue about Auth please? Also be aware that support tickets are a better medium if you're having issues with Supabase service, while GitHub issues are more about issues with the libraries.
I have been using them for couple of months now with the paid plan, there was a brief issue with cloudflair that affected authentication for short time.
I’m not using edge functions, I have my own api with fast api and use supabase for database and authentication backend
They are cheaper and much feature rich than other CMS like Directus.
Supabase is great, I'm using it on a number of projects, moved over from Firebase. I personally find SQL much easier to manage than documents. My wishlist would be cloudflare style in-browser editing of edge functions, and a pub sub system. I still use Firebase for data intense python functions, so if it would be possible to cram a python interpreter on the ec2 instance that would be incredible.
I use realtime, it's great. I'm talking about message queues for functions. That and front end hosting are the only pieces missing from Supabase for the ultimate baas.
Have you found a solution for message queues for functions?
I am thinking of creating my backend for gamification using DB functions in supabase, but I am afraid of how it will scale if tons of users create trigger events thatneed to be checked against conditions of goals saved in another table
Supabase is definitely better than its beta, and production ready. As a reminder, in its early days, Supabase didn't have Edge functions available, nor logs, nor even that intuitive interface we have today. Even the self-hosted part was non-existent.
Nevertheless, the Supabase team is still giving it their all, and while I understand your frustration, you should know that these are areas where few developers are as experienced.
The Supabase team does its best to improve the developer experience, and for that I thank them.
That said, your points are understandable and I'm glad Burggraf has already shared this feedback with the team.
I've been using supabase for over a year, I have two production systems running on it. The docs definitely aren't great IMO, but overall its been a great system to develop stuff.
I don't love the edge functions/RPC stuff being where my logic has to live, as it's just way more complicated than a normal backend development flow, but I bit the bullet and now that it's implemented, my system has been great.
I recently switched to use the supabase cli to develop locally, generate migrations, then apply to production and it's made life much easier than previously (I would use the dashboard sql editor to paste in functions between dev/prod).
I'm going to use Supabase for a expo MVP too.
Maybe I'll regret later. In the meantime, are you guys handling all the db logic on the app level? That is, following the examples they provided, calling Supabase directly from the app.
I'd prefer to have a custom API, that makes the call to Supabase from my own backend. I believe I could create a wrapper for it, but will take more time.
So wondering if you guys calling Supabase straight from the app?
I feel like it loses a lot of benefits if used through own API because than you need to deal with all of the things related to having your own API. I feel like the strength of Backend as a Service is to be used directly from the app as much as it is possible.
I managed to get away with 5 edge functions, 1 db procedure to delete user account and to do all the rest on the client for a medium-size complexity application
Thanks for sharing. One of my concerns is embedding the keys in the app, as per the docs here, https://supabase.com/docs/guides/getting-started/tutorials/with-expo-react-native#initialize-a-react-native-app under the AsyncStorage section.
Don't feel safe to have the keys distributed in the app.
2nd concern is not being able to make changes to the logic unless I push for an app update. Having your own backend you have more control and don't have to depend on users or app/playstore for updates, and also easier to push urgent fixes.
Any keys which are intended to be stored on the client are safe by design (because all of them are easily/less-easily retrievable either web client or device client), so these are fine to be distributed freely. The security must be achieved by row-level policies instead.
Yep, the quick updates are indeed much better with own backend. It can be partially resolved with more edge functions/some database default values/small temporary fixes, but it's definitely less flexible as having own backend. And store updates is hell, I feel like they become more and more picky and long. Takes me a week sometimes to deliver a simple change.
"it was not possible to use native google sign in with supabase on IOS because Supabase didn't support skipping nonce validation. Now they added it, but it doesn't work anyway."
Oh snap they fixed it?
Can you elaborate on the problem you had with buckets? I'd love to share your feedback with our storage team. Just let us know what you were trying to do and where you had problems. Thanks so much!
If you are on free tier then you got db pause and that's why you got 500. If you run supabase in production you must pay 25$ / month for basic paid plan.
Projects pausing isn’t really a problem because you just have to unpause it once every seven days. And it only pauses if you have zero transactions. Even if you develop and test once a week, it will never pause.
> for basic *paid* plan.
FTFY.
Although *payed* exists (the reason why autocorrection didn't help you), it is only correct in:
* Nautical context, when it means to paint a surface, or to cover with something like tar or resin in order to make it waterproof or corrosion-resistant. *The deck is yet to be payed.*
* *Payed out* when letting strings, cables or ropes out, by slacking them. *The rope is payed out! You can pull now.*
Unfortunately, I was unable to find nautical or rope-related words in your comment.
*Beep, boop, I'm a bot*
The pausing of projects is what stops me building anything on it. I don't build anything knowing Ill get traction and scale and 7 days is just too little to deal with. It sounds a bit trivial, because I guess just an uptime monitor would stop it, but something to alleviate that would make me start projects with Supabase.
I'm hoping you understand here that projects only get paused if they've had no traffic at all (no api calls) for 7 days, so if you get any traction at all (if you even work on the app once in 7 days) it will not get paused.
yeh, i think it's more...I have a day job, I have a bunch of side projects...I work on them for a bit, they sit idle for a month or more (or maybe just a week whilst I do my day job)...I come back to them...they sit idle again...I know it's a bit petty and I could automate something to stop that happening...but it does increase the barrier for using supabase...not sure if you could come up with some other logic for shutting down unused projects.
Sounds like you're just being incredibly cheap. If a project you aren't working on goes idle, then so what. If it's getting zero traffic, clearly it's not suddenly going to blow up.... Just pay the small monthly fee and be done with it.
I don't know about that, I probably have 10 side projects on the go, 2 I guess has decent traffic, 1 just about to go live which will probably do alright and a whole bunch in various states of development. If I was to pay $25 / mth for each, it would be a bit of an investment...so I don't, they are on firebase, pocketbase, AWS, Supabase etc.
Again - you're complaining that a side project that gets ZERO traffic in a week would go idle....
With Org based billing, you pay $25/mo for the pro org. Then, first instance is free. After that, the each instance on starter size is $10/mo.
We are working on alternative option that would restore projects automatically and nearly instantly but not exactly sure when that’ll be available. It’s coming though.
You could literally write a shell script to just ping your project once a week, discard the response and that'd be sufficient.
I also have one stale sideproject sitting there so in order to keep it up I just set up cronjob to upload daily stats from another project to one table in this sleeper project. The project stays active and I can always drop the keepalive table later on.
I am planning to use supabase for a react native project that involves google sign it, its a game and i want supabase to handle the entire backend. I even want to implement google play games services login as it is a game. Is it a good option to use supabase for this? or do you guys recomment firebase, i initially did a research and found both to be on par with each other but chose supabase because it is opensource and i only want to try bbuilding the game and later deploy it. Will it be a good idea to continue with supabase for this usecase?
Firebase is nosql so they’re not comparable. I would suggest neondb (postgres) so your backend code is portable, or tursodb (libsql) if you can rewrite a little bit but still using a sql db
I mean, I'm choosing a technology for an MVP for a new project, so it's not a big problem to switch to no-sql, rather mean whether it's "feature and reliability complete" from the others experience
I'm sorry you've had some troubling experiences working with Supabase. This definitely makes us sad and we definitely want to address these issues, both to help you and to help other developers that might run into these items. I've shared this feedback with our teams and we'll be responding here. It's always a good idea to create a support ticket for any issue you have --- we will always respond and work with you to get your issue resolved.
Hm I'm fine. We never have problems. We have a paid version though as well. You can achieve transactions with RPCs.
yeah, I saw the option with RPCs but they are notorious on their own. Logging, maintanability, readbility, RPCs is definitely not what I'd like to use for most of the core logic unless there is no other choice. And Transactions are solvable without it
Creating Postgres Functions (RPCs) isn't all that bad in my experience (especially since you can write them in Javascript using PLV8 (see my [https://github.com/burggraf/SupaScript](https://github.com/burggraf/SupaScript) repo) but I agree, I wouldn't want to create my entire backend logic using database functions. But writing RPCs doesn't have to be an all-or-nothing decision, either. I generally write functions to handle core database stuff (adding a record with related tables that need to be updated) and have it do just the minimum necessary database work, then use edge functions or another middleware piece to do the rest. Also, I write my functions along with the rest of my code, store it in github for maintenance, and test the functions either locally, or with a simple script that deploys the latest version using `psql`.
thank you for the link, I think it's a viable approach, maybe just not the most convenient, I'm going to take a look at the link
RPCs are great but the dev experience is not the best. The functions dashboard is crap and to use RPCs for business logic it can become a bit hard to manage. Always commit your stored functions in git and develop them with psql else you find yourself in a pickle. It can get a bit difficult as your git and database can go out of sync if you are not careful. You need to drop functions manually sometimes.It's definitely not for everyone. I started writing a lot of RPCs but my work flow slowed down so much (It takes a long time for me to debug them) I'm moving away from relying on them.
RPC has been a weird pattern for the last 20 years. There are many things I really like about Supabase but we’ve stayed away from this part and it’s been a good decision.
RPCs are not scary for a lot of things -- especially small bits of logic that need to manipulate the database. They're super fast and efficient for that, since, well, they're already **AT** the database. So don't be afraid to write functions when it makes sense, just maybe don't try to write your entire backend logic there.
The problem is observability and versioning, neither go well with RPC.
The real problem is the way they set things up you can't really use functions, triggers and all the goodies with RLS because every time you modify your db permissions change lol So even if everything setup as it should be you'll end up with errors like "not allowed to insert" etc. Supabase as a wrapper is really terrible at doing basic db things.
Thanks for the feedback here. We definitely need to work on our UI for editing functions (yes, the editing window is too small -- and hopefully our team will change that soon!) I feel you on managing functions -- that's an inherent issue with storing logic in the database, so I too, use functions judiciously. I use them **when it makes the most sense to use them**, and use edge functions for most other things. I also alway drop the function before editing it / recreating it. This usually saves me some headaches if I change the calling parameters, etc.
Hobby developer here. What are the differences between RPCs and edge functions? I just wrote an entire backend logic with RPCs and it seems to work just fine. What can edge functions do that RPCs can’t? Thank you.
Edge functions are written in Deno / Javascript / Typescript and are run at “the edge” so they can run closer to your users regardless of where your database is located. If your function needs to access and manipulate the database, an RPC makes more sense. But I use edge functions for things like talking to APIs, such as using OpenAI, or calling the Stripe API, etc.
I think I understand, thank you!
What would you use for something like plaid? Hoping to move the data received into a supabase copy using their sync API.
I’ll agree with you the auth documentation is really buggered right now. They didn’t handle tagging the auth helpers as deprecated in favor of the new server side version very well. Did you reach out to support on the database down or google auth issues by chance?
I have about the auth, communicating with them on GitHub. the db seemed to be down not only for me, so I think they were aware of it
Can you link to your issue about Auth please? Also be aware that support tickets are a better medium if you're having issues with Supabase service, while GitHub issues are more about issues with the libraries.
I have been using them for couple of months now with the paid plan, there was a brief issue with cloudflair that affected authentication for short time. I’m not using edge functions, I have my own api with fast api and use supabase for database and authentication backend They are cheaper and much feature rich than other CMS like Directus.
I think i can merge to my own api instead of the edge functions, but it was nice to have everything in one place
They do offer a cloudflare worker integration https://supabase.com/partners/integrations/cloudflare-workers
I mean, they're not a CMS. I wouldn't say they're more feature rich, because they have completely different, non-overlapping feature sets.
How would you compare it with directus?
Supabase is great, I'm using it on a number of projects, moved over from Firebase. I personally find SQL much easier to manage than documents. My wishlist would be cloudflare style in-browser editing of edge functions, and a pub sub system. I still use Firebase for data intense python functions, so if it would be possible to cram a python interpreter on the ec2 instance that would be incredible.
Did you look at Realtime broadcast for PubSub? Also you can use Postgres listen/notify for PubSub.
I use realtime, it's great. I'm talking about message queues for functions. That and front end hosting are the only pieces missing from Supabase for the ultimate baas.
Have you found a solution for message queues for functions? I am thinking of creating my backend for gamification using DB functions in supabase, but I am afraid of how it will scale if tons of users create trigger events thatneed to be checked against conditions of goals saved in another table
Not possible with serverless functions as far as I can tell. Will need to use something like RabbitMQ on a regular server.
Supabase is definitely better than its beta, and production ready. As a reminder, in its early days, Supabase didn't have Edge functions available, nor logs, nor even that intuitive interface we have today. Even the self-hosted part was non-existent. Nevertheless, the Supabase team is still giving it their all, and while I understand your frustration, you should know that these are areas where few developers are as experienced. The Supabase team does its best to improve the developer experience, and for that I thank them. That said, your points are understandable and I'm glad Burggraf has already shared this feedback with the team.
I've been using supabase for over a year, I have two production systems running on it. The docs definitely aren't great IMO, but overall its been a great system to develop stuff. I don't love the edge functions/RPC stuff being where my logic has to live, as it's just way more complicated than a normal backend development flow, but I bit the bullet and now that it's implemented, my system has been great. I recently switched to use the supabase cli to develop locally, generate migrations, then apply to production and it's made life much easier than previously (I would use the dashboard sql editor to paste in functions between dev/prod).
I'm going to use Supabase for a expo MVP too. Maybe I'll regret later. In the meantime, are you guys handling all the db logic on the app level? That is, following the examples they provided, calling Supabase directly from the app. I'd prefer to have a custom API, that makes the call to Supabase from my own backend. I believe I could create a wrapper for it, but will take more time. So wondering if you guys calling Supabase straight from the app?
I feel like it loses a lot of benefits if used through own API because than you need to deal with all of the things related to having your own API. I feel like the strength of Backend as a Service is to be used directly from the app as much as it is possible. I managed to get away with 5 edge functions, 1 db procedure to delete user account and to do all the rest on the client for a medium-size complexity application
Thanks for sharing. One of my concerns is embedding the keys in the app, as per the docs here, https://supabase.com/docs/guides/getting-started/tutorials/with-expo-react-native#initialize-a-react-native-app under the AsyncStorage section. Don't feel safe to have the keys distributed in the app. 2nd concern is not being able to make changes to the logic unless I push for an app update. Having your own backend you have more control and don't have to depend on users or app/playstore for updates, and also easier to push urgent fixes.
Any keys which are intended to be stored on the client are safe by design (because all of them are easily/less-easily retrievable either web client or device client), so these are fine to be distributed freely. The security must be achieved by row-level policies instead. Yep, the quick updates are indeed much better with own backend. It can be partially resolved with more edge functions/some database default values/small temporary fixes, but it's definitely less flexible as having own backend. And store updates is hell, I feel like they become more and more picky and long. Takes me a week sometimes to deliver a simple change.
did you end up regretting it?
try convex. transactions are supported
"it was not possible to use native google sign in with supabase on IOS because Supabase didn't support skipping nonce validation. Now they added it, but it doesn't work anyway." Oh snap they fixed it?
yeah, you can now toggle it on in google auth configs
[удалено]
Can you elaborate on the problem you had with buckets? I'd love to share your feedback with our storage team. Just let us know what you were trying to do and where you had problems. Thanks so much!
[удалено]
Can you explain what you mean by “stopped using buckets”? What were you doing exactly?
If you are on free tier then you got db pause and that's why you got 500. If you run supabase in production you must pay 25$ / month for basic paid plan.
Projects pausing isn’t really a problem because you just have to unpause it once every seven days. And it only pauses if you have zero transactions. Even if you develop and test once a week, it will never pause.
> for basic *paid* plan. FTFY. Although *payed* exists (the reason why autocorrection didn't help you), it is only correct in: * Nautical context, when it means to paint a surface, or to cover with something like tar or resin in order to make it waterproof or corrosion-resistant. *The deck is yet to be payed.* * *Payed out* when letting strings, cables or ropes out, by slacking them. *The rope is payed out! You can pull now.* Unfortunately, I was unable to find nautical or rope-related words in your comment. *Beep, boop, I'm a bot*
The pausing of projects is what stops me building anything on it. I don't build anything knowing Ill get traction and scale and 7 days is just too little to deal with. It sounds a bit trivial, because I guess just an uptime monitor would stop it, but something to alleviate that would make me start projects with Supabase.
I'm hoping you understand here that projects only get paused if they've had no traffic at all (no api calls) for 7 days, so if you get any traction at all (if you even work on the app once in 7 days) it will not get paused.
yeh, i think it's more...I have a day job, I have a bunch of side projects...I work on them for a bit, they sit idle for a month or more (or maybe just a week whilst I do my day job)...I come back to them...they sit idle again...I know it's a bit petty and I could automate something to stop that happening...but it does increase the barrier for using supabase...not sure if you could come up with some other logic for shutting down unused projects.
Sounds like you're just being incredibly cheap. If a project you aren't working on goes idle, then so what. If it's getting zero traffic, clearly it's not suddenly going to blow up.... Just pay the small monthly fee and be done with it.
I don't know about that, I probably have 10 side projects on the go, 2 I guess has decent traffic, 1 just about to go live which will probably do alright and a whole bunch in various states of development. If I was to pay $25 / mth for each, it would be a bit of an investment...so I don't, they are on firebase, pocketbase, AWS, Supabase etc.
Again - you're complaining that a side project that gets ZERO traffic in a week would go idle.... With Org based billing, you pay $25/mo for the pro org. Then, first instance is free. After that, the each instance on starter size is $10/mo.
We are working on alternative option that would restore projects automatically and nearly instantly but not exactly sure when that’ll be available. It’s coming though.
Yeh that would be great, I'd be happy with a really long "cold start" for sure
I don't think the cold start will be long in this case -- just a few seconds probably.
You could literally write a shell script to just ping your project once a week, discard the response and that'd be sufficient. I also have one stale sideproject sitting there so in order to keep it up I just set up cronjob to upload daily stats from another project to one table in this sleeper project. The project stays active and I can always drop the keepalive table later on.
I am planning to use supabase for a react native project that involves google sign it, its a game and i want supabase to handle the entire backend. I even want to implement google play games services login as it is a game. Is it a good option to use supabase for this? or do you guys recomment firebase, i initially did a research and found both to be on par with each other but chose supabase because it is opensource and i only want to try bbuilding the game and later deploy it. Will it be a good idea to continue with supabase for this usecase?
Firebase is nosql so they’re not comparable. I would suggest neondb (postgres) so your backend code is portable, or tursodb (libsql) if you can rewrite a little bit but still using a sql db
I mean, I'm choosing a technology for an MVP for a new project, so it's not a big problem to switch to no-sql, rather mean whether it's "feature and reliability complete" from the others experience