You can have non-ACIDic SQL databases and ACID NoSQL databases.
While it is true that many KV stores do not present a fully consistent view over distributed data, there are some that do.
It is very important that people shed this idea that only SQL databases can have strong consistency, that's for sure.
Why? In practice, people are going to be building things using the same common paths: Postgres, Mongo, MySQL, Redis, etc., and from a purely pragmatic standpoint, the SQL databases that you're likely to use come with strong ACID guarantees while the NoSQL databases don't.
If you can point me to a NoSQL data store that provides high availability, similar atomicity, consistency, and isolation properties provided by a strong isolation level in Postgres/MySQL/Oracle/SQL Server, and has a good track record of production use, I'm all ears.
I use it in production for a game that supports over 100,000 concurrent users and it's been around for a very long time.
It's fully ACID by default but you get the ability to drop elements of ACID in exchange for greater performance in a per table or transaction level. It also supports two different isolation approaches on a per table level. Locking or MVCC (like postgres).
It's a really great NoSQL database from the days before the term NoSQL existed.
https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...
Still there are plenty of highly distributed stores to go around, and it's good to know that people are actively using them with great success.
It's very nice to have fine control over consistency vs performance even if you do have to think about it as a developer, but then that's our job :-)
LMDB has taken its place in a lot of projects that used to use Berkeley.
which was inspired by this paper:
http://research.google.com/archive/spanner.html
which google made available for all in form of it's cloud datastore:
https://cloud.google.com/datastore/
"We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions." [1]
[1] http://highscalability.com/blog/2012/9/24/google-spanners-mo...
[1] http://realm.io
I haven't used it in a few years, but from what I remember you could have ACID like operations on grouped entries because grouping them makes their physical storage the same so ACID transaction becomes a localized operation.
ACID transactions
Consistency is always relative to what the DBMS can enforce, which is in turn always relative to what the the DBMS's schema language can express. A KV store can be trivially consistent in that, between writes, it always presents the same view of the data. But it won't be consistent in the sense of presenting a view of the data that's guaranteed not to contradict your business rules. The latter is what users of relational databases expect.
On the other hand, SQL makes it hard to maintain the state definition, I had to develop a mechanism to upgrade the DB from any possible state to the latest state.
Still, this allows me to define very accurately what is a valid row or entry in the database, which means my Applications need to make far fewer assumptions.
I can just take data from the DB and assume with certainty that this data has certain forms, formattings and values.
MongoDB makes none of these guarantees.
A lot of developers don't want to do that, because they want to think of data integrity as this tangential concern that's largely a distraction from their real job. A lot of developers also have a habit of cursing their forebears on a project for creating all sorts of technical debt by cutting corners on data integrity issues, while at the same time habitually cutting corners themselves in the name of ticking items off their to-do list at an incrementally faster pace.
This isn't to say that NoSQL systems make your system inherently less maintainable. But I do think NoSQL projects gained a lot of their initial market traction by appealing to developers' worst instincts with sales pitches that said, "Hey, you don't even have to worry about this!" and deceptively branding schema-on-read as "schemaless". So a reputation for sloppiness might not be deserved (or at least, that's not an issue I want to take a position on), but, in any case, it was very much earned.
Reading your comment reminds me of ESR's point in The Art of Unix Programming that getting the data structures right is more important than getting the code right, and if you have good data structures, writing the code is a lot easier. The database is just a big data structure, the foundation everything else is built on, and the better-designed it is, the easier your code will be.
When I get data from a well validated DB, I don't have to check that it is valid or has certain formats, that is ensured by the DB.
I can remove checks from the entire CRUD stack, if it's invalid data it does not get created or won't make it into the update.
The easiest way to check data is then to try the INSERT or UDPATE and if it works it's valid.
Otherwise I'd need to validate all fields, see if any contain errors, if any are missing, etc etc.
And I love it to death for it.
It also allows me to do some nifty little tricks.
I've developed my own Migration Tool that works by exploiting this data integrity, it actually aids me to identify and upgrade the database dynamically without worrying about which updates are applied and which not.
Surely I get the feeling, NoSql just exposed the issue and became synonymous with it.
The truly nefarious aspect of NoSQL stores is that the problems that arise from giving up ACID often aren't obvious until your new product is actually in production and failures that you didn't plan for start to appear.
Once you're running a NoSQL system of considerable size, you're going to have a sizable number of engineers who are spending significant amounts of their time thinking about and repairing data integrity problems that arise from even minor failures that are happening every single day. There is really no general fix for this; it's going to be a persistent operational tax that stays with your company as long as the NoSQL store does.
The same isn't true for an ACID database. You may eventually run into scaling bottle necks (although not nearly as soon as most people think), transactions are darn close to magic in how much default resilience they give to your system. If an unexpected failure occurs, you can roll back the transaction that you're running in, and in almost 100% of cases this turns out to be a "good enough" solution, leaving your application state sane and data integrity sound.
In the long run, ACID databases pay dividends in allowing an engineering team to stay focused on building new features instead of getting lost in the weeds of never ending daily operational work. NoSQL stores on the other hand are more akin to an unpaid credit card bill, with unpaid interest continuing to compound month after month.