Transitioning database is painful, but dealing with the extra complexity of non-ACID stores can inhibit your growth. If you reach the scale where you need to change, you'll probably be able to afford more developers to help you.
I call shenanigans on that - Google's experience was that they tried it and then got bogged down as every developer had to roll their own mechanism for waiting for syncs - hence they developed F1 instead...
They're approach is to use a Key-Value DB to build a linear-scaling PostgreSQL-like Database.
Personally, I'm just waiting for that to become a bit more stable, but it's probably the most promising in this regard and already very usable.
This is quite arguable. Before the Computer Era, all businesses, including the whole financial sector did just fine without ACID. Still, ACID is used only at a local scope. I can often see ACID requirement used rather as an excuse for poor data modeling than a real need.
Can you elaborate a bit? I believe that in the pre-ACID world, business processes were much slower, not online processes like today. When you're only really changing data once a day, backups and manual intervention are acceptable options.
> Still, ACID is used only at a local scope.
What do you mean by "local scope"?
As for "local scope" I meant "at a single business entity". If you look at a banking or online payment systems as a whole then they are not ACID, they are eventually consistent. The are based on two basic principles:
1. write everything down at least two times, so you never lose data
2. updates are incremental, so you never overwrite data
Of course when you want stuff to happen at a faster-than-human timescale - or when you just want lots of stuff to happen - an ACID model might not be the right fit.
> As for "local scope" I meant "at a single business entity".
Understood.
http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...
http://www.enterpriseintegrationpatterns.com/docs/IEEE_Softw...
The standard of the time looks quite ACID-y to me:
https://en.wikipedia.org/wiki/Double-entry_bookkeeping_syste...
The cost: transactions, relations. These are actually incredibly valuable things to have.
If you're storing billions and trillions of records that don't need relations, NoSQL is great. You'll keep your fast lookups and saves no matter how big things get.
This can matter a lot more if you're a start up with the goal of having trillions+ records some day. Your SQLServer will eventually not be able to scale any higher, and then what? Moving to Nonrelational from relational is so painful.