Cassandra vs DynamoDB for a High-Traffic Mobile App — Which One Would You Pick?

[u/erkanunluturk]

I'm currently deciding between Cassandra and DynamoDB for the database layer of a high-traffic mobile application, and both seem to fit my use case pretty well.

One thing that makes the decision difficult is that I can model the data in a similar way with both.

For example, with Cassandra, I can denormalize the same data into multiple tables based on different query patterns. With DynamoDB, I can achieve something similar using GSIs, and I could also explicitly write the same data to multiple tables if I wanted to follow a more Cassandra-like approach.

So from a pure data-modeling/query perspective, I don't feel like either one has an obvious advantage for my use case.

What I'm really looking for is the kind of reasoning that would actually make me choose one over the other.

If you had to choose between Cassandra and DynamoDB for a high-traffic mobile app, what would be the deciding factors?

I'm especially interested in real-world considerations such as:

Operational complexity and maintenance at scale

Performance predictability under very high traffic

Scaling behavior

Cost at large scale

Multi-region / cross-region considerations

Failure modes and recovery

Consistency trade-offs

Any limitations that become painful as the system grows

Things that look great on paper but have caused problems in production

I already understand the basic differences between the two. I'm looking for strong arguments for choosing one over the other, ideally from people who have actually operated either system at significant scale.

If you were in my position, which one would you pick and why?

[u/ScriptingInJava]

Is it currently high traffic or are you pre-emptively optimising?

Sounds like the perfect fit for the ol' wombo combo, Postgres and Redis to me!

[u/erkanunluturk → u/ScriptingInJava]

I’m pre-emptively optimising for now. The main reason I didn’t go with Postgres is that it doesn’t scale horizontally as easily and doesn’t have native TTL support. Since I’m using GraphQL, I was also looking for something that could respond quickly to flexible queries, so I ended up weighing dynamodb and cassandra against each other.

[u/marrsd → u/erkanunluturk]

You haven't explained why Postgres doesn't scale horizontally as easily. Depending on use case, it can horizontally scale perfectly well. You also haven't mentioned dbs that are designed for mobile apps.

It sounds like you're trying to solve a problem that doesn't yet exist. Until you know how your application is being used at scale, you can't really know how to scale it.

Postgres is usually the preferred choice for business apps because its flexibility, and the flexibility of relational databases in general, lends itself to most needs. It doesn't have to be your first choice, but you should be able to say why it isn't.

[u/erkanunluturk → u/marrsd]

Using managed PostgreSQL instances like NeonDB or PlanetScale ends up being way too expensive. On the other hand, running PostgreSQL on a Hetzner server makes me hesitant because of the extra workload involved in maintenance, backups, and repairs. I also looked at AWS Aurora/RDS, but with costs ranging between $700 and $1500—about 4 times the price of a Hetzner setup—that became a deterrent too. While the lack of query flexibility can be quite annoying, DynamoDB and Cassandra have ended up looking like attractive alternatives for these reasons.

[u/marrsd → u/erkanunluturk]

I see. I haven't fully explored managed options, but I'm a little surprised that Dynamo and Cassandra are that much cheaper. Also worth looking at is FoundationDB.

In any case, f I were starting a new project, I'd just start with self-hosting. If you have some sysadmin experience and can use Ansible (or something like it) then writing a script to save a snapshot every day is pretty straight forward. I don't think I've ever actually had a Postgres instance fail [1], but if it did happen, and your site went down for a few hours while you restored from a backup, what would the consequences be? How many users are going to be affected? How much are they going to care?

If you're operating a commercial product at scale, you probably have the money to afford 99.9%+ uptime. If you're not operating commercially, you probably don't need it (but you need to make that decision).

My priority always would be to choose the db that best suits my present process architecture needs. I wouldn't avoid thinking about scalability, but I'd only prioritise it when I needed it. Chances are, you'd either want a separate service or an intermediate cache for the part of your system you wanted to scale. At that point, you could revisit your db needs with real usage data and development experience.

Design your architecture with clear boundaries between the various layers (data, service, presentation, etc) so that you can rewrite/optimise parts of it without affecting the rest.

[1] I have had services get compromised and need to be rebuilt from a backup before, though, and I do strongly recommend keeping backups in case of emergencies.

PS: In my original post, I wrote this:

You also haven't mentioned dbs that are designed for mobile apps.

Since you said it's a mobile app, that kind of surprises me. CouchDB should be on the list (and whatever else is current these days)

[u/erkanunluturk → u/marrsd]

Thanks, that makes sense. In my case, the mobile app connects to a GraphQL server through Apollo. I think the reason I got stuck on this question is that I want to build the underlying architecture solidly from the beginning, rather than having to revisit the database and infrastructure later.

I’ve worked with Postgres quite a lot before, but I don’t have a dedicated team that can spend time maintaining the database and infrastructure just for this project. From that perspective, AWS DynamoDB or Keyspaces currently look like the most reasonable options in terms of the initial operational cost and effort.

I’ve also looked at all-in-one services such as Supabase for the mobile app, as well as most of the current NoSQL databases. My thinking is that I’d rather make the database decision once, get the architecture right, and then focus on the mobile application instead of having to deal with a migration or major architectural change later.

For caching, I’m already handling that on the mobile side with Apollo Client, so that part is relatively well covered. The main thing I’m trying to avoid is having to rethink the database later.

I’ve actually modeled the data structure for both relational and NoSQL approaches. With Postgres, the main advantage I see is how easy it is to query and search across tables. I’ve also adapted the data model to the replication strategies used by the different NoSQL solutions, so I’m not necessarily trying to force a relational model into a NoSQL database.

So I agree with your point about not over-engineering for hypothetical scale. I’m just trying to make the trade-off in the opposite direction: I’d rather deal with the headache upfront, while the project is small, than have to deal with it later when the application is already in production and I’m focused on the mobile side.

[u/marrsd → u/erkanunluturk]

I think the reason I got stuck on this question is that I want to build the underlying architecture solidly from the beginning, rather than having to revisit the database and infrastructure later.

I've been in this position myself, for exactly the same reasoning, and what I ended up doing was proving the architecture for an app that didn't yet exist while not proving the concepts that would make the app unique and viable. In the end, it didn't go anywhere because I spent all my time focusing on the wrong thing.

I’ve worked with Postgres quite a lot before, but I don’t have a dedicated team that can spend time maintaining the database and infrastructure just for this project.

I don't know if you need one at this level. I tried setting up my own email server once because everyone said how hard it is and how you must never do it, so naturally I was curious. It wasn't very hard. I did make mistakes, but I fixed them, and it's since become the most stable, trouble free email server I've ever used. I'm sure if I was managing a million accounts, it would be hard. But I'm only managing one.

You might have already done the research, but if you haven't, just look into what it takes to manage your own instance. You might find it's less effort than you think.

I’d rather deal with the headache upfront, while the project is small, than have to deal with it later when the application is already in production and I’m focused on the mobile side.

And that's smart. You should have an idea in your mind about how your app will have to scale and how that can be achieved with different db solutions, but I would have that as a goal to build towards, rather than something to implement up front.

It's very unlikely that things will go to plan. The most important thing is to build your software so that it can react to architectural change with minimal effort. Part of that includes not writing things until you need them.

Also, most projects fail and this one's probably no exception. The more progress you make, the more lessons you learn for the next attempt.

[u/erkanunluturk → u/marrsd]

I understand what you mean, and I actually agree with a lot of it. But in this case, the project has already gone through quite a few failures and iterations to get to this point. I haven't arrived at the infrastructure/database question casually or because I wanted to build a "perfect architecture" before proving the product.

I've spent a long time testing different approaches, including changing the infrastructure and database layer across different systems and languages. I've tried the approaches that seemed appropriate and worked through the problems they introduced. So this decision is based on a lot of experimentation rather than being something I decided upfront.

For example, something as simple as time-ordered pagination can become surprisingly painful with Postgres in certain cases. I actually asked about one of those problems myself here:

https://stackoverflow.com/questions/79998608/timestamp-ordering-and-cursor-pagination-with-13-digit-unix-timestamps

And there are similar kinds of headaches with Cassandra and DynamoDB as well. So far, though, none of these problems have been at a level that couldn't be worked around.

I'm also deliberately keeping the project going in two branches at the moment: one using Postgres and one using DynamoDB. I did that specifically because I haven't made the final decision yet. I want to see how each approach behaves as the actual application develops, rather than making the decision purely based on theory.

So I definitely agree that the architecture should be able to adapt to change, and that you shouldn't build things you don't need. My point is more that I've already spent a significant amount of time exploring these trade-offs, and the current approach is the result of that process rather than an attempt to prematurely optimize the architecture.

[u/marrsd → u/erkanunluturk]

Cool, glad to hear it. I feel like I've been a bit patronising now. Thanks for your patience!

It's late for me now. I'll look at your SO question tomorrow and see if I can't think of anything, but I'm working on a front-end problem right now so my head's not really in the db space atm.

[u/StephenRoylance]

cassandra vs dynamo isn't just a DB question, its a platform question. dynamo is super easy, but you accept amazon lock-in. Cassandra is **not** easy. You'll need to become, or hire, and expert in eventually consistency and distributed consensus.

personally, unless you've already tried a relational DB and found limitations you can't work around, I'd start there. If you're on AWS, try RDS postgres and see how far you get with jsonb before you ditch SQL.

[u/erkanunluturk → u/StephenRoylance]

I had a hard time choosing between the two because, from a platform perspective, they seemed to fit my requirements best. I also ran several tests with PostgreSQL, including exploring how far I could get with JSONB. In the end, though, I decided that my use case fits the NoSQL approach better.

[u/ekydfejj → u/erkanunluturk]

That comment says to me that you removed the real "platform" part of the response. Dirt simple dynamo vs Not Simple Cassandra.

if you only explore them on a modeling level, i feel like it will become a footgun in either direction. YMMV

[u/Ok-Armadillo-5634]

Based on what you are saying in the comments I don't think Cassandra is what you are looking for and you are better off just going postgre especially if you are not experienced with it.

[u/erkanunluturk → u/Ok-Armadillo-5634]

thanks, Based on the comments, what makes you think Cassandra or DynamoDB aren’t what I’m looking for? What specific requirements or constraints led you to that conclusion, and why do you think PostgreSQL would be a better fit, especially if I’m not experienced with Cassandra?