Gyakorlatilag ezt: https://cloud.google.com/spanner . Most látom, hogy van PostgreSQL interfésze, szóval a kérdezőnek is jó lehet. ACID, alig van kompromisszum a CAP miatt, és tényleg veszettül skálázódik. Földrajzilag replikált, egy adott helyszínen pedig clusterként skálázódik automatikusan (pl. egy-egy szerver bizonyos táblák vagy sorok egy adott halmazáért felelős). Valahol hallottam, hogy a CockroachDB is hasonló elvek szerint épült fel.
Mivel mi viszonylag lassabb (100-1000ms) tranzakciókat futtatunk, ezért optimistic concurrency controlt építettünk köré, de pessimistic locking módot is tud. Mindkét esetben garantált, hogy ha írunk, akkor az abban a tranzakcióban olvasott adatok konzisztensek és más nem vágta felül. Okosan kell kezelni azt, hogy ha transaction conflict hibát kapunk, milyen szinten próbáljuk újra. Olvasás esetén lehet választani, hogy nagyon friss adat kell, ami lassabb, vagy kicsit régebbi is jó, ami gyorsabban elérhető (ez utóbbi az eventual consistency), illetve timestamp-ek kezelésével read-after-write consistency is elérhető. Külön öröm, hogy lehet adott időpontbeli állapotot olvasni, mert minden adat verziózott. Ezek egy része sok embernek szokatlan, de a valóságban mindig kiderül, hogy némi kompromisszum belefér a követelményekbe, cserébe még gyorsabb lesz. De mindez opcionális, lehet ilyen dolgok nélkül is buta adatbázisként használni, csak akkor kicsit lassabb és néha fog furcsa hibákat produkálni.