The FDB knobs are tuned with the 8GB per process assumption. Changing these knobs is generally reserved for advanced deployments. ref
Without key clears or inserts I don’t believe the btrees will need to rebalance in any significant manner. Unless I am missing something?
Yes, this is very much in line with my thinking, taking inspiration from Erlang’s atom table, but making it a permanent part of the metadata in the DB. However, there is likely a challenge with coordinating changes to Ecto Schemas across a distributed app. As you deploy a new app release, some clients will be on one Ecto.Schema and others on the new Ecto.Schema. It is during these transition periods that I believe something more must be done to prevent wires being crossed. For example, a naive approach would cause a node on the old Ecto.Schema to start getting nils for a field that has been remapped in the symbol table. This is probably all surmountable, but it’s a significant amount of work.
EctoFDB already does what you describe in each transaction. I’m not familiar with \xFF/metadataVersion; I will have to look into it, thanks for the tip!
.
. I’ll update the docs to reflect this, too.