igormiazek

It is good you are trying to build an app with PDD and vibecoding, but at different levels you will hit wall due to lack of information. Your app will be as good as context you provide and this is coming from your knowledge and experience. Reach me on DM, I can share with you my guidebook, it's free. I will not solve all of your problems but it will make you more aware about how RLS works, you need to understand that in order to capture the mistakes that AI is doing and being human in the loop.

Nice to read smart words. I agree with you context is everything, less you know about architecture, infrastructure, fronted-backend interactions, auth and authorization more prone to problems your app will be. Although PDD prompt driven development has it's place, for PoC and MVPs, internal organizations but only if have strong IT department that can lay down an excellent foundation for them to use it, so they don't care about security, auth, streaming, storage, so they focus only on problem solving.

You are on free plan? Maybe you went above usage that is available in your plan?

Hi <@1503209765596041216> i am interested. Here more Information about me https://www.linkedin.com/in/igormiazek/, will send DM.

Service role key can bypass RLS, you use it by backend services that execute business logic asynchroniously, so not directly when user action is executed in synchronious way but latter, for example in Edge Functions or in your Backend Service or Worker.

looks like schema mismatch

<@1295560294894145651> are you sure that the backup you used to restore database had all migrations applied? From what you wrote seems that your application has more business logic included than database schema has?

I know it doesn't change anything <@1452654900680069272>, in Poland we say "mądry po szkodzie" which translate directly smart after accident. Think about adding additional backup process that will store your db in other location too like in aws s3 or gcp storage in addition to what Supabase enable.

that's should happen during build process

What is the difference between local and and test flight build? You are using exactly same build?

Reviewing it, I DMed you as well, if you would like to share more details related to the whole code base.

<@252453382306922496> do you have maybe a sequence diagram showing user interactions with your products (FE, BE) with indication where refreshing of the session is happening? Will help to identify the problem with auth flows implementation. If you are using AI tool that has access to your code base like Cursor you could try to generate it with a tool.

Have you checked this https://developers.cloudflare.com/turnstile/get-started/mobile-implementation/#react-native-webview ?

As the problem is random and not reproducible easily, I think the only way to go is to add logs in all places so you can track all actions related to authentication after the problem is reported to you by end user.

<@680995995152154710> and you checked logs in Azure related to authentication, those were correct and auth was done for right user? Gary provided interesting github issue related to caching, are you using a caching layer? Have you checked auth tables, have you found anything wrong about users that experienced an issue?

I assume you don't have direct urls with db password to connect to database? Always worth asking, if you have such access you could try to extract data through url and restore your Supabase project as new project.

What is the exact problem you experience? API is not working?

If well designed, using modules which encapsulate subdomain and business logic, using private schemas to isolate module data, when you observe that specific module or subdomain (I refer to Domain Driven Design by Eric Evans) you can deploy concrete part of your system as "Do you have a separate backend (Node.js, NestJS, etc.) that talks to Supabase/Postgres?" so in my opinion that's natural evolution. Complex queries maybe result of BaaS Backend as a Service, Supabase move a lot of complexity into database directly, so people start putting there everything which make things slow. But then it really depends on your queries, if right indexes were applied, maybe you need partitioning? If remember correctly Discord which has large traffic started with MongoDB and after moved to PostgreSQL which had better results, at the end I think they ended with CassandraDB or ScyllaDB, but still PostgreSQL can manage a lot.

Why not using Supabase branching?

I would clean it up unless there is a purpose of keeping them? Normally you would keep TestFlight user because when new feature is delivered, you want to test on fresh users but as well old users to see if nothing broke.

About branching "A Supabase branch is essentially a copy of your Supabase project, minus the data. Rather than making risky changes to your production database, edge functions or configuration, **you instead spin up a preview branch and make the changes there**. This gives you a safe, isolated environment to work from." [https://supabase.com/docs/guides/deployment/branching](https://supabase.com/docs/guides/deployment/branching) So branching meet your purpose perfectly. What you are missing only is: 1. Creating a logic that takes your production data. 2. Remove confidential information or and Apply masking or anonymization Go with branching and create your seed logic. A question is why you need production copy as you haven't explained? If you afraid of breaking something, review your change, I mean the code before it goes into production.

That's the role of seeding logic, each environment must be clean, normally you want to have it empty. If production data is needed it needs to be anonymized properly first.

Are you on free plan? If project is not used and in free plan it will go into pause mode after some time of not activity.

you can generate a mcp url that is limited to read only, concrete project and predefined permissions like this one https://mcp.supabase.com/mcp?project_ref=your-supabase-project-id&read_only=true&features=database%2Caccount

Hi Ori, if you want to limit the scope of what is exposed, this is the way to go https://supabase.com/docs/guides/ai-tools/mcp#step-1-follow-our-security-best-practices

<@1513257627843297470> It is fully up to Lovable what you can move out, because they own the supabase project if you haven't used your own supabase account. Have you explored your lovable code base? Maybe you have there schema definition and edge functions logic? I worked a bit with lovable but don't remember if supabase schema and edge functions logic is included into a code base.

Hi it is a community forum not supabase support. In order to get some help you need to provide more details it is hard to tell what is wrong based on your message.

Hi Guys, I wrote an article that may help https://igormiazek.substack.com/p/from-one-supabase-app-to-ten-when it is my perspective as architect on how to get most of Supabase. Most of the people select Supabase because it accelerate development. When you think in terms of speed, security and long-term architecture is not something you want to address at day 0. It rather comes a bit latter when you grow and have first paying customers. In order to achieve multi-tenancy + platform architecture, you need to go with extra tables for tenants management and preferably dedicated subdomains (tenantA.mydomain). If you go this way, when user is authenticated it see organizations or tenants to which he belong. This doesn't come by default with Supabase but with good db schema design it is doable and not bad database design at all. As it goes about platform architecture, I believe best option is with leveraging private schema per module to achieve strong isolation between domain layer services. What do you think about this approach?

Try to ask Lovable if the allow to https://supabase.com/docs/guides/platform/project-transfer they you could move it to your organization. If not you need to do things manually, create a backup, but not sure if you will be able to migrate everything.

If you haven't done it with project transfer https://supabase.com/docs/guides/platform/project-transfer and deleted already the original source project, you maybe not able to restore it.

[https://playwright.dev/](https://playwright.dev/) is a framework to create end to end tests, but it support API testing too. [https://www.artillery.io/](https://www.artillery.io/) is a framework to execute performance tests. Both can be used together. Personally, yes, but how strong it will be is up to you, test case is something you need to write, if you write good strong test cases you will have strong protection, if you write weak bad test cases you have minimal or no protection at all.

It apply to all projects that are successful I would say, because as soon you start growing and you see demand on your product, you start to make it better and provide more services over time right? It happens I have experience as solutions architect and for me that's very natural when I design systems, I start from data modeling and group data models into sub-domains. From such a diagram I see already at a very early stage which models can be fully isolated and which will be reused between sub-domains. Of course some data models like Customer will have data in multiple domains. To be more precise in DDD Domain Driven Design we talk about domain and sub-domains. But for the consistency of my post and comments that were added let's stay with Domains. So Customer will have data in Sales/Leads Management domain and in Product Catalogue/E-Commerce domain, but it is not data duplication it;s only a different domain, totally different business context but the same data ownership, the same customer. App belongs to application layer - unique user experience Module or Domain Service belongs to domain layer - reusable domain logic, business logic. When app is created with Supabase nobody thinks about that because Supabase make things so fast. Clients I worked with always went the same way, first app, second app, good feedback from users and a growth, more apps, more apps. At some point managing all of those apps is hard, because you don't have foundation that could be reused, and I am not referring to Supabase features, I am refering to your problem domain services that will be treated as core building blocks. With the post I wanted to say, that if you have 10 apps that belongs to the same problem domain, they all have the same business and user context,, solve problems from the same problem domain. Then without a platform which is consumed by those apps you will encounter issues in further development, maintenance and management. If you don't define platform sharable layer, you end with building 10 fragmented apps, which have nothing to share beside Supabase internals if each of it is a separate Supabase project.

The best way, in my opinion, is to write automated tests that intentionally try to break your tenant isolation. Don't just test the expected access paths, test cross-tenant access attempts and make sure they fail. That tends to catch issues much earlier than manual testing or spot-checking policies. A matter of selecting framework and running those each time you change something. Of course manual tests and all the things you mentioned are good but without automation you cannot properly test the security aspects. This will be as strong as the test cases you created, weak basic and happy path test cases, bad tests, strong advance testing, edge case scenarios that will give you good protection. I recommend Playwright + Artillery, those 2 work together, So after writing tests you can reuse them to check if your project is able to handle a specific amount of users, heavy load tests.

but no 403

I was not checking other requests but this one after removing hubs give me empty list with some random data

you don't have hubs column

https://dcmagmncrdwhklvffxvm.supabase.co/rest/v1/organizations?id=eq.dfgdfg&select=id,name,sector,country,active,primary_color,logo_url,field_labels,custom_activity_types,hubs

the original one has hubs or hub in request

curl 'https://dcmagmncrdwhklvffxvm.supabase.co/rest/v1/organizations?id=eq.gtttghjghj&select=id,name,sector,country,active,primary_color,logo_url,field_labels,custom_activity_types' \ -H 'User-Agent: [removed]' \ -H 'Accept: */*' \ -H 'Accept-Language: en-US,en;q=0.9' \ -H 'Accept-Encoding: gzip, deflate, br, zstd' \ -H 'Referer: https://tailaaxiom.com/' \ -H 'apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImRjbWFnbW5jcmR3aGtsdmZmeHZtIiwicm9sZSI6ImFub24iLCJpYXQiOjE3ODA0OTYxMTUsImV4cCI6MjA5NjA3MjExNX0.2h0T2HdhUiqrljAlIUwx5aX-jnk78Uz2hxZlYYYS6uo' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImRjbWFnbW5jcmR3aGtsdmZmeHZtIiwicm9sZSI6ImFub24iLCJpYXQiOjE3ODA0OTYxMTUsImV4cCI6MjA5NjA3MjExNX0.2h0T2HdhUiqrljAlIUwx5aX-jnk78Uz2hxZlYYYS6uo' \ -H 'Content-Type: application/json' \ -H 'Prefer: return=representation' \ -H 'Origin: https://tailaaxiom.com' \ -H 'Connection: keep-alive' \ -H 'Sec-Fetch-Dest: empty' \ -H 'Sec-Fetch-Mode: cors' \ -H 'Sec-Fetch-Site: cross-site'

Fell free to DM me if you prefer private discussion or provide more details here.

Hi <@1513224163182121087> could you confirm: 1. What IP network restrictions you have defined in your project? 2. Have you already repaired it? I see that public Data API calls to your tables works, I just copied cURL from browser requests and it works totally fine. Although there is some issue with database schema, the api requests that is executed after the form is filled with data on the website you provided, when this is done the first error is related to not existing columns

Exactly Data API automatically generate for you endpoints to tables, sometimes you need simple full CRUD without any extra business logic on top of that, and with Supabase you have this out of the box. In Supabase ecosystem it accelerate apps development, you create tables that have REST api out of the box and you can start consuming those without writing a single line of code.

Yes, in my opinion the best architectural approach is to use Data API and actually treat that as a service. Doing SQL between schemas should be only acceptable for analytical, data warehouse purposes. From my experience u/bjl218 , all migration tools work in a similar way. They verify that the migration history in the codebase matches the state of the database. Migrations form a chain, and you generally can't have multiple independent migration chains that are unaware of each other while targeting the same database. That's why I'm curious: what are the main reasons your team is against using a monorepo? An alternative could be to have a dedicated repository for the shared platform/database layer. That repository would own the migrations and any shared code, while the application repositories remain separate. I think a monorepo can work well because it provides a single place for migrations, while still allowing database models, services, and business logic to remain organized by application or module. This can actually make data ownership more explicit, since each app's domain is clearly separated, but all schema changes still go through a single migration history. I DMed you too, if you would like to go deeper into this topic.

Hi <@1484650249774694480> , I have extensive experience building SaaS platforms on Supabase, including Auth, RLS, OAuth integrations, security audits, and multi-application architectures sharing the same backend and data model. Regarding Allegro, I have worked on integrations in construction and e-commerce domains where ERP systems automatically created and updated Allegro offers, with two-way synchronization of products, inventory, and orders. I also built ETL and synchronization pipelines using Supabase Edge Functions to integrate external systems and keep data consistent across platforms. From a security perspective, I treat OAuth tokens as secrets and store them encrypted (e.g. Supabase Vault), with server-side refresh flows and backend-only access. Reviews: https://clutch.co/profile/techs#reviews Feel free to schedule a call: https://calendly.com/igor-miazek/30min Best, Igor Sent you a DM.

Using separate Supabase schemas is a good patter to isolate sub-domains and give ownership of sub-domain and underlying data model to concrete service or module. So if you have well defined data model it is a good way to go, but be careful with schema joins it may indicate not good data model design.

You shouldn't do cross-schema joins, unless this is only for analytical, BI purposes, but apps shouldn't do it. I will copy past my answer for second point from your previous comment/post because I think it is relevant. Original comment is here [https://www.reddit.com/r/Supabase/comments/1tsuywe/comment/oq2l3l6/?utm\_source=share&amp;utm\_medium=web3x&amp;utm\_name=web3xcss&amp;utm\_term=1&amp;utm\_content=share\_button](https://www.reddit.com/r/Supabase/comments/1tsuywe/comment/oq2l3l6/?utm_source=share&amp;utm_medium=web3x&amp;utm_name=web3xcss&amp;utm_term=1&amp;utm_content=share_button) If you need joins after isolating tables with database schema it could indicate: 1. Some tables you isolated from each other shouldn't be actually isolated, are to tightly coupled in the context of problem domain and business model. Based on my experience, if you would like to make use of microservices based architecture pattern. You need to define a layer where you have problem domain services, not application services. Those services can be consumed directly by other microservices or apps, it could be a generic purpose CRM microservice or mcroservice that is responsible for group chats and video stream. Those services are your system core building blocks. Next on top of that you can create frontend/client/consumer apps and dedicated application services. I think Netflix had a good article about that. Each application may need a different user experience, maybe the data need to be transformed or aggregated in a different way. The core question to answer when new app is added is about which part of this app is app specific and which should go to a core layer with problem domain services. If you would provide video stream services like Netflix, you would like to maintain a stable core layer which would enable you building variety of apps where sometimes those apps may provide totally different experience. Dividing data into separate schemas is a good and healthy pattern, you isolate different part of the systems. But you need to be sure you know why, you separate them not in order to create separate apps, you separate them because each part of your system maybe become in future an independent system component and have full ownership over single sub-domain.

u/bjl218 I think that doing joins between schemas is not something you should do. If you need joins after isolating tables with database schema it could indicate: 1. Some tables you isolated from each other shouldn't be actually isolated, are to tightly coupled in the context of problem domain and business model. Based on my experience, if you would like to make use of microservices based architecture pattern. You need to define a layer where you have problem domain services, not application services. Those services can be consumed directly by other microservices or apps, it could be a generic purpose CRM microservice or mcroservice that is responsible for group chats and video stream. Those services are your system core building blocks. Next on top of that you can create frontend/client/consumer apps and dedicated application services. I think Netflix had a good article about that. Each application may need a different user experience, maybe the data need to be transformed or aggregated in a different way. The core question to answer when new app is added is about which part of this app is app specific and which should go to a core layer with problem domain services. If you would provide video stream services like Netflix, you would like to maintain a stable core layer which would enable you building variety of apps where sometimes those apps may provide totally different experience. Dividing data into separate schemas is a good and healthy pattern, you isolate different part of the systems. But you need to be sure you know why, you separate them not in order to create separate apps, you separate them because each part of your system maybe become in future an independent system component and have full ownership over single sub-domain.

u/filibustermonkey I see more and more builders arrives to a similar conclusion, especially those managing multiple applications. Over time, they realize that a shared foundation is needed a platform that provides common capabilities across all apps. I like your idea of using separate schemas per module. It's an interesting approach because it preserves boundaries while keeping everything under one roof. If designed well, it also gives you flexibility to evolve the architecture later. For example, domain-specific modules could eventually be moved to their own infrastructure, while shared platform services such as Supabase Auth, billing, and user management remain centralized.

No problem. Do you have a separate backend layer responsible for problem domain or you fully depend on Supabase Data API + NextJS(or something similar)?

The best way to approach is to follow Domain Driven Design principles (Eric Evans, recommend to read to anybody who think about future of their software). Supabase simplified many things so people don't need to think too much about architecture which is good in some aspects as you can quickly create an app, and for problem solvers that the ideal scenario. But in enterprise large systems, different system components have responsibilities and data ownership. My personal recommendation is to start from monolith-first-approach with modular code structure. As soon as you see that specific module grows a lot and it's usage is extreme, you should take it out from monolith and run as independent system component for example with separate database or separate database server. This is possible when you think first: problem domain, business context, user context. Based on this simple analysis you will come out with subdomains which divide your main problem domains on smaller chunks. And know the most important part, your code needs to follow and obey this structure, only then you system will evolve together with your business. Your approach is not bad, I mean the section with Edit. But make sure that your code is modular and the data tables which are owned by the module are not accessible by other modules, that is giving you full decoupling. As well no SQL joins between data models that belong to separate modules, you need to think about them as separated silos-es that in the future may run on it's own. Single responsibility principle.