I typically agree but this is based on Postgres which is nearly always a solid bet.

Postgres jsonb works well enough for me - but this looks like a good alternative for Mongo people.

It's of course the translation that can contain bugs. Dumb error in a date conversion? Your accounting no longer works.

That and significant differences in performance for more complex operations like the aggregation framework

Curious about that. I recently made something similar, but for SQLite w/JSON. The backend can use a local sqlite3 file instead of mongodb, while using the same queries. It can only translate the queries we actually use, but it's quite doable to translate $lookup, $group and $project to their SQL equivalents (which were the inspiration for the aggregation in the first place, IIRC). Initial evaluation shows that the performance is quite good, and the translations look decent, so it might be possible to get some mileage out of ferretdb.

Yeah seems like a mix between a ORM and a Database, not sure how much they can let postgres solve. But I agree when I look into it, it's bit less scary then a competely new database.

PostgreSQL isn't a "newly created database"

> FerretDB is an open-source proxy, converting the MongoDB wire protocol queries to SQL - using PostgreSQL as a database engine.

Based on this description I'd agree that FerretDB isn't a database itself. However the conversion between the MongoDB wire protocol to SQL queries could have bugs, data resiliency could be an issue if you need to guarantee writes, No guarantees of on-going support, etc.

New db's are always welcome but to use a brand new one in production would be very.... bold.

The humor is strong in you fellow Jedi