if (you Don't Have DynamoDB Yet) {

In this case I would strongly recommend to not use DynamoDB.
Instead of it go with PostgresQL or MongoDB or anything else.

DynamoDB scales pretty well, but it's very annoying for developers. Just pick another one even AWS DocumentDB or you can go with AWS RDS - PostgreSQL/MySQL](https://aws.amazon.com/rds/)

}

if (you Have DynamoDB Already) {

Pagination Nightmare

This is something that I only seen with DynamoDB. You can do a Scan or a Query and you only will have a page so you will have to iterate. If you want to dig: DynamoDB Pagination.

When I reached DynamoDB it was for a legacy system that I had to improved. This is the first thing I didn't like it. I've worked with MongoDB, Couchbase, MySQL and PostgreSQL along with others and never seen something like this. The the bottomline is that if you want all the records of the database you will have to iterate.

Scan vs Query

In any Database the indexes are useful to speed the queries and make those very performant. In DynamoDB if you don't have a "partition index" or a "global secondary index" you are not allowed to do a Query. The option then is to do Scan that is painfully slowly since it retrieves all the data and then you can use filters but again it is like getAll and then filter over that collection. This means that you have to think in advance how you want to access the data. And think which are your fields that you'll have queries. In a refactor of an existing table I did that work and I added 3 GlobalSecondaryIndexes for 3 different queries.

Partition Index vs GlobalSecondaryIndex

AWS GlobalSecondaryIndexes

AWS PartitionKey

Environments? Prefix vs Region vs Different Accounts.

I dig into the situation of having to have:

a) A local environment.
b) development, test vs production environments

A local environment

1. Setting up the Local Environment:
   Document for Setting up Env

2. Copying from AWS to Local
   Use one of the tools that I have in the tools section to read a table and write it to the local.

development, test vs production environments

I do not like this approach but it is the recommendation from AWS is to use a prefix so you would have users and dev_users which is the "development environment table".

Tools

There is a lack of good tools for DynamoDB there are a few that are decent but paid.

a. AWS DynamoDB tool NoSQLWorkbench

Some considerations about the AWS NoSQLWorkbench it is useful to design a little bit the new tables or collections (name it as you wish). But for queries kind of sucks, The main reason is because of Pagination.

b. AWS DynamoDB Web Console:

c. Dynobase (Paid):

Dynobase UI

d. A npm tool I built to copy tables between environments and regions or even within the same region but a different prefix:

aws_dynamo_copy_table

}