[audioheavy]

This sounds like an interesting hybrid implementation, and I understand its motivation. However, if distributed writes at low latency with the highest consistency guarantees are essential, combining those two layers (Mongo and PostgreSQL) isn't worth the complexity. It looks like you can administer it with both Mongo and PostgreSQL tools, but do you want to? Clusters, partitioning, replication? That's a lot of heavy lifting.

To fully disclose, I have a biased view on this given that I work for a (closed source) serverless, no-ops DB provider (Fauna) that implements a distributed transaction engine that is natively document-relational and doesn't compromise on relational (ACID, transactional) guarantees. Although not directly comparable to an OSS DB, The market expects software and services to abstract as much complexity as possible. It is hard to imagine how such a Mongo/Postgres hybrid could handle hyper-scale apps that require highly consistent distributed writes.

[peterfarkas]

Thanks for the feedback. Any managed Postgres-compatible database which offers autoscaling works with FerretDB. You don't have to manage the Postgres side if it is already managed [1].

One example would be Yugabyte which is not yet officially supported, but was tested by Yugabyte with FerretDB. Same goes for CockroachDB, which was also tested to some extent. Neon would work, too.

On the other hand, FerretDB may not be a solution for all possible use cases out there, but no database is.

[1]: https://dev.to/aws-heroes/ferretdb-yugabytedb-on-kubernetes-...

https://dzone.com/articles/migrating-mongodb-collections-to-...

https://dzone.com/articles/using-cockroachdb-as-a-backend-fo...

https://dzone.com/articles/experimenting-with-unique-constra...

https://dzone.com/articles/cockroachdb-multiregion-abstracti...