![]() Migrating to a different database is certainly a very costly operation. Thus, starting with DynamoDB, is at the best a premature optimization. Once again, the probability to underestimate the potential growth of a service is very low, since most of the service do not land where we want them to be. In the fortunate case in which it does, a relational database might impact service growth, requiring engineers to perform a painful migration to NoSQL, which ultimately will impact speed of delivery for new features.ĭoes the cost of a possible migration always outweighs the upfront cost required for NoSQL, even if you might never benefit from its features? It's hard to tell if something is going to succeed or not. Used by a well known population, company internal tooling, niche service, etc.) When the potential growth is easier to determine, deciding which solution to pick becomes straightforward (system is going to be It's more rewarding being able to iterate on ideas as fast as possible in order to increase the likelihood to finally get to the successful one. Most new ideas fail or they do not have the expected customer impact.īased on this intuition, the probability of a service growing above the supported use cases of a relational DB like Aurora is very limited. In the following section I am going to explain why I believe this might the wrong trade off to make. In other words the trade off to make is between the potential growth of a service versus speed of development: when using DynamoDB for applications with a low/medium TPS and a fairly ambiguousĪccess pattern, the argument is to favor potential growth against speed of development. Using a database that better matches an application's needs will improve programmer productivity. Using DynamoDB in sub optimal use cases has a big disadvantage: engineering costs and speed of development. ![]() So it looks like, DynamoDB covers all the possible use cases, thus we should always use it. Access pattern is not understood or it might change in the future.High storage requirements (i.e, Big Data, etc.)ĭynamoDB certainly works also in the complementary use case:.By contrast, in relational databases you can always write a new query or create new tables when you need it Access patterns is clear (or can be clarified) from the get-go. ![]() What are the use cases in which DynamoDB shines? Plenty of words have been written on the topic, the interested reader will find more information in the reference section. I am only going to go over the main use cases. Thus the first thing to verify is that DynamoDB violates the assumption of being superior to a relational database in almost all the use cases. As any other database, it shines in some use cases and might be overkill in others. If X produces good results in almost all the cases, then it is beneficial to always use it.īecause the majority of use cases benefit from it and the cost of not using is extremely high, it should be enforced by a rule or a policy.Īlthough I agree with the general statement, I think it is not applicable for DynamoDB. The argument pro using DynamoDB in all circumstances is based ![]() To my surprise, I was the only one to disagree with the statement and my arguments were not convincing enough to inspire in them second toughs.Īfter my unsuccessful attempt to convince them, I set myself to better understand their argument and to elaborate mine. One of the ideas which bounced around the room was to always use DynamoDB even when a relational database would be a better fit. We discussed about DynamoDB vs managed relational database (like RDS and Aurora) and which one to pick in use cases where both could work. A few days ago, I ended up discussing with some friends
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |