Developer here (woke up surprised it was on hn again), why not?

The blog posts go into more details: http://legitimatesounding.com/blog/building_a_mongodb_clone_... and http://legitimatesounding.com/blog/building_a_mongodb_clone_...

I suspect there are lots of people who built applications on top of MongoDB who would like to transition away from Mongo onto a different database, or would at least like the option to be able to to. This may provide a good mechanism for a transition.

Which leads to a question for the OP: does this work with mongoose.js?

i started a mongo client implementation in node.js, but it fell off my radar - the goal was to get it to work with mongoose, etc: https://github.com/JerrySievert/mongolike-client (it is not yet complete).

in the end, i just wrote my own database system, with a query language that could act as an intermediary from multiple sources (SQL, mongo, etc).

but, this stuff is mostly just for fun, my day job keeps me plenty busy.

Could be interessting for meteor.com, the mongodb only usage prevent me to use it.

problem : meteor relies on a specific mongodb feature,ie polling the db for any change. I heard there is experimental support for PG but it seems to rely on a complex hack using triggers ... So the issue isn't really about mongo queries, but whether it is possible to track db edits from third parties or not.

There's infrastructure for that in postgres, since 9.4. See

http://www.postgresql.org/docs/devel/static/logicaldecoding.... for the (somewhat low level) description of the feature. You'd have to write an output plugin that formats the output as json, but that should be pretty easy.

Disclaimer: I'm the author of the feature ;)

That specific MongoDB feature is "tailing the oplog", where the oplog is the capped collection with the idempotent commands that represent the changes in the database. This is what Meteor uses to receive (be pushed) changes (not polling).

Certainly, logical decoding provides the necessary infrastructure to implement it (and also normal tailable cursors): thank you Andres, really nice work! :) But some work is also needed to transform the representation you are using in PostgreSQL into MongoDB's oplog entries.

This is definitely what we are using in ToroDB to emulate it (currently, under development).

> I suspect there are lots of people who built applications on top of MongoDB who would like to transition away from Mongo onto a different database

What happened to separating the data access layer from the business logic layer? Oh yeah, "good architectural practices are so JEE ..." /s

Taking full advantage of the capabilities of the data layer has effects on the business logic layer. Sometimes it's worth it, sometimes it isn't.