- Correct.<p>- Incorrect. They are all inside a single LMDB file. So there is not an open file handle for every actor.<p>&gt; How do you coordinate safe schema changes across all actors?<p>Before committing a schema change, we test it against the existing schema. If SQLite runs the SQLs successfully (on a dummy memory-only database) it is committed. We do not guard against writing updates which might succeed in some actors and not succeed and others. It is the developers&#x2F;administrators responsibility to create schema updates that are valid.<p>We assume schema changes are reasonable (add tables, columns, indexes). Not rewrite the entire schema kind. Of course you can do that, but it&#x27;s your responsibility that it is working.<p>If there is any doubt of a schema update, one can always create a dump of the live database, start it up in a staging environment and perform the planned update there first.<p>&gt; But for many types of schema changes you do 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>I don&#x27;t really see a benefit in doing that. But you can very easily write such a query: &quot;actor mytype(*); select id from sometable limit 1;&quot;<p>&gt; Thread example...<p>The user actor would be the right place to store the list of threads where it has commented. So every post would be a transaction to thread (where the message and actor id would go) and user actor (that would just store a list of thread ids).<p>There is also another way of modelling a forum that I think would be better. Have two KV types, users and threads.<p>The schema:<p>------------<p>actor user kv<p>CREATE TABLE actors (id INTEGER PRIMARY KEY, hash INTEGER, name TEXT);<p>CREATE TABLE messages (user INTEGER, thread INTEGER, FOREIGN KEY (user) REFERENCES actors (id) ON DELETE CASCADE, PRIMARY KEY (uid,thread)) WITHOUT ROWID;<p>actor thread kv<p>CREATE TABLE actors (id INTEGER PRIMARY KEY, hash INTEGER, title TEXT, date INTEGER);<p>CREATE TABLE messages (id INTEGER PRIMARY KEY, thread INTEGER, uid INTEGER, txt TEXT, FOREIGN KEY (thread) REFERENCES actors (id) ON DELETE CASCADE);<p>------------<p>KV types with sub-tables are quite powerful. You can have a rich data model and the data will not be too fragmented over a large number of actors.<p>&gt; How much failover testing have you done on your Raft implementation?<p>Replication receives the bulk of testing.