Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.
It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance
Compare:
psql --host=team1.example -d team1
# versus
psql --host=the-db.example -d team1
Sometimes one can get away with schema level split, which can allow cross schema references in a read only setup, but carries coupling concerns
psql --host=the-db.example -d my_db -U team1 "select * from team1.orders o inner join team2.products p ..."
I don't mean to troubleshoot over HN comments, as the problem space is filled with nuance and trade-offs, but intended it as "for your consideration"
Thanks, but it's something else. When I say people shove their data into other teams' DBs, I really mean into other teams' schemas... and they don't even have direct SQL access to their data anymore, rather the teams set up some CRUD API which they have to painfully maintain.
We aren't using Postgres but a more specialized DBMS. Everyone basically does the first thing in your example, sharing one cluster. The real issue is it's a big corp with red tape around stuff, people don't want responsibilities like compliance, and people are rightfully scared of keeping things performant on a fancy DBMS. Our team isn't scared, we did it, but it wasn't easy either.
To clarify, team A has some data in a DB, team B comes along asking to store their own data in there too, team A sets up CRUD API through which team B writes their stuff into team A's DB then gets it back.
