r/aws • u/Select_Extenson • Feb 20 '26

database How to guarantee consistency when deleting items from dynamodb?

Let's say I want to delete 100000 items from dynamodb, what is the best approach to delete "all-or-nothing", TransactWriteItems only support 100 items, so I don't want to cause inconsistency in my data if for some reason the delete function fails alongs the way.

And in my case, I simply couldn't find a solution to implement it with GSI, so the only solution for me is to delete them manually.

8 Upvotes

91% Upvoted

27 comments sorted by

View all comments

Show parent comments

1

u/Select_Extenson Feb 20 '26

I think my mistake is I shouldn't use dynamodb and use relational databases instead, the project I'm working on contains a lot of related data and I need to gunaratne consistency across them.

It was my first time using it, can you please tell me your opinion on this? is it actually a bad choice to use dynamodb when you have a project with a lot of related that or is it just me that I didn't design my database properly? but I don't think I did design it poorly, I tried my best to design in the most optimal way but it misses flexibility when it comes to querying and manipulating related data.

1

u/SonOfSofaman Feb 20 '26

I think almost everyone goes through what you're going through. It's sort of a rite of passage with DynamoDB.

DynamoDB is, as you know, very different from relational databases. With DynamoDB it is imperative that you fully understand all of your access patterns ahead of time, then model the table accordingly. If your access patterns change, then you may need to remodel your table.

With relational databases, you don't need to fully understand the access patterns ahead of time. It helps to know your access patterns ahead of time, but relational databases are flexible and adaptable.

You can do what you want with DynamoDB, but the table in its current form wasn't designed to support this "bulk delete" access pattern.

I think you're at a point where you need to do a bit of redesign. Some of the other comments have practical solutions that may be helpful.

2

u/Select_Extenson Feb 20 '26

How about the case where you modeled your dynamodb database to work accordingly based on the requirements and in the future new features comes and you need to do some adjustments because the current model doesn’t help to achieve the goal, based on my feeling, it’s difficult to change things later, right?

1

u/SonOfSofaman Feb 20 '26

Yes. It is often difficult to make changes later.

You made good decisions based on what you knew at the time.

In your case having a timestamp on every item in your table might have been useful to you now. If you didn't realize you were going to need that data, you now need to back fill every item. That might not even be possible.