Let's take a look at how DynamoDB compares to other database technology that you might already be familiar with. You've probably already worked with a relational database like MySQL, Oracle, or Microsoft SQL Server. DynamoDB is a NoSQL database which means that you won't be writing SQL queries to read and write data. Instead, you'll need to make calls to specific DynamoDB APIs with names like PutItem, GetItem or query.

DynamoDB is also schemaless so you don't have to define a fixed table structure in advance. When you insert a DynamoDB record, it can have any attributes that it needs. So you can adjust columns and data types on the fly.

DynamoDB was designed from the beginning to be extremely scalable. Your data can grow to many terabytes, with hundreds of thousands of reads and writes per second. You don't have to manage the servers or the partitions, this is all handled for you by AWS. It's much more difficult to do this in a relational database because of the way data structures like indexes work in a relational system. But this flexibility means that DynamoDB does not follow the typical ACID properties of atomicity, consistency, isolation, and durability.

Data in DynamoDB is quite durable, but because of the way data is replicated across the AWS infrastructure, it's only eventually consistent. If you modify a record and then read it back, you may sometimes receive the older version of the data until the data is fully consistent across all three replicates.

Finally, be aware that using DynamoDB will tie you to Amazon Web Services. There aren't really other options for hosting DynamoDB databases except using the AWS public cloud. If you need to keep all of your data on premises, or if you want to be able to easily switch cloud hosting vendors, then DynamoDB might not be right for you.

If you've used NoSQL databases like MongoDB or Cassandra, Then DynamoDB might feel more at home. DynamoDB is considered a document-oriented database much like MongoDB. The database can understand a little bit about the structure of each record or document but each item can have it's own unique structure.

Other NoSQL databases are in different categories. For example, HBase is a column storer. DynamoDB only supports an eventual consistency model. Some other NoSQL databases can be used on a single service where there's no need to worry about consistency across a cluster. Or they can be used in a mode that enforces strict consistency across the cluster.

DynamoDB scales transparently to the users. It doesn't matter whether your table has 10 rows or 10 billion rows. You don't have to do anything differently as your tables grow. Many other NoSQL databases do allow you to scale up as your data grows. But you'll have to manage individual servers or add servers to the cluster as you need them.

Finally, DynamoDB is always managed by Amazon Web Services. This is great because it reduces the operation burden for your team, but again it means that you are tied to the AWS public cloud. If you're trying to decide between different ways of running a database on AWS, use Amazon DynamoDB if you want a fully managed database that can scale easily and you don't mind learning new concepts. Use Amazon's Relational Database Service if you want a managed database instance using a standard relational database like MySQL, Postgres, Oracle or Microsoft SQL Server. And if you're concerned about giving control of your data to a hosting provider, or if you need the data to live on premises, then you should probably host your own database either in the cloud or in your own data center.