When to use multiple tables in DynamoDB?

The DyanmoDB [best practices](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html) make it clear that: > You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table. I find it amusing then that just about every single tutorial I've seen dealing with DyanmoDB has a multi-table design. But what does this mean in practice? Let's consider a simple application with three main entities: Users, Projects, and Documents. A User owns multiple projects, and a Project can have multiple Documents. We typically have to query on the Projects for a User, and on the Documents for a Project. Reads outnumber writes by a significant margin. A naive tutorial's table design would use three tables: Users Hash key user-id Projects Hash key Global Index project-id user-id Documents Hash key Global Index document-id project-id We could pretty easily collapse Project and Document into one Documents table: Documents Hash key Sort key Global Index project-id document-id user-id But why stop there? Why not one table to rule them all? Since the User is the root of everything... Users Hash key Sort key user-id aspect --------- --------- foo user email: foo@bar.com ... foo project:1 title: "The Foo Project" foo project:1:document:2 document-id: 2 ... Then we would have a Global Index on, say, the email field for user record lookups, and another on the document-id field for direct document lookups. Is that how it's supposed to work? Is it legit to throw such wildly-divergent kinds of data into the same table? Or is the second, two-table design a better approach? At what point would it be correct to add a second table?