The user is inquiring about the introduction of UUI7 in Supabase, which is reportedly available only in Postgres v18. They are seeking information on when Postgres v18 or UUI7 will be supported by Supabase.
The user is asking if it's possible to log into different Supabase accounts on different repositories using the Supabase CLI. They mention the inconvenience of constantly logging out and in, and note that they couldn't find relevant information in the CLI documentation.
The user is trying to add an 'is_admin' key to the JWT returned from Supabase auth by following the official documentation. However, after implementing the code, the 'is_admin' key is not present in the JWT when signing in with email and password.
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
Thanks. At the end, I chose the path of least resistance. I am now just running SQL directly on a server component. Makes my life much easier than having to go through Google Sheets or any other tool
Thanks. I just looked into it again. Look like the 🌐 icon doesn't appear unless I refresh the page after running that GRANT statement. so that's okay. Regarding the no Save button on Data API > Settings, that issue is still there. I see it fine on Supabase.com but in local, I dont see any Save button. - Local v2.107.0 no Save button appears: https://ibb.co/7Nx4b7PN - Supabase.com all looks good: https://ibb.co/Dg5CfM6h I just made a new local instance and ran only 1 migration (below) and the issue with the save button not appearing persists. Also, it's not clear what that Save really does behind the scene. Does it just ran the GRANT statement on the selected table(s)? My demo migration: ``` create table public.test ( id integer generated by default as identity not null, created_at timestamp with time zone not null default now(), constraint test_pkey primary key (id) ) TABLESPACE pg_default; alter table test enable row level security; ``` > file a support ticket from your dashboard I couldn't figure out how to do this in local
I agree. Most people tend to overthink things
I don’t see what you mean. I thought AI was supposed to read my mind!!
The easiest and cheapest way is to use SMTP. Just enter the details there and it works. For the edge functions, make a secret for each value then use nodemailer and you are good to go.
Is this a bot posting the same question over and over? The same question was posted a few weeks ago
Thank you for sharing, ChatGPT.
Dictionary.com should use this post as an example of “word salad”.
For transactional, just use Resend or SMTP. You can use React Email in your edge function to send out the email automatically: https://react.email/
What do you need to do exactly? When someone is added to your Supabase database, they get added to your newsletter list as well? That’s much easier than you think. What you need: 1. trigger on your auth.users to run an edge function 2. Get an API form your newsletter platform like MailChimp and add it to your edge function secrets 3. Have a function that receives the database data and then sends their info to the newsletter platform’s API to add the user to the list automatically. If you need extra options, you can have a have a profiles table with their name, and another table with marketing permissions so you check if they should be added to the newsletter or no.
There are multiple problems with how people are using AI. The result is bad because the input is bad and the input is bad because the prompter has zero idea how proper backend and frontend separation works. The issue I constantly see is that these AI tools like Lovable include the Supabase project into the vercel project which is a very bad idea. You never mix frontend and backend projects together. That’s why slapping it with another patch or library will not fix it. It’s a bandaid solution. The AI is as good as the prompter’s knowledge of web development.
Thank you. I actually asked about it a few days ago and someone from your team told me about the new server library. I looked into it. It seems well done but I haven’t migrated yet
Great thank you. This seems like a much easier and less convoluted approach than what was introduced a few months so good job 👏 I see it's in beta mode. Is it safe to use on a production project or better to wait a few weeks/months for the stable version? Thanks a lot EDIT: is there any way to sandbox a cli version or use two versions at the same time (similar to `nvm` in Node) so that I can test the new system before committing to it?
I watched the video. It looks useful but I doubt I would personally use it since I can already do it manually quickly.
I genuinely don’t understand what is so complex or scary about RLS policies that is causing 10 new RLS inspections tools posted here weekly, 90% just being AI slop.