Honestly... if you have figured out how to scale with full ACID... I have a hard time believing that having SQL support in there is going to "kill" your ability to scale.
I'm guessing that no-SQL documents are written at a more course granularity than SQL table rows. One document could well represent 3, 4, 5 rows in a normalized SQL database.
OTOH, if you put all your "documents" in 3rd normal form, you might not see much gain.
You are right. Our API is strong enough that you could implement a SQL database on top of it efficiently. I have done it (using sqlite4 as the front end) as a proof of concept.
Comments
Honestly... if you have figured out how to scale with full ACID... I have a hard time believing that having SQL support in there is going to "kill" your ability to scale.
I'm guessing that no-SQL documents are written at a more course granularity than SQL table rows. One document could well represent 3, 4, 5 rows in a normalized SQL database.
OTOH, if you put all your "documents" in 3rd normal form, you might not see much gain.
The overhead with transactions doesn't come from the fields being in different tables...
You are right. Our API is strong enough that you could implement a SQL database on top of it efficiently. I have done it (using sqlite4 as the front end) as a proof of concept.