ashkanahmadi

Oh that makes sense and super clear. I’ll definitely implement that. Thanks a lot

Interesting. Just out of curiosity can you tell me how this is done?

I’m more baffled by why SO MANY PEOPLE are confused by RLS than anything else. What is so difficult about RLS that causes so many people posting about it and creating tools for it every day? Genuinely curious

Thanks. Makes sense. Then I suppose I need to do it the “Easter egg” way like tapping a specific icon to get to a hidden screen that Apple can get to with an email and password form so they can login like that and then use the rest of the app? Because I suppose they need to do this with every new build submission so it’s not easy to rely on OTP.

Cool thank you. Never really looked in the Logs in details before (I know I should).

Thanks for sharing. Where do you see the request history? Under Logs?

I don’t think there is an official Supabase PHP SDK but the SDK does just API calls so in theory, it should be easy to create functions that make the same API calls to check if the user is authenticated or no

Oh didn’t know that. Thanks

This usually isn’t Supabase but AWS (not just now but a lot of the issues come from AWS). Most providers now also use AWS unless you want to self host.

You are missing a major point. You have 10 users. How many tables? I’m running a production project with thousands of users, about 30 tables, thousands of rows, with cron job, lots of edge functions, and triggers feeding a mobile app and a custom built dashboard all while communicating with Stripe all and all on the free plan. If you have 10-20 users and you are already thinking about specs, either you are severely trying to optimize prematurely for a problem that isn’t there or you didn’t set up the database properly if you already notice query load.

How is what you are saying related to the title of your post?! Everything you are talking about is easily fixable but using a clickbait title just to get reaction will not work well for you.

Just sent you a message.

I built something very similar last year and I’m still maintaining it. The only difference is that eveverythi you mentioned is on an iOS app but I use Next for the panel to manage everything. I used Supabase for everything: well defined and structured tables with clear normalization, Supabase edge functions for complex things like creating orders, payment intents, and webhook. Next js is used for creating products, orders, user management, etc. It involves events (everything you mentioned like upcoming events, an event having multiple tickets like free and paid, QR scanner, buying other merch, etc). For payment I use Stripe React Native but you can use Stripe Checkout Sessions, it’s a piece of cake working with it. You also need a Stripe webhook to receive the notifications to update your database. Overall, it’s excellent, works flawlessly like a Swiss watch, and I can help you with it if you have any questions.

That's very manageable. Unfortunately, Supabase pushes for convenience in their guides and tutorials instead of long term maintainability and reliability. That's why I dont recommend using schemas. You need to do everything properly through migration files. You never ever modify the database structure or core data by running SQL in the editor. You run migration files to do that so that you have access to the history of changes. What I recommend: Give Claude your schema and ask it to read it and break it into smaller topic-specific migration files. If you need help with that let me know so I can tell you how I keep my local, staging and production projects in sync

Yes everything in the database will be wiped out. The auth will be cleared too since it comes from the auth.users table. As far as I remember, the edge functions and storage will not reset (the storage table in the database will be wiped though). How many tables do you have? Based on that, I could recommend you a clear workflow so you don’t have to mess with the schema

Ah then in that case, you can use “Supabase db reset —linked” to completely nuke the remote database and reset it from scratch. Thats what I do from time to time in local and staging projects but obviously, never in the production project. Never had issues. That might help you too

That’s why I hate it when people recommend using schemas. They always lead to bugs and misbehaviors. Always use migration files, never schemas.

The Supabase JS sdk is just a fancy fetch request and every fetch request can be a curl request. If you use the Supabase library without the “await” you can see the URL it hits to perform something. My point is that you cannot stop curl without stopping the JS sdk from working properly.

500 a month? Definitely you are being taken advantage of. You are host Supabase on any VPSfor less than 10 bucks a month. You can rent out a server for that amount per month. This isn’t just a Supabase thing but web hosting as a whole so i recommend you post what you exactly so people can help you here.

I’ve been using it for over a year and never had a single issue that people talk about. You see posts with issues because people with no issues wouldn’t post “today the dashboard worked as usual”.

Why would you care if you are changing someone else’s row in an UPDATE? Are you guys testing things in production?!!!!!

I write the policy myself. Not by asking the AI. Then I explain the business logic to the AI and feed it the policies to review. Then ask it to come up with as many scenarios to test. I also brainstorm a lot and test manually using curl or an HTTP client.

You need to know the basics. Start with these (google them or watch a tutorial or ask LLMs) \- table normalization (very important) \- migration files (also very important) \- basic SQL like how to select, insert and update \- triggers and functions \- role-level access (granting or revoking access per role) \- RLS and the difference between role-level access and RLS

No. I have 2 different projects. One for testing and staging while lots of dummy data. Then the production real database. I use “supabase link” to switch between them. When I’m done with all tests in dev, I run the migration files linking to the staging. When that’s all good, I unlink and link to production and push the changes and unlink immediately. No branching needed.

Ah then if I understood it right: you have another api key that you don’t users to see. It depends how/where you use that api key. If you use it on the frontend like sending a fetch request, potentially, the users can see that api key. If you really really really don’t want an api key to be visible by any user, then it needs to be done through an Edge Function or a Next API route, or some other server endpoint since it must run on the server (and not on the client) so it’s not exposed. If you tell me what tech stack you are using, I can tell you how to do it in an easy, manageable and secure way

Before anything else or touching Supabase, you need to learn the basics: what is an RLS and how to grant/revoke access with different roles `anon` and `authenticated` and `service_role`, how to organize your database so you can tell how many tables you need, etc. > don’t want to expose my api key You dont have a choice. The publishable API key is public and accessible by everyone. It's totally safe to have it exposed. It's like the lock on your house door. it's okay for people to see there is a lock as long as your lock requires a strong key (which should be your role access and then RLS).

Looks very nice. No way to deploy Supabase at the moment, correct?

Hi again. Thanks. What would be the safest way of updating my Edge Functions? I'm still on CLI 2.62.10 with `Deno.serve` type of functions. If I upgrade my CLI to the latest version, then update my Edge Functions to follow the new `supabase/server` structure with `withSupabase`, that would be enough before pushing them to remote? Thanks

It clearly says ChatGPT also that looks sketchy af. You sure you didn’t download some virus or suspicious file? This has nothing to do with Supabase

This is what happens when people with no experience think they are suddenly experts just because they managed to get a basic project off the ground with 5 prompts. Tips and help are always welcome but I genuinely don’t understand peoples problem with RLS and such rudimentary issues. That’s even if these posts aren’t bots

You can't do it simply because the `auth` REST API endpoint is always exposed. The SDK doesn't do anything itself. It just translates your code into a regular `fetch` automatically attaching the user's JWT along to be validated. You can always hit the REST API directly to perform something without needing the SDK like this: confirm OTP:: ``` curl --request POST \ --url SUPABASE_URL/auth/v1/verify \ --header 'Content-Type: application/json' \ --header 'apiKey: {{supabase_publishable_key}}' \ --data '{ "email": "email-to-confirm-here@test.com", "token": "123456", "type": "email" }' ``` or change password: ``` curl --request PUT \ --url SUPABASE_URL/auth/v1/user \ --header 'Authorization: Bearer {{supabase_authenticated_user_jwt}}' \ --header 'Content-Type: application/json' \ --header 'apiKey: {{supabase_publishable_key}}' \ --data '{ "password": "Password123!@#" }' ```

There are a few different ways to approach this. Two good starting points for you: 1. Use HTTP client To rule out UI or any data processing, you need to fetch the data directly from the Supabase's API using cURL (hard) or HTTP client (easy). Since you are using VSCode, look up the extension `rangav.vscode-thunder-client` and install it. You can use it to send a REST API request directly to Supabase and see how long it takes to respond (if you dont know how to do that, feel free to let me know I can help you with it). If it takes something like 300ms (0.3 seconds) to load, then it's okay. If it takes 2 seconds, then move on to the next step. 2. Use `EXPLAIN ANALYZE` Use Supabase's SQL Editor page to run your SQL command starting with `EXPLAIN ANALYZE ...`. For example, if you want to select all the rows in the table `items`, you would do `SELECT * from items`. But with `EXPLAIN ANALYZE ` in the beginning, Postgres tells you how long it took to run this query. If you see Execution time as something like 0.5 ms (less than a thousandth of a second) but in your app it takes 2 seconds, then it's not Supabase but your app. That should put you in the right direction. If you need extra, let me know

I use Supabase for a website and app with lots of traffic and never noticed any delay. You sure you don’t have badly structured database?

Do not connect anything to production db especially if you don’t know much about code because you can’t really notice anything weird if there is anything (which is commonly done by AI) Supabase isn’t slow but idk what you mean by slow. Also, how slow is slow? To find out if a service is slow, you need to have the exact same specs and data, then query the exact same thing over 100k times to get their average to see if its overall slow or if there are anomalies. Unless you are talking about millions and millions of rows, you won’t notice anything weird difference. What CAN make any service slow is bad (or lack of) database normalization, unnecessary indexes on everything, lots of triggers and functions, etc.

Just out of curiosity, what was the challenge with that? I’ve been doing that for a year now with my production projects and I’ve never had any issues

I don’t do that. When I create a new table, the RLS and views and index and grants and triggers all go in the same file. If I need to change something later, I just make a new migration file just for that. Like this it’s more organized and I can see the flow of the changes easily.

RLS is much easier that people think. It's literally a fancy `if` statement. I always follow these steps in this order in my migration files: 1. Create table 2. Handle permissions to each role since the Data API change in Supabase (the least amount of permission to get started - better to have restrictive policies than loose ones). 3. Enable RLS 4. Handle RLS (who needs to see what exactly)? Before writing anything, you need to write in plain language: - Who can see what? - Who can insert what? - Who can update what? - Who can delete what? Once you have that, you just do the RLS accordingly. I have clear documentation in my `.sql` migration files. I also feed it into ChatGPT to review it just as another pair of "eyes" just in case I missed something. I see so many posts about RLS like it's some complex issue. If your RLS can get really really complex, then you shouldn't rely on RLS solely but on a custom Edge Function or some external API to handle the request.

Hi Ali. This is to confirm that I have now installed v2.109.0 and I do see the Save button now and it’s working correctly. Thanks a lot

Interesting. Can you share more info like examples of what is not easy to replicate and what your script does exactly?

Good 👍 remember that Supabase is just a cohesive compilation of different tools you can use individually like Postgres so when you see tables and rows and RLS, those aren’t Supabase. Those are just Postgres so it’s best to learn the basics of Postgres and SQL in general. Become familiar with the core concept like “normalization” which is very important in relational databases.

> I’ve been reviewing a bunch of public Next.js/Supabase repos recently Who is having their projects and database structure public for everyone to see?!!!!

Unless you have hundreds of thousands of rows in your tables, you shouldn't worry about disk size or speed or anything else. In general, you want `int` for when you dont mind someone guessing the other `id`s or that you want to keep it a secret. For example, an event is fine to have `int` as id but the bookings or ticket ids should be `uuid`.

I use SiteGround SMTP. no issues

It depends on every case. For example, we have a WordPress hosting with SiteGround so I use the SiteGround SMTP system to send out all emails like auth confirmation, otp, confirmation emails, edge functions,etc. Very reliable overall. For that, DKIM SPF and DMAR Care already set up. If you need a lot of emails sent, use SendGrid. For marketing emails, it should be a separate system like marketing@domain.com sent to a marketing system like MailChimp.

Pretty cool. The UI seems a bit too crowded. You don’t need to have a border around everything. You should post it in r/BitchImATrain to get maximum feedback

Amazing thanks a lot for letting me know