[inkyoto]

> You don't have to support MongoDB, but you can support apps that were only written with Mongo as backend? That's awesome. I can't imagine it's production-ready yet but it's a great idea.

You have just described AWS DocumentDB, which is a Mongo compatible frontend using Postgres as the backend (AWS coyly refer to it as Aurora, though); the wire protocol compatibility is at the version 4.0 level, with some extras thrown in. Change event streams also works like a charm. We have been using it for a couple of years and have found DocumentDB stable, performant with the AWS support being very good. Support for complex compound indices is still missing as well as support for complex query projections is somewhat missing, but we have decided to change ways of how we use use documents instead, so it has not become a major impediment for us.

The main disadvantage, though, is cost, especially for smaller datasets where spinning up a separate DocumentDB cluster quickly turns into a money wasting excercise. Although, for our primary use cases, DocumentDB is still more than 3x cheaper than a comparable Atlas MongoDB PaaS.

[julianlam]

Except DocDB is not a drop-in replacement despite what Amazon says.

People have tried and failed to get our software running on DocumentDB, whereas another developer got it running on CosmosDB with minimal changes upstream.

Not affiliated with MS in any way, just sharing what I've witnessed secondhand.

[inkyoto]

Amazon do not say that DocumentDB is a drop-in replacement, neither do I. Moreover, I have outlined specific incompatibilites between Mongo and DocumentDB we have encountered for our use cases; RBAC controlled document filtering is not available in DocumentDB, either. Therefore, it won't suit everybody.

However, for simple to medium complexity projects, especially for brand new ones, DocumentDB is a viable and a more affordable alternative to Atlas MongoDB with a decent level compatibility.