4 ms·

Couldn't agree more - just like NoSQL vs regular old SQL - don't assume you need a NoSQL solution, until you actually prove you need it. probably 90-97% of solu

by ejb999 5y ago

Couldn't agree more - just like NoSQL vs regular old SQL - don't assume you need a NoSQL solution, until you actually prove you need it. probably 90-97% of solutions will be better off with a relational database; boring yes, but they 'just work'. Choose NoSQL only when you need them, choose micro services the same way. If you 'think' you need NoSQL or a MicroService architecture - chances are you don't.

malandrew 5y ago
> don't assume you need a NoSQL solution Likewise, people who only know relational DBs shouldn't assume they need an SQL solution. It's remarkably rare that you encounter engineers with real thoughtful experience with both and they have the experience to know which tool to pick up for different problems.
travisgriggs 5y ago
I don’t think I need NoSQL. It’s just that I hate having to map my structured data into tables and rows and joins and schemas and primary keys. A document|object|key-value store just usually maps better to the data I’m trying to model than a trumped up spreadsheet that requires me to speak a foreign language to it. Other’s mileage may vary of course. Just been my experience in the domains I’ve worked in. (Ironically, I agree very much with your general sentiment, just not the example of illustration you chose)
- AndrewDucker 5y ago
  You can do those in most SQL databases too, with the option of structured data if some of your data fits it
- projct 5y ago
  > having to map my structured data into tables and rows and joins and schemas and primary keys You don't have to. You can just use JSONB.
deepfriedrice 5y ago
I wish I could justify using SQL more. It's just way too easy to use Dynamo. Unless my data is complicated enough to warrant a relational model, it's going in Dynamo.
- ejb999 5y ago
  I don't disagree, it is so easy to build solutions on tp of dynamodb - and then I regret it when the access patterns change and the solution falls apart -thats when I wish I had stuck with tried-and-true relational. That is kind of the problem, DynamoDB - and other NoSQL database - allow you to just start building your app, without any real thought about what data you will need and how it will be used - but you are often shooting yourself in the foot to not map this stuff properly out in advance.

by ejb999 5y ago

malandrew 5y ago

> don't assume you need a NoSQL solution Likewise, people who only know relational DBs shouldn't assume they need an SQL solution. It's remarkably rare that you encounter engineers with real thoughtful experience with both and they have the experience to know which tool to pick up for different problems.

travisgriggs 5y ago

I don’t think I need NoSQL. It’s just that I hate having to map my structured data into tables and rows and joins and schemas and primary keys. A document|object|key-value store just usually maps better to the data I’m trying to model than a trumped up spreadsheet that requires me to speak a foreign language to it. Other’s mileage may vary of course. Just been my experience in the domains I’ve worked in. (Ironically, I agree very much with your general sentiment, just not the example of illustration you chose)

AndrewDucker 5y ago
You can do those in most SQL databases too, with the option of structured data if some of your data fits it
projct 5y ago
> having to map my structured data into tables and rows and joins and schemas and primary keys You don't have to. You can just use JSONB.

deepfriedrice 5y ago

I wish I could justify using SQL more. It's just way too easy to use Dynamo. Unless my data is complicated enough to warrant a relational model, it's going in Dynamo.

ejb999 5y ago
I don't disagree, it is so easy to build solutions on tp of dynamodb - and then I regret it when the access patterns change and the solution falls apart -thats when I wish I had stuck with tried-and-true relational. That is kind of the problem, DynamoDB - and other NoSQL database - allow you to just start building your app, without any real thought about what data you will need and how it will be used - but you are often shooting yourself in the foot to not map this stuff properly out in advance.