high-roller-all-in78

I would keep one database as the source of truth and avoid cross project table reads unless the boundary is really stable. Using the signed in user token against project A is usually simpler to reason about for permissions, while a service role or foreign data wrapper can get messy fast if both apps start owning business logic. If project B only needs a small predictable slice, I would rather expose that through a small server layer than let both apps reach deep into the same tables.

If both accounts can access the project, I would try the official transfer first because it preserves more than a manual rebuild. If you have to do it by hand, make a checklist for schema, storage buckets, edge functions, auth settings, secrets, cron jobs, and webhooks, then rotate every key after the move so account X truly loses access. The easy thing to miss is not the data dump, it is all the little environment and integration settings around it.

I think you are right that basic login history should exist below the team tier. Short term, I would log auth events yourself through a small table or server side audit trail so you at least know when sign ins happen and from what source. Not as nice as built in account history, but it gives you something real to monitor now.

That count can be higher than people expect because the client may check or refresh the user session on page loads, tab focus changes, and server calls, not just when someone signs in. Regular inserts and updates should not by themselves create a wave of sign in traffic unless your app is reinitializing the client or repeatedly asking who the current user is. I would inspect one page in the network tab and see whether the same session endpoint is firing over and over. That usually shows whether it is normal background refresh or an app bug.

I would keep permanent development, staging, and production for anything important, then use preview branches for short lived testing. The magic is nice for catching migration mistakes, but I would not make it the only place you prove changes. If a setup feels too clever to explain to a new teammate in two minutes, it usually gets expensive later.

I like the angle because most damage comes from one reckless query, not a slow one. The thing I would make painfully clear is who this is for first: people writing database queries by hand, people using generated queries, or teams letting coding agents touch real data. A couple of concrete before and after examples would help a lot.