[TeMPOraL]

You seem to be coming from somewhere closer to "like SQL" than the data-oriented end of the spectrum.

On either end of the spectrum, there's much less flexibility. The "SQL side" is optimizing things for bulk operations[0] and flexibility coming from composition[1]. The "data-oriented side" is optimizing for performance, and it so happens that stuffing data that's processed together into arrays you can just scan in a cache-friendly way, also yields a component-like division of data.

Both those approaches are quite inflexible. They do kind of meet in the middle, as they yield similar data organization, but I'm increasingly convinced this is a surface-level, entirely incidental similarity. Philosophically, the two extremes of "ECS" are entirely unlike.

--

[0] - Again, AFAIR, ECS originally came from MMO world, where they do use relational databases for storing game state.

[1] - Also reason to use databases if you're making an MMO, as relational tables are known quantity, while serializing polymorphic object graphs is plain annoying.

[rcxdude]

The performance side is a bit overblown, in that of course performance strongly depends on access patterns and the access patterns strongly depend on what you're actually simulating. ECS can help with performance but it can also hurt: e.g. the devs of factorio, who have a very large simulation, based on their profiling, have found the game is almost entirely memory bandwidth limited, and so an ECS SoA system like is often touted would not work very well, as it's far better to run every system on each entity than it is to feed each entity through each system, and when inevitably different systems care about the same components, the first will almost certainly find the component data in the cache, while the latter almost certainly won't be and results in the same data being loaded from RAM multiple times.