Hi there, we are mostly targeting analytic use-cases with this. SQL already has a lot of analytics functionality built into the language, so we thought it might be interesting to enable it.
* We find that in the context of analytics, transactions aren't as important (they are still relevant, but people are OK if results are a bit off).
* For the MongoDB sharding model, CitusDB already keeps similar metadata and moves around shards accordingly. By syncing MongoDB's config server metadata to the CitusDB master, we can ensure that shards are moved around properly. We can also run queries across shards using this metadata.
And thanks a bunch for the encouragement. As you noted, we think of this as addressing some interesting use-cases, and are looking to get the community's feedback.
Your idea is great, but you will end up with average Joe using it for other cases thus MongoDB will be nontransactional database engine with SQL interface and sharding feature, which will be much slower and will have less features than any other RDBMS with proper replication funcionality.
* A big benefit for SQL are transactions, I have a hard time seeing anything done efficiently with MongoDB.
* Additionally, joins cannot be consistent with the MongoDB model (shards, reading from secondaries, ...).
While this idea is charming, I don't see this reaching any serious production environment.
But it's cool, Citus implemented a somewhat working prototype which is useful for some use cases. Kudos ! :)