That&#x27;s awesome. It looks very cool and pragmatically design. So as far as I can see:<p>- There is a database schema per actor type.<p>- Each actor has a separate physical (SQLite but with the backend replaced by LMDB) database.<p>Is this the case? Won&#x27;t this be using a lot of file handles if there are thousands or tens of thousands of actors? I&#x27;m assuming you already optimize this by closing &quot;idle&quot; actors, but what if they&#x27;re all &quot;live&quot;?<p>How do you coordinate safe schema changes across all actors? You mention that schema changes are performed &quot;just in time&quot;, that is, not when an actor is idle. I can definitely see the benefit of doing that. But for many types of schema changes you <i>do</i> want a controlled migration where you ensure that all tables are fully updated. Can you force the schema upgrade by touching all agents with a dummy query, perhaps?<p>It looks like ActorDB is designed for schemas where data is strictly partitioned, and where data wouldn&#x27;t cross these boundaries, because joins would be impractical&#x2F;not performant. For example, in a Dropbox-style system, every user would be an agent, and every user would really only talk to a single agent at a time. So that&#x27;s a perfect fit.<p>You also show a discussion thread example, where there is one actor per thread. This would mean that if you wanted to do something like &quot;get all threads where user X has commented&quot;, you would need to either query all agents of type &quot;thread&quot;, or you would need to maintain an agent that keeps track of [user, thread] mappings, and then either query each manually, or use the looping construct (section 4.1.4 in the documentation) to perform the query across the relevant agents. Am I getting this right?<p>How much failover testing have you done on your Raft implementation?