The Good Tech Companies - How Digital Turbine Migrated DynamoDB to GCP With ScyllaDB in One Sprint

Episode Date: September 30, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/how-digital-turbine-migrated-dynamodb-to-gcp-with-scylladb-in-one-sprint. Digital Turbine migrated from DynamoDB to ScyllaDB on GCP in just one sprint—boosting performance, cutting costs, and ensuring business continuity. Check more stories related to cloud at: https://hackernoon.com/c/cloud. You can also check exclusive content about #dynamodb-migration, #scylladb-alternator, #gcp-database-migration, #digital-turbine-case-study, #cloud-cost-optimization, #database-performance-boost, #sada-cloud-migration, #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. Digital Turbine, a $500M mobile ad tech firm, had to leave DynamoDB after standardizing on GCP. Partnering with SADA, they migrated to ScyllaDB’s DynamoDB-compatible API in under a sprint. The move improved performance, reduced infrastructure needs, and cut costs by 20%, giving Digital Turbine a scalable, faster, and more efficient platform for future growth.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. How Digital Turbine migrated DynamoDB to GCP with Ciladib in one sprint. By Skyla DB, how Joseph Shorter and Miles Ward led a fast, safe migration with Siladibbe's DynamoDB compatible API Digital Turb as a quiet but powerful player in the mobile ad tech business. Their platform is pre-installed on Android phones, connecting app developers, advertisers, mobile carriers and device manufacturers. In the process, they bring in $500 million annually. And if their database goes down, their business goes down. Digital Turbine recently decided to standardize on Google Cloud. So continuing with their DynamoDB database was no longer an option.

They had to move fast without breaking things. Joseph Shorter, VP, platform architecture at Digital Turbine, teamed up with Miles Ward, CTO at Sada, and devised a game. plan to pull off the move. Spoiler. They not only moved fast, but also ended up with an approach that was even faster and less expensive too. You can hear directly from Joe and Miles in this conference talk. We've captured some highlights from their discussion below. Why migrate from DynamoDB? The tipping point for the DynamoDB migration was Digital Turbine's decision to standardize on GCP following a series of acquisitions. But that wasn't the only issue. DynamoDB hadn't been ideal from a cost

perspective or from a performance perspective. Joe explained, it can be a little expensive as you scale, to be honest. We were finding some performance issues. We were doing a ton of reeds. 90% of all interactions with DynamoDB were red operations. With all those operations, we found that the performance hits required us to scale up more than we wanted, which increased costs. Their DynamoDB migration requirements. Digital turbine needed the migration to be as fast and low risk is possible, which meant keeping application refactoring to a minimum. The main concern, according to Joe, was, how can we migrate without radical lyre factoring our platform, while maintaining at least the same performance and value, and avoiding a crash and burn

situation? Because if it failed, it would take down our whole company. They approached Sada, who helped them think through a few options, including some Google native solutions in Silladeeby. Sillotiby stood out due to its Dynamo D-B API. Sillidiby alternator, what the DynamoDB migration entailed. In summary, it was as easy as putting pie. Quoting Joe here. But a little more detail. There is a DynamoDB API that we could just use. I won't say there was nor a factoring. We did some refactoring to make it easy for engineers to plug in this information, but it was straightforward. It took less than a sprint to write that code. That was awesome. Everyone had told us that Sillidibi was supposed to be a lot faster.

Our reaction was, sure, every competitor says their product performs better. We did a lot with DynamoDB at scale, so we were skeptical. We decided to do a proper POC, not just some simple communication with CILIDB compared to DynamoDB. We actually put up multiple apps with some dependencies and set it up the way it actually functions in Oz, then we pressure tested it. We couldn't afford any mistakes. A mistake here means the whole company would go down. The goal was to make sure, first, that it would work and, second, that it would actually perform. And it turns out, it delivered on all its promises. That was a huge win for us. Results so far, with minimal cluster utilization. Beyond meeting their primary goal of moving off

a WS, the digital turbine team improved performance, and they ended up reducing their costs a bit too as an added benefit from Joe. I think part of it comes down to the fact that the performance is just better. We didn't know what to expect initially, so we scaled things to be pretty comparable. What we're finding is that it's simply running better, because of that, we don't need as much infrastructure. And we're barely tapping the Cillity B clusters at all right now. A 20% cost difference. That's a big number, no matter what you're talking about. And when you consider our plans to scale even further, it becomes even more significant. In the industry we're in, there are only a few major players, Google, Facebook, and then

everyone else. Digital turbine has carved out a chunk of this space, and we have the tools as a company to start competing in whiz others can't. As we gain more customers and more people say, hey, we like what you're doing, we need to scale radically. That 20% cost difference is already significant now, and in the future, it could be massive. Better performance and better pricing, it's hard to ask for much more than that. You've got to wonder why more people haven't noticed this yet. Thank you for listening to this Hackernoon story, read by artificial intelligence. Visit hackernoon.com to read, write, learn and publish.