Forcing developers to think ahead about what data they actually need in advance also seems like a good thing maybe.

It does.

You're right that this could introduce regressions, but it sounds like it's making more testable.

My biggest concern would be introducing db contention with locks being held for too long, and introducing race conditions because the cached data isn't locking the records when they're cached.

Edit: your->you're

Regardless of what pattern it is, you have a clear performance need and a testable implementation. That's a win.

Beyond looking for a pattern, I'd look at what your doing to make sure you're not loading a ton of extra dependencies of your know you won't use them.

Also, you generally want a database transacting to be one logical unit of work, that all commits or all rolls back together, if you're combining multiple transactions is likely what you want, but be aware that you might be holding locks for longer, so you might be introducing contention.

By the same token, make sure you've got records locked if you need them locked. If you had atomic updates before, or your first update locked the records you needed, you may need to lock records explicitly to keep your database consistent.

How much could performance even improve?

Definitely voting for someone who doesn't support genocide for president. Down ballot I'll likely vote 3rd party as well, but I haven't decided for sure.