Like kvark said, they don't really fit the ECS model well. The standard answer would be to encapsulate them into a system (i.e. go outside the ECS). The way I

Like kvark said, they don't really fit the ECS model well. The standard answer would be to encapsulate them into a system (i.e. go outside the ECS). The way I see ECSs is that they are in-memory relational databases that only support equijoins (look up component matching entity ID) and optimize for table scans. The typical choice of an index structure is a contiguous ordered array, making for very fast lookups and scans. If insertion/deletion performance becomes an issue you can add one level of indirection and only keep a list of pointers to components ordered. However, like you indicated, games also need other kinds of queries, so scene graphs and quad trees should be supported as indices on the same level as the arrays and hash tables that are traditional for ECSs. I would love to see an in-memory database with all the features required by games. There are some very different tradeoffs to be made than in typical in-memory databases: - The most important queries are known up-front, since the simulation/rendering loop is fairly defined. - Transactions don't need to be durable. Just need to be able to checkpoint once in a while. - Lots of bulk updates from the simulation. - Query language needs to be well integrated into the application language to avoid overheads.