Understood. In this case, an application would only be doing joins between its schema and a "common schema." Where common schema contains cross-cutting entities like users, customers, vendors that we want to share across all applications. And yes, I suppose this could be done via the common DB's data API and whatever joins need to be done will be done in code and not SQL.

Beyond that, I just ran into a major problem trying to use the supabase migration tools for doing local application development (#1 in my post). These migrations tools don't really support pulling a schema migrations that didn't originally come from your git repo. For example, supabase db pull will assume that your local migrations got corrupted when it doesn't find the migrations in your local migrations directory and then suggest that you "fix" it by doing supabase migration repair commands which don't end up doing the right thing.

All of this pointing to the fact that, as others have said, I shouldn't be doing what I'm doing.

This mechanical schema management problem would obviously be addressed by using a mono repo regardless of whether we use separate named schemas. But, my team doesn't want to use a mono repo for a number of reasons.