msw or a real neon branch per PR when the suite has 9 minutes of budget CI

The real cost of request mocking is drift. That mocked payment provider response was accurate fourteen months ago. Nothing tells you when it stops being.

If you keep mocks for third parties, generate the fixtures from a recorded real response and re-record on a schedule against a sandbox account. Otherwise you are testing your own memory of an API.

Test the policy from outside, as the app role. Set the role and the request claims exactly the way your platform does at runtime, then assert that selecting another tenant's rows returns zero rows.

Assert on the row count, not on an error message. Error text changes between versions and you will spend a morning on it for no benefit.

Point them at the staging database. Branches are a lot of setup for the same outcome and you get realistic data for free.

Budget maths, since nine minutes is the actual constraint: 400 tests against a real database is fine as long as they are not each running migrations. Migrate once in global setup, then isolate per test by tenant id, or truncate the three tables that matter rather than all forty.

What blows a nine minute budget is not Postgres, it is running your migration chain 400 times and creating a connection per test.

Add one canary test that only passes when RLS is actually on. Otherwise the day someone runs CI as a superuser or a role with bypass privileges, every policy test goes green and stays green, and the suite is worse than useless because it is now lying confidently.

In-process Postgres compiled to wasm is a third option worth knowing about - genuinely Postgres, so policies behave, and no container to wait for. A sqlite stand-in is not an option here at all, since it has no row level security to test.