Hacker News Reader

Comment by onetwotree | Hacker News Reader

Frankly, if I were tasked with integrating existing BI tools with MongoDB, I'd immediately start looking at ways to "escape" the anemic Mongo ecosystem to something a bit richer. A Postgres FDW seems like an excellent design.

Of course, I'm a bit of a Postgres partisan, and a Mongo refugee, but it still seems like a solid engineering decision and most of this guys arguments seem to hinge on "BUT POSTGRES IS TEH ENEMY!".

View on HN

Well, you might start off down that path, but eventually you'd find that if you try to execute analytics via PostgreSQL via FDW via Multicorn via MongoDB, you're only able to push conjunctions of simple relational operators on original (non-derived) fields in the source collection.

What that means is virtually any query will end up executing (via PostgreSQL via FDW via Multicorn via MongoDB) by first pulling out all (!) the data from all (!) source collections, relocating it to MongoDB, and then executing the query. Possibly, in fact, these full collection scans might be repeated multiple times, especially for nested data, crosses, and other types of operations.

And then you'd decide that "solid engineering decision" wasn't so solid after all. Then hopefully you'd quit MongoDB and go work on PostgreSQL full time. ;-)

We have a legacy app that runs on Mongo. For MI/BI reasons we implemented pretty much the same thing about 18 months ago, first with Citus DB's excellent mongo_fdw and then with Stripe's mosql.

That application is currently being rewritten on top of PostgreSQL.

I think the guy's argument is more "but you should have used my product insteeeaaaadddd"

Reply on news.ycombinator.com