Should storage be treated as a complete database solution?

Documentation
,
1

I understand that storage is a table for storing player specific information and exists alongside other tables all being used in the nakama engine. https://forum.heroiclabs.com/t/storage-vs-database-the-difference/805

I also understand the userid can be circumvented if an empty one is used to store other information https://forum.heroiclabs.com/t/purpose-of-userid-in-storage-entries/4570

so technicaly storage can be used to:
1- store somewhat static information such as the list of item ids available in the in game shop and item information for each item id. which are design data that are read alot but not written to so often

{
Collection: “shop”,
Key: “availableItemIds”,
UserID: “00000000-0000-0000-0000-000000000000”,
Value: {someItemId1, someItemId2, someItemId3}
}

{
Collection: “items”,
Key: “someItemId”,
UserID: “00000000-0000-0000-0000-000000000000”,
Value: {name: someName, price:10}
}

2- store data for shared concepts such as match results. for example in a 5v5 game a match with a match id of X is added to the match collection, X is also added to the list of matches played by each participant. so the match table is written to storing information about the match, each participating member can use the matchids they have to read the past match information.

{
Collection: “matchIds”,
Key: “matchGameMode”,
UserID: someUserId,
Value: {someMatchId1, someMatchId2, someMatchId3}
}

{
Collection: “matches”,
Key: “someMatchId”,
UserID: “00000000-0000-0000-0000-000000000000”,
Value: {players: [someUserId, someUserId2], winner: someUserId}
}

1- Are the use cases mentioned doable?
2- Is this way of thinking and using storage where I fulfil all my data storage requirements through nakama storage intended and advised?
3-At what point and in what scenarios should developers write their own data base and develop their own server side service for nakama to use to write and read from instead of using storage directly?

2

We store a fair deal of stuff without a user id, such as things that are not player specific or common to all players. Some data is config data sent to clients when they connect and some is used by the server for everyday operations. So leaving out the user id works fine.

Personally I would like to see some system that works like a normal database table where we could store things like match results, purchased items (not IAP), statistics etc. Having to either read in a blob, append a struct and write it back out feels extremely heavy. Having a new unique storage record just for something that should be just one line in a mostly write-only table also feels heavy.

1 Like
3

Hello @alireza,

These threads can give some more insight into how to best lay out the data in the storage engine as well as how to achieve partial updates with some custom SQL queries: Storage engine structure
How to best implement a sorted list of JSON data accessible for all players to submit to multiple times?

To answer your questions directly:

1 - Yes absolutely.
2 - Yes, this is a good approach, create a shared object written once and then have “pointers” for each player that point to the match data entries.
Sometimes it may make more sense to just duplicate the data under the different users, whatever works best for what you’re trying to achieve.
3 - Ideally never. The Nakama and its Storage Engine is designed to be flexible enough for most uses. We have many customers relying solely on the Storage Engine and its APIs for all their storage needs.

@chakie In the future we’d like to support partial updates with a first party API using something like JSONPATH.

Beware that shared objects are fine as long as they aren’t under heavy concurrent write loads (e.g.: the same object can be updated by all the clients) - this can create db contention.