I can think of two ways you can optimize it when it is inlined. Either store two copies of it (one in the users table and another in your Objects store for history), or hope that the system IO caching layer keeps it memory, so the DB doesn’t need to go to disks. Both aren’t great I think. I’ve ignored caching the Actor representation on purpose, since in that case you wouldn’t need to make any DB requests at all, there are no performance implications.
Meanwhile if you don’t inline it and instead store a link to it, that is retrieved when necessary, you can complete most of the requests for an Actor with one round trip to the DB (newest link can be easily stored in the users table as another column) at worst when not cached already. Most instances will simply never fetch the link, because frankly they won’t understand it. And if they do, they likely won’t make the HTTP request, because it either didn’t change, or they received the change via push federation. In this case, a single DB query on most requests is more expensive than an HTTP request that is barely ever made. At a scale of few users on an instance, it does not matter, but at scale of hundreds or thousands, it can. Why I even brought it up is because in most cases instances are very IO starved and making unnecessary requests hitting the disk(s) makes it even worse.
But those are my two cents, I don’t wanna turn this into a case of pointless bikeshedding preventing finalization.