DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • How to Maximize the Azure Cosmos DB Availability
  • Microsoft Azure Cosmos Database Service
  • Connecting to Azure Cosmos DB MongoDB API
  • Which Tool Is Better for Code Completion — Azure Data Studio or dbForge SQL Complete?

Trending

  • *You* Can Shape Trend Reports: Join DZone's Software Supply Chain Security Research
  • Scalable, Resilient Data Orchestration: The Power of Intelligent Systems
  • Accelerating AI Inference With TensorRT
  • Unlocking AI Coding Assistants Part 1: Real-World Use Cases
  1. DZone
  2. Data Engineering
  3. Databases
  4. Cost Comparison: Azure Cosmos DB vs. DynamoDB vs. Neptune

Cost Comparison: Azure Cosmos DB vs. DynamoDB vs. Neptune

I try here to break down the costs for these three services in an effort to help you make an apples-to-apples comparison.

By 
Thomas LaRock user avatar
Thomas LaRock
·
Apr. 17, 18 · Opinion
Likes (5)
Comment
Save
Tweet
Share
30.6K Views

Join the DZone community and get the full member experience.

Join For Free

Building on my previous post, Azure vs. AWS Data Services Comparison, today, I want to write about the Azure Cosmos DB costs vs. DynamoDB and Neptune. I'm going to give an example today comparing only the NoSQL services offered by Azure and AWS.

For Azure, the NoSQL service offered is Azure Cosmos DB. Cosmos DB is the place for all your key-value, document, and graph database needs. (Cosmos DB is what we would have if your cable company started offering databases. Phone, television, and internet all bundled together for one low price sounds good, but key-value, document, and graph for one price and SHUT UP AND TAKE MY MONEY). On the AWS side, we have DynamoDB for key-value and document, and Neptune for graph.

For the purpose of this post, I am going to try to price the simplest of deployments in an effort to match services. In other words, I'm not going to dive into multi-region or geo-replicated databases today. I am going to assume that we have a requirement of 50GB of storage for three database services: key-value, document, and graph. I will keep the reads and writes to be the same, and do my best to keep everything equal.

Let's break this down. First up, Cosmos DB pricing.

Azure Cosmos DB Pricing

The Azure pricing page seems simple enough. You pay for your storage and for these things called request units per second, or RU/s. The FAQ section of the Cosmos DB page explains in simple terms what RU/s means. However, this page is far better for referencing what RU/s means, as well as understanding that size matters. That page also breaks down how you pay less for reading data from Cosmos DB than you do for writing data. I'm going to use one of the 4kb size examples and 500 reads and 500 writes, giving us a total of 4,150 RU/s. We will use that along with a modest 50GB of storage. The pricing calculator looks like this:

Not shown in that image is the fact that support is included, along with 99.99% availability for local region databases (99.999% for multi-region databases). Also worth noting is that Cosmos DB has an SLA of 10ms for reads and 15ms for writes. If Azure cannot give meet that SLA you will receive a credit on your next billing statement.

Let's move on to AWS. For that, we need to look at two services: DynamoDB and Neptune.

Amazon DynamoDB Pricing

For DynamoDB, the pricing calculator requires a few more inputs. Similar to Cosmos DB, we need to know the storage and the expected reads and writes. But we also need to know details about the expected throughput, the consistency model (apparently you pay 2x more for "strong" consistency in DynamoDB), and how many requests for something called DynamoDB Streams. That link suggests that I would use DynamoDB streams to implement my own form of replication across AWS zones. So, we won't include that in our pricing today. Here's what it looks like:

One thing to note here is that the consistency model is a factor for price. For Cosmos DB, there is no difference in price based on consistency models. I chose "strong" consistency here and we should assume that I would be deploying a Cosmos DB with strong consistency, as well. Also warrants mentioning: DynamoDB Streams is in Preview, and the first 2.5 million requests are free. Lastly, I split out the read/write throughput to be an 80/20 split.

Oh, and we are still missing one thing: the ability to use graph.

Amazon Neptune Pricing

Enter Neptune, the AWS graph database service. First, I want you to know that as of this post (March 2018), Neptune is in Preview. You won't find it on the calculator page. Instead, you have to go to the pricing page for Neptune and manually figure out your costs.

This alone makes it very difficult to compare services between Azure and AWS. For the Cosmos DB example above, I don't need to worry about what service I am using — I just pay one price.

From the Neptune pricing page, it would appear the billing will involve the size of the instance, storage, I/O, and data transfer. For our purposes here, let's assume we have modest needs, and that 25% of the Cosmos DB workload is graph-related. So, that's 10 GB storage and 830 RU/s. We will calculate this cost for Neptune.

I will take the lowest-end memory-optimized instance (db.r4.large) and allocate 10GB storage. For the total requests, we need to do some math. The Cosmos DB example above was 4200 RU/s for one month (730 hours). To get the equivalent number of requests for Neptune, we will take 20% of 4200, or 840 requests/second. That would be 220.7 million requests/month. The last piece of information we need is data transfer. Let's assume 20% of the DynamoDB transfer rate, so 8GB out and 2 GB in.

The total for Neptune would be:

  • The db.r4.large instance is $255.50/month
  • The 10 Gb storage is $1/month
  • The 220.7 million requests are $44.14/month
  • The data transfer rate is $0.72/month

That's a total of $301.36/month for our graph needs.

But now we need to adjust DynamoDB, reducing it by 20%. Doing that, we have:

Adding this up, we now have $790.60 for DynamoDB and $301.36 for Neptune, for a total of $1,091.96.

The Cosmos DB costs are $257.78. And you get all three services. One bill versus two.

Summary

I've tried here to break down the costs for these three services in an effort to help you make an apples-to-apples comparison. Some things were left out such as specific region costs, failover, availability, backups, etc. I've tried to keep things as simple as possible to give you an idea of costs and services provided.

It's hard to compare cloud services, but not impossible. Feel free to use this method for any of the other services I talked about in my previous post. As I mentioned in that post, it is easier to evaluate services when you examine costs versus trying to examine the resource limits the services provide.

This research also makes me wonder why AWS decided to deploy Neptune instead of extending DynamoDB. With that in mind, it would not surprise me to wake up one day to find that Neptune absorbed DynamoDB. After all, Cosmos DB absorbed DocumentDB last year. If Neptune became the only offering, it would make this example above a bit easier to complete. And I'd have to update my cheat sheet.

I'm okay with that.

Cosmos DB Cosmos (operating system) azure Database Comparison (grammar) AWS

Published at DZone with permission of Thomas LaRock, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • How to Maximize the Azure Cosmos DB Availability
  • Microsoft Azure Cosmos Database Service
  • Connecting to Azure Cosmos DB MongoDB API
  • Which Tool Is Better for Code Completion — Azure Data Studio or dbForge SQL Complete?

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!