Separation of game worlds entity database, is it a good idea?


The multiplayer game I am working on consists of multiple worlds/levels and one main hub world.

I am using Zay-ES and it internally uses HSQLDB for persisting entity data.

Each level has its own world. Levels going to be unlocked one by one as players progress through the gameplay.

Players’ data must be shared/synced between the worlds. (player stats, player inventory,…)

Only one world can be active at the same time.

Considering the above facts, is it a good idea to let each world has its own separate entity database?

If so, any idea how I can sync the player’s data?

In my current approach, I am using a single entity database and separating entities with a world ID component.

I want to know which approach should be good to take.



There may have been another thread that discussed this in detail recently. In that game setup it was more about just player stats being shared between ‘games’ but it still might be helpful.

The idea was that a regular REST web server would coordinate the “outside game” data, accounts, etc… Each “game” would have its own data, ie: own entity day, own server, etc…

1 Like

Yeah, that was about the separate hosts and separate players, but in this case it’s about the same host, same game and same players but the different level in the game :slightly_smiling_face:. So I was not sure if I should follow the same principle here.

Yes, this was in mind to use rest to save player entity data, but I was not sure if this is right, because player data are actually game objects. but will give it yet another think. Thanks.

1 Like

Unless your game is huge with 50,000 players in a single “game” and 9,000 levels with a hundred million entities each, it would be tempting to just put it all in one DB.


My Outside Engine puts everything for all worlds in the same database. There is a users table for account info. A characters table for character data for both users and npcs. A npc table for NPC specific data. A world_items and world_objects table for objects and items in the game world. Each of the world tables use virtual tables via partitions to separate the data per world. This is done using postgres. This way a single table is used for the querries, but behind the scenes the worldId actually selects different table partitions. The Outside enigne supports multiple unrelated games and their worlds using this structure while allowing a universal user account.


Personally I’d put it in a single database because it’s the same stuff. Collating data cross-databases is expensive, too, so reading multiple databases and then possibly re-organising it based on collated data will be a pain and an area of both expense and maintenance.


I’d suggest keeping all data in the same DB - preferably one you have good admin access to outside of your game engine. This makes things a lot less error prone and much simpler (no chance for data loss or duplication due to a failure at an unlucky time).

You might want to look into Apache Ignite ( - it greatly simplifies managing server-specific data, locality, and persistence, and it can be used in a very lightweight embedded mode.


And to note, a lot of database layers have multi-threading built in (connection pools) which is also a bonus - saving you the effort. All roads lead to a single setup for me.


Just pointing out that he’s already said what his database is and how it’s used.

…which I still think is fine for his use case. My answers have all been in that context.

Ok, thanks so much everyone for pointing me to right direction. :slightly_smiling_face:

1 Like