MySQL and Postgres are awesome for a lot of what websites do. They have advantages and disadvantages. Things like sharding tend to be premature optimizations except for write-heavy sites running at high scale. I prefer a mixture of SQL and NoSQL for the projects I work on. Redis, especially, is great at things like atomic updates and counters that become cumbersome in sql. With a well architected model-layer the complexity of multiple datastores can be minimized significantly. By using the right tools for the job, we are often able to simplify even versus using one database and a hacky solution.

Isn't updating a counter in SQL just: update counters set amount = amount + 1 where id = something?

In a basic application yes this is true. But if you have a large cluster and data is spread out it becomes more difficult not to mention time consuming to run that query. With redis and other nosql solutions they are designed with this in mind so they are much faster and easier.

Don't check for overflow. Simply use a data type so large that it would take centuries to overflow.

If you were doing a million increments per second it would take almost 600,000 years to overflow a 64 bit int.

Check your assumptions. The field could be updated at any time to any value by another connection.

And who's to say we started at zero.

My background is business-first, hacker-second, and I mainly read everything on HN to pick up little places not to fuck up when architecting a software business.

The benefit of NoSQL's ease of dropping/adding schema...that's going to be one of the better ones.

I hope your code is compatible with mixed schemas. Otherwise your NoSQL is just moving the problem somewhere harder to test.

Can't vote this up enough.

The use of NoSQL is for very specific scenarios, don't make the mistake of thinking it's a good object store replacement. As a business guy this is definitely not a decision you should be making, let your team use what they're happy with, they'll get a lot more done that way.

I refer to this as the database making you eat your vegetables.

"I just want to change this tiny thing, what could possibly go wrong?"

"Nein!" shouts the database. "It will violate this and that and the other rule you told me to enforce!"

"Stupid database, always getting in my way. I'm going to install MongoDB/Redis/Couch ..."

12 months later: "Hang on ... which version of the code were these 40,000 records entered under? Does that integer field refer to the protocol 2 or protocol 3 headers? Why is there some XML in the email field?"

LOL. Awesome analogy. Muchos gracias to your reply and everyone else's.