Did you send a ticket? If you did, can you share the ticket #?
This should give you a good idea on prices: [https://saasprices.net/auth](https://saasprices.net/auth) Disclaimer: (not maintained by me or Supabase or affiliated with us in any manner)
You can check this page for more information: [https://supabase.com/docs/guides/integrations/build-a-supabase-oauth-integration](https://supabase.com/docs/guides/integrations/build-a-supabase-oauth-integration)
We are revamping this program, but the submission should link to a public social media video and once accepted they will get an email with a swag promo code and a link to a form to fill out for Supabase credits.
The screenshot appears to suggest that you are trying to use a direct connection they are IPv6 only. Also, in [my experience](https://github.com/mansueli/Supa-Migrate/blob/main/backup_database.sh?#L14-L21) pg\_dump works better for Supavisor by using the full URL pg_dump "$SUPAVISOR_URL" \ --clean \ --if-exists \ --quote-all-identifiers \ --exclude-table-data 'storage.objects' \ --schema-only --exclude-schema 'extensions|graphql|graphql_public|net|tiger|pgbouncer|vault|realtime|supabase_functions|storage|pg*|information_schema' \ --schema '*' > dump.sql
Does your ISP support IPv6 connections? [https://test-ipv6.com/](https://test-ipv6.com/)
We have two pages: the initial blog post explaining why we designed the new keys: [https://supabase.com/blog/jwt-signing-keys#why-symmetric-jwts-can-be-risky](https://supabase.com/blog/jwt-signing-keys#why-symmetric-jwts-can-be-risky) We also go into more depth into how these secrets work on the following page: [https://supabase.com/docs/guides/auth/signing-keys](https://supabase.com/docs/guides/auth/signing-keys) Quotes from page above: * Using a shared secret can make it more difficult to keep aligned with security compliance frameworks such as SOC2, PCI-DSS, ISO27000, HIPAA, etc. * A shared secret that is in the hands of a malicious actor can be used to impersonate your users, give them access to privileged actions or data.
We don't run Deno, we run a deno-compatibly runtime which is ([open source](https://github.com/supabase/edge-runtime)) in the edge. **I am not a lawyer and you should discuss this with your legal adviser.** But the understanding that I got from several clients is that you can process edge functions in other regions as long as: A) You are using and storing the data in a project in EU; (edge function is processing in transit data) B) You have the DPA signed, so you would be relying on SCC (Standard Contractual Clauses) which are safeguards to be compliant. If you want to ensure that your edge functions also run on the EU, you could even route them through an RPC call: [https://github.com/mansueli/tle/tree/master/pgwebhook#direct-usage](https://github.com/mansueli/tle/tree/master/pgwebhook#direct-usage) Or specify regional invocations: [https://supabase.com/docs/guides/functions/regional-invocation](https://supabase.com/docs/guides/functions/regional-invocation) The only answer that I can give is that you should consult with your lawyer and check which path they consider appropriate here.
If you're planning to use Supabase as a data processor, the key thing for GDPR compliance is not whether Supabase itself is GDPR-certified (it currently isn’t subject to formal GDPR audits like some SaaS are), but whether you can run your app in a GDPR-compliant way using Supabase. And yes, you can. Supabase provides the tools needed for GDPR compliance: European data residency: You can choose an EU region (e.g., eu-west-1 on AWS). Your database and storage stay in Europe unless you explicitly move data elsewhere. Data Processing Agreement (DPA): All Supabase customers ( free or paid) can sign a DPA directly in the dashboard: [https://supabase.com/dashboard/org/\_/documents](https://supabase.com/dashboard/org/_/documents) A DPA is the actual legal requirement for using a third-party service as a data processor under GDPR. Transfer Impact Assessment (TIA): If you need to document US-related transfers under Schrems II, the TIA is also available in the same dashboard location. **GDPR discussions online get confusing because:** Some people talk about Supabase as if it were a consumer SaaS product needing its own GDPR certification (not how B2B processors work). Others misunderstand data transfers involving US cloud providers generally. Some older or anecdotal comments predate Supabase’s DPA and TIA. In practice, GDPR compliance depends on how you configure and operate your app, not just the platform.
If you're planning to use Supabase as a data processor, the key thing for GDPR compliance is not whether Supabase itself is GDPR-certified (it currently isn’t subject to formal GDPR audits like some SaaS are), but whether you can run your app in a GDPR-compliant way using Supabase. And yes, you can. Supabase provides the tools needed for GDPR compliance: European data residency: You can choose an EU region (e.g., eu-west-1 on AWS). Your database and storage stay in Europe unless you explicitly move data elsewhere. Data Processing Agreement (DPA): All Supabase customers ( free or paid) can sign a DPA directly in the dashboard: [https://supabase.com/dashboard/org/\_/documents](https://supabase.com/dashboard/org/_/documents) A DPA is the actual legal requirement for using a third-party service as a data processor under GDPR. Transfer Impact Assessment (TIA): If you need to document US-related transfers under Schrems II, the TIA is also available in the same dashboard location. **GDPR discussions online get confusing because:** Some people talk about Supabase as if it were a consumer SaaS product needing its own GDPR certification (not how B2B processors work). Others misunderstand data transfers involving US cloud providers generally. Some older or anecdotal comments predate Supabase’s DPA and TIA. In practice, GDPR compliance depends on how you configure and operate your app, not just the platform.
You can start with the [index advisor](https://supabase.com/docs/guides/database/extensions/index_advisor), then also use the [inspect commands](https://supabase.com/docs/guides/database/inspect#inspection-commands) for a more hollistic view. Then, if everything looks fine in the [performance advisor](https://supabase.com/dashboard/project/_/advisors/performance) (no errors or warnings). Then you need to start going for the EXPLAIN ANALYZE to investigate it further (which you can also call from the client libraries).
Branching is creating a new project and pushing the schema changes there. You can already do self-hosted branching. You will them pass the \`--db-url\` when calling the commands: [https://supabase.com/docs/reference/cli/supabase-db-pull](https://supabase.com/docs/reference/cli/supabase-db-pull)
We do have it in the docs, but sometimes people are unable to find it 🫤 [https://supabase.com/docs/guides/api/securing-your-api#disable-the-api-or-restrict-to-custom-schema](https://supabase.com/docs/guides/api/securing-your-api#disable-the-api-or-restrict-to-custom-schema) Maybe we could also add something about it in other pages. Where did you look?
I've updated with the new link.
Yes. But better safe than sorry IMHO. If you are not using it, disabling makes a lot of sense.
Can you explain with more details what you are running and what is your goal? Do you want to skip the seed or not? I am sorry, but it isn't very clear on your post.
No, as long as you disable the Data API, you should be fine. [https://supabase.com/dashboard/project/\_/settings/api](https://supabase.com/dashboard/project/_/settings/api) If you don't disable it, then you NEED to enforce RLS policies (even if you don't create any policies). Otherwise, anyone that figures your supabase URL could do some serious damage.
Were you using Realtime with broadcast from the DB or postgres changes? (The former is more scalable) Now, getting back to your questions: > 1. Do Edge Functions support WebSocket protocol, or are they HTTP-only? Yes, they do [support websockets](https://supabase.com/docs/guides/functions/websockets). > If not, what's the recommended architecture for scaling beyond Realtime's limits? You can also disable the [spend cap](https://supabase.com/dashboard/org/_/billing) on a pro project which will bump your [Realtime limits](https://supabase.com/docs/guides/realtime/quotas) for up to 10,000 connections. > Should I just spin up a separate WebSocket server (Node.js/Deno) and use Supabase only for database/auth? That's also an option, but you probably don't *need* to do this unless you have an specific reason for it.