I found that PostgreSQL was good for all of the cases I would use with NoSQL. Even on AWS, I found Dynamodb's query language really unintuitive. There will be use cases for NoSQL but for the 99% cases, it doesn't make much sense.
I use DynamoDB for most production workloads. With that said, I really miss the ability to run ad-hoc queries against a relational database.
Joins can be baked in to DynamoDB for application access patterns - but frequently I (or product/sales) want to know "how many people with X also have Y", which is really hard to do with DynamoDB.
> NoSQL databases don’t offer much in the way of transaction management or real coding. They are great for storing data that doesn’t change much or changes minutely with every transaction.
Sure, that's fair, because it's an "eventually consistent" database. It's not intended for transactions that need to be validated and enforced immediately, because it is not ACID compliant. I think the solution here is to simply not use it for that. Use it for what it was intended for - data that is okay to be eventually consistent, which does not include financial transactions and the like. The value of eventually consistent databases is much more apparent in transactions that do not require immediate consistency, such as a friendship status.
To exemplify this, imagine someone changes their status to say, "You're not my friend anymore." The database will eventually show everyone that the person in question is no longer your friend, but in the meantime, people aren't going to be double-spending because you decided that you don't like someone anymore.
> Further, understanding the NoSQL model is difficult for developers used to coding for SQL systems.
Presumably, these are intelligent people, and I would argue that the concept of "eventual consistency" and the ramifications of that, aren't really that hard to grasp. If you need something now, then you know what to do (you need an ACID compliant database). If you're able to wait, then you know what options you have available to make things better.
8 comments
[ 3.2 ms ] story [ 28.1 ms ] threadJoins can be baked in to DynamoDB for application access patterns - but frequently I (or product/sales) want to know "how many people with X also have Y", which is really hard to do with DynamoDB.
Sure, that's fair, because it's an "eventually consistent" database. It's not intended for transactions that need to be validated and enforced immediately, because it is not ACID compliant. I think the solution here is to simply not use it for that. Use it for what it was intended for - data that is okay to be eventually consistent, which does not include financial transactions and the like. The value of eventually consistent databases is much more apparent in transactions that do not require immediate consistency, such as a friendship status.
To exemplify this, imagine someone changes their status to say, "You're not my friend anymore." The database will eventually show everyone that the person in question is no longer your friend, but in the meantime, people aren't going to be double-spending because you decided that you don't like someone anymore.
Presumably, these are intelligent people, and I would argue that the concept of "eventual consistency" and the ramifications of that, aren't really that hard to grasp. If you need something now, then you know what to do (you need an ACID compliant database). If you're able to wait, then you know what options you have available to make things better.