SQL or NoSQL? These days it's a religious argument (tabs vs spaces, anyone?) I've been using SQL since the late 80's, and spent several years working with NoSQL offerings. There were some really great things about using a document-based database -- mainly being able to take a block of JSON from my front-end app and throw it into a database. That was great.

But over the years, some of my NoSQL projects made me start to yearn for those things that are super easy to do in SQL, but can be a pain with a document database. Quick aggregate queries to answer business questions: How much did we sell of this product last month in each region? Or I'd want to change the schema of my data, and it would be a pain to do that in a document database. I'd have to write a script to migrate the data, and then I'd have to change my code to use the new schema. Or else my code started filling up with code to manage the schema. if (typeof total_sale !== 'undefined')...

Once I figured out that it's easy to throw JSON data into Postgres, I was able to get the best of both worlds. I'm not saying SQL is always better -- it totally depends on the application and what your needs are. But I've also been bitten before by "oh this is easy to do in NoSQL because the data is just a simple document" followed three months later by "the app is working great -- but now can we do X, Y, and Z?" And I'm thinking "why didn't you ask for those things before we built the app? I should have done this in SQL." Ugh.

Your comments and questions are welcome!