For most of the stuff we use MySQL. We just use Amazon RDS. But for some stuff we use Amazon DynamoDB. We love DynamoDB. It's amazing. We store usage data in there, for example. I think we have close to seven or eight hundred million records in there and it's scaled like you don't even notice it. You never notice any performance degradation whatsoever. It's insane, and the last time I checked we were paying $150 bucks for that.

zerotoherojs.com ’s userbase, and course details are stored in DynamoDB tables.

The good thing about AWS DynamoDB is: For the amount of traffic that I have, it is free. It is highly-scalable, it is managed by Amazon, and it is pretty fast.

It is, again, one less thing to worry about (when compared to managing your own MongoDB elsewhere).

We store customer metadata in DynamoDB. We decided to use Amazon DynamoDB because it was a fully managed, highly available solution. We didn't want to operate our own SQL server and we wanted to ensure that we built CloudRepo on high availability components so that we could pass that benefit back to our customers.

When creating proofs of concept or small personal projects that are hosted primarily in AWS, with non-relational data models, this is the NoSQL managed database I usually pair them with.

몇몇 로그는 현재 AWS DynamoDB 에 기록되고 있습니다. 개선을 통해 mongodb 로 옮길 계획을 하고 있습니다. 아주 간단한 데이터를 쌓는 용도로는 나쁘지 않습니다. 다만, 쿼리가 아주 제한적입니다. 사용하기 전에 반드시 DynamoDB 의 스펙을 확인할 필요가 있습니다.

All main application data is stored here. Most data is loaded through queries, but some collections are also indexed with Algolia for searching.

If you need a document-based database with geo-redundancy (imagine AU-HU distance), this is the way to go.