DynamoDB Table Structure

Hoped to clarify conflicting information between AWS DynamoDB best practices and what is seen in the cloud gems. According to [DynamoDB Users Best Practices],(https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html) it clearly states

You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.**

I have seen this exact same suggestion made on countless other forums and blogs. Yet, however, the actual sample cloud gems provided, such as Leaderboard, contains tons of tables.

I guess my question is two-fold. We are creating a massive multiplayer experience where each user may have multiple characters/avatars they can choose from. Would I be best served by using the PlayerAccounts Cloud gem as a base (since it has the Cognito authorization already running) and then build upon that same table to add additional attributes that each player will need, or should I create a completely separate table to access additional player data after the user has already logged in through the sample playeraccount cloud gem?

What have been your experiences with player account table design in DynamoDB and LY?


You are correct that because Dynamodb is effectively schemaless and supports denormalized data you often can often model applications with a single table.

In practice, it may make sense to have multiple tables in your application because:

  • The data has different uses leading to scaling/security separations
  • Table row items have grown to large requiring multiple reads per line
  • Or its just that the implementer find its easier to have separated tables to aid modelling/maintaining the application.

I will try and have a look at the tables created by the PlayerAccounts Gem to refresh my knowledge so I can answer your specific question in detail.

This may be an interesting (and short) read in the meantime: https://aws.amazon.com/blogs/database/amazon-dynamodb-gaming-use-cases-and-design-patterns/

btw, this is a good AWS talk that covers how to model a lot of access patterns using a single table.

The whole talk is good but the good part is around 49mins in: