The Good Tech Companies - DynamoDB: When to Move Out

Episode Date: December 23, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/dynamodb-when-to-move-out. ScyllaDB offers a high-performance NoSQL alternative to DynamoDB, solving throttling, latency, and size limits for scalable workloads. Check more stories related to tech-stories at: https://hackernoon.com/c/tech-stories. You can also check exclusive content about #cloud-database-migration, #nosql-database, #scylladb, #low-latency-database, #dynamodb-alternative, #high-throughput-database, #scylladb-alternator, #good-company, and more. This story was written by: @scylladb. Learn more about this writer by checking @scylladb's about page, and for more stories, please visit hackernoon.com. ScyllaDB offers a high-performance NoSQL alternative to DynamoDB, addressing throttling, latency, item size limits, and cloud lock-in. With larger mutation sizes, predictable low-latency throughput, and compatibility via ScyllaDB Alternator, teams can scale efficiently while maintaining flexibility and minimizing operational complexity as workloads grow.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. DynamoDB. When to move out, by SkylaDB. A look at the top reasons why teams decide to leave DynamoDB. Throttling, latency, item size limits, and limited flexibility, not to mention cost's full disclaimer. I love DynamoDB. It has been proven at scale and is the back end that many industry leaders have been using to power business critical workloads for many years. It also fits nicely within the AWS ecosystem, making it super easy to get started, integrate with other AWS products, and stick with it as your company grows. But hopefully, there comes a time when your organization scales quite significantly. With massive growth, costs become a natural

concern for most companies out there, and DynamoDB is fairly often cited as one of the primary reasons for runaway bills due to its pay-per-operation service model. You're probably thinking, Oh, this is yet another post trying to convince Medad DynamoDB costs are too high, and I should switch to your database, which you'll claim is less expensive. Ha, smart guess, but wrong. Although costs are definitely an important consideration when selecting a database solution, and SkylaDB does offer quite impressive price performance versus DynamoDB, it is not always the most critical consideration.

In fact, many times, switching databases is often seen as an open heart surgery, something you never want to experience, and certainly not more than once. If costs are a critical consideration for you, there are plenty of other resources you can review. To name a few, SkyladyB versus DynamoDB benchmark, comparing price performance across workloads. Alex DeBree's article on how you should think about DynamoDB costs. Tobias Schmidt's very comprehensive Amazon DynamoDB pricing explained, but let's switch the narrative and discuss other aspects you should consider when deciding whether to shift away from DynamoDB. HTTPS colon slash www Skylid B.com DynamoDB cost optimization masterclass.

This masterclass will teach you strategies on DynamoDB cost optimizations and other AWS alternatives to fit your technical needs. DynamoDB throttling. Throttling in any context is no fun. Seeing a makes people angry. If you've seen it, you've probably hated it and learned to live with it. Some may even claim they love it after understanding it thoroughly. There are a variety of ways you can become a victim of DynamoDB throttling. In fact, it happens so often that a WS even has a dedicated troubleshooting page for it. One of the recommendations here is switch to on-demand mode before actually discussing evenly distributed access patterns. The main problem with DynamoDB's throttling is that it considerably

harms latencies. Workloads with a Zipfian distribution are prone to it, and the results achieved in a recent benchmark aren't pretty. During that benchmark, it became apparent. that throttling could cause the affected partition to become inaccessible for up to two. Five seconds, that greatly magnifies your P99 tail latencies. While it is true that most databases have some built-in throttling mechanism, DynamoDB throttling is simply too aggressive. It is unlikely that your application will be able to scale further if it happens to frequently access a specific set of items crossing the DynamoDB partition or table limits. Intuition might say, Well, if we are hitting DynamoDB limits, then let's put a cache in front of it.

Okay, but that will also eventually throttle you down. Itis. In fact, particularly hard to find hard numbers on DynamoDB accelerator's precise criteria for throttling, which seems primarily targeted to CP utilization, which isn't the best criteria for load shedding. DynamoDB latency. You may argue that the Zipfian distribution shown above targets DynamoDB's Achilles heel and that the AWS solution is a best.

better fit for workloads that follow a uniform type of distribution. We agree. We've also tested Dynamo D bunder that assumption. Even within DynamoDB's sweet spot, P99 latencies are considerably higher compared to Skylady B across a variety of scenarios. Of course, you may be able to achieve lower DynamoDB latencies than the ones presented here. Yet, DynamoDB falls short when required to deliver higher through puts, causing latencies to eventually start to degrade.

way to avoid such spikes is to use DynamoDB accelerator or any other caching solution, really, for a great performance boost. As promised, I'm not going to get into the cost discussion here, but rather point out that DynamoDB's promised single-digit millisecond latencies are harder to achieve in practice. To learn more about why placing a cache in front of your database is often a bad idea, you might want to watch this video on replacing your cache with Skylidibi. DynamoDB item size limits. Every database has an item size limit, including DynamoDB. However, the 400KB limit may eventually become too restrictive for you. Alex DeBri sheds some light on this and thoroughly explains some of the reasons behind it in his blog on DynamoDB limits. Greater than, so what accounts for this limitation? DynamoDB is pointing

you toward how you greater than should model your data in an OLTP database. Online transaction processing, or greater than OLTP, systems are characterized by large amounts of small operations against a greater than database. Opening parenthesis, ellipsis, closing parenthesis. For these operations, you want to quickly and efficiently filter greater than on specific fields to find the information you want, such as a username or a greater than tweet ID. OLTP databases often make use of indexes on certain fields to make greater than lookups faster as well as holding recently accessed data in RAM.

While it is true that smaller payloads or items will generally pro-Veed improved latencies, imposing a hard limit may not be the best idea. Skylid boozers who decided to abandon the Dynamody B ecosystem often mention this limit, positioning it as a major blocker for their application functionality. If you can't store such items in DynamoD B, what do you do? You likely come up with strategies such as compressing the relevant parts of your payload or storing them in other mediums, such as a WSS3. Either way, the solution becomes suboptimal.

Both introduce additional latency and unnecessary application. application complexity. At Skylidibi, we take a different approach. A single mutation can be as large as 16 megabytes by default. This is configurable. We believe that you should be able to decide what works best for you in your application. We won't limit you by any means. Speaking of freedom, let's talk about DynamoDB's limited freedom flexibility. This one is fairly easy. DynamoDB integrates perfectly within the AWS ecosystem, but that's precisely where the benefit ends. As soon as you engage in a multi-cloud strategy or decide to switch to another cloud vendor, or maybe fall back to on-prem. Don't get me started on a WS outposts. You will inevitably need

to find another place for your workloads. Of course, you cannot predict the future, but you can avoid future problems. That's what differentiates good engineers from brilliant ones, whether your solution is ready to tackle your organization's growing demands. After all, you don't want to find yourself in a position where you need to learn a new technology, change, your application, perform load testing in the new DBMS, migrate data over, potentially evaluate several vendors. Quite often, that can become a multi-year project depending on your organization size and the number of workloads involved. DynamoDB workloads are naturally a good fit for Skyladyby. More often than not, you can simply follow the very same data modeling you already

have in Dynamo Dband use it on Skyladyby. We even have Skyladyby Alternator, an open-source DynamoDb compatible API to allow you to migrate seamlessly if you want to continue using the same API to communicate with your database, thus requiring fewer code changes. Final remarks, folks, don't get me started on DynamoDB is a nice Reddit post you may want to check out. It covers a number of interesting real-life stories, some of which touch on the points we covered here. Despite the notorious community feedback, it does include a fair list of other considerations you may want to be aware of before you stick with DynamoDB. Still, the first sentence of this article remains true. I love DynamoDB. It is a great fit and an economical solution when your company or use case has low-through-put

requirements or isn't bothered by some unexpected latency spikes. As you grow, data modeling and ensuring you do not exceed DynamoDB's hard limits scan become particularly challenging. Plus you'll be locked in and may eventually require considerable effort and planning if your organization's direction changes. When selecting, you'll be locked in. When selecting, you'll be locked in, a database, it's ultimately about choosing the right tool for the job. Skylidibi is by no means a replacement for each and every DynamoDB use case out there. But when a team needs a NoSQL database for high through Pudent predictable low latencies, SkylaDB is invariably the right choice. Thank you for listening to this Hackernoon story, read by artificial intelligence. Visit hackernoon.com

to read, write, learn and publish.