It had/has a cool name which is why an lot of people adopted it.
But they had no idea it was really an in-memory database with inconsistent writes.
We accidently purchased a backup solution that did de-duplication and file-structure virtualization. Yep, you guess it, based on MongoDB, where all the backup data was stored. The memory sizing advice from the vendor was approximately equal to the number of (Windows) clients times 4GB each. Have 100 clients, have half a terabyte of RAM (remember you can only purchase halves or quarters, not fractions.)
We non-accidently shipped to a few customers (as part of a much larger system) and boy were we embarrassed. The backups failed to complete because the VM hosting the backup software locked up for lack of memory (we gave it 16GB for five clients. Five.) (It spent all it's time paging to the database files. Seems "dedup" meant "compare and contrast with the entire set of blocks ever seen.)
And some customers of course noticed, mostly because the status was on the dashboard we supplied.
Oopsies....time to retire!
(I think the second, or third parameter of PostgresSQL server configuration is....how much memory it can have! That is exactly what is needed. Good luck to the folks at FerretDB, they have a lot TAM to address here.)