Upgrade to the new entity database
The entity database: background
The entity database is responsible for storing the canonical value of component data for entities, making sure that only clients with authority over component data have write access to that data, and informing clients of when there are changes to data they’re interested in.
Upgrading to the new entity database is the third and final step in upgrading to the new Runtime. We encourage you to upgrade your projects to the new Runtime and to use this configuration going forward. This means you’ll be using the most performant, most stable and easiest to scale version of the Runtime.
What’s changing
Updates from the Runtime to workers can be “squashed” if either the worker or the Runtime is under high load. For example, if Worker A is struggling to keep up with updates, then a series of position updates {P1, P2, P3} emitted by Worker B might be received by Worker A as {P1, P3}. In other words, Worker B will observe the latest state, but not intermediate states.
If you need a worker to observe every update in a series of updates, use events, as these are never squashed. If you just care about state, use component updates.
The system no longer deletes entities that leave the world boundaries defined in the launch configuration file. World boundaries are no longer a necessary constraint of the system and we’ll remove them at a later date.
What’s not changing
Chunks no longer exist in the new entity database. However, we’ll continue to emulate chunk-based entity interest for workers (where workers become interested in discrete square chunks of space based on their authority).
How to upgrade
To upgrade to the new entity database, in your launch configuration file, change your deployment template to <size>_entity_db_v2.
For example, if you’re currently using the small template, change this to small_entity_db_v2.