MangoDB: An open-source MongoDB alternative
mangodb.ioNobody remembers the MangoDB spoof where they made fun of mongodb reliability by writing to /dev/null ? https://github.com/dcramer/mangodb
If this project is real they chose the worst name possible.
> If you use this, you must donate $1 to someone more intelligent than you.
The license for that is so great.
Can't believe this is 10 years old and MongoDB is still a hot topic :)
Well, they did end up making it a pretty good database. They saved the good parts (great clients, dev experience) and got rid of the bad (original storage engine, instability) add and have a legit database. Good on them.
While I want to agree, until this year there were still deadlock issues that could take down whole clusters [0][1].
A JIRA user is needed to see them I guess. Do you mind to tell what are the issues ?
I could open the issues in icognito mode. 1: Operation may block on prepare conflict while holding oplog slot, stalling replication indefinitely
2: Do not use the collection distributed lock for chunk merges
Yep. #2 is kind of a hush-hush way of them fixing a bug that can take a lock on a collection during a chunk merge and fail to release it, resulting in writes to primaries to stop until they are kill -9'd.
This was posted not much more than a year ago.
https://jepsen.io/analyses/mongodb-4.2.6
Looks like it was a bug and Mongodb fixed it.
MongoDB is a web scale
Let's make bets on how long it takes before the C&D hammer comes down hard on them.
> Trademark infringement is the unauthorized use of a trademark or service mark on or in connection with goods and/or services in a manner that is likely to cause confusion, deception, or mistake about the source of the goods and/or services.
Emphasis mine, source https://www.uspto.gov/page/about-trademark-infringement
https://trademarks.justia.com/860/49/mongodb-86049805.html
I wouldn't rule it out they will simply dispute the domain name https://my.nic.io/legal/legal_dispute.html
> by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other online location, by creating a likelihood of confusion with the complainant’s mark
> Let's make bets on how long it takes before the C&D hammer comes down hard on them.
Hey, free publicity. News regarding C&D hammering tends to spread like wildfire in the open-source community. A boatload of publicity for a meager name change? That's a steal.
> you have intentionally attempted to attract, for commercial gain
I don't see anything on on MangoDB.io that would result in commercial gain. Maybe I'm missing something though.
It’s been previously ruled that notoriety counts as a commercial gain. The authors could later add monetization to MangoDB, or leverage their increased reputation for gains.
Source? Sounds like this ruling would invalidate fair use...
Please explain how this has anything to do with fair use.
I doubt anyone will confuse Mango’s and Mongo’s. It’s clearly satire, even if it’s a real project.
This is trademark, not copyright. And no I don't think this qualifies as satire at all.
For as long as the mango in MangoDB is rendered as being pear shaped, they should do just fine.
This was actually my first thought even before continuing reading what they do.
I think they‘ll hear from lawyers sooner than later, if this gathers more attention…
They must.
If you don't protect your trademark you can lose it.
Hopefully with better durability than https://github.com/dcramer/mangodb
If it also supports auto-sharting, then I think it'll do fine.
I think and hope you meant sharding
check out the repo your parent comment linked
I immediately thought of this when I saw the title. Unfortunate name clash here.
What makes you think it's an "unfortunate name clash", rather than taking inspiration from the joke?
Mainly because it'll be hard for folks to take it seriously when discussing it, and Googling for it may result in the wrong result. I can get over it, didn't say it was a terrible name or anything. It's hard to come up with a name that communicates a relationship to an existing thing while sounding interesting.
If anything I think it's a shame that the joke MangoDB took the name.
I'm still waiting for somebody to launch MondoDB, hopefully with the tagline "The Radical Database!"
And of course the query language for this database would be GNARLY - Guided Natural Accurate Realtime Lookup Yahoo
The wire protocol should be SENDIT - Synthetic Electronic Node Dialogue Interoperability Transport
> I'm still waiting for somebody to launch MondoDB, hopefully with the tagline "The Radical Database!"
Hmm... how about Mongo 2000? https://en.m.wikipedia.org/wiki/MONDO_2000
The key question for me would be whether this or any other Mongo alternatives are compatible with mongodb's indexing capabilities. They are complex, powerful, and can be somewhat finicky to understand and deploy.
As a longtime Mongo user who was disappointed to see their licensing restrictions, I would probably go back to the release before the license change and maintain a fork rather than try to plug in postgres under the hood.
We actually considered it at Percona with few other companies in the space and there were not enough interest, unlike in Elastic case.
Keeping reasonably up to date in Tech with 30B+ company by reimplementing key features from scratch is daunting task.
MangoDB approach focuses on PostgreSQL (and PostgreSQL Compatible) databases future innovation which makes long term progress much more feasible.
With DocumentDB and many other partially MongoDB compatible software getting traction I think we will see subset of MongoDB functionality to emerge as de-facto standard in this space
And the other day there was a project that allowed to use MS SQL wire protocol on PostgreSQL, so my question is:
Are we just gonna implement everything on top of PostreSQL?
> Are we just gonna implement everything on top of PostreSQL?
On top of PostgreSQL? Which project keeps incorporating other database paradigms at a good clip, and includes a Foreign Data Wrapper feature?
Yeah, looks like it.
It makes me quite happy. I love working in Postgres' dialect and would happily port applications from other dialects to postgres chunk by chunk as stuff broke.
Solid, boring tech as foundations for abstractions is a logical approach to system architecture.
It's PostreSQL all the way down.
Apart from the fact that this project is a spin-off of a MariaDB NoSQL example app.
EDIT: I was wrong about this.
I think you confuse an example with the proxy itself: https://github.com/MangoDB-io/MangoDB
Oh, I see, you are right. Misunderstanding on my part.
Anxiously awaiting the first FPS engine built out of sprocs and views.
here's a start https://observablehq.com/@pallada-92/sql-3d-engine
yes
Yes, PostreSQL is like the javascript of databases.
Expect without all the data type issues and Postgresql having a sane design, Postgresql be a pleasure to use and having the courtesy of staying out of my browser.... Please don't tell me that someone compiled Postgresql to WASM.
> Please don't tell me that someone compiled Postgresql to WASM.
I don't believe that nobody has ever done this... And google delivers: https://github.com/wasmerio/wasmer-postgres
Unfortunately, that is WASM on postgres, not postgres on WASM: https://medium.com/wasmer/announcing-the-first-postgres-exte...
you might want to sit down for this one, but we're pretty close (sqlite):
SQLite, on top of IndexedDB, on top of SQLite... the circle of life!
MySQL is clearly the javascript of databases. PostgreSQL is the Rust of databases.
Agrees, MySQL is full of crap while Postgres kept too few craps. But the majority of the internet (especially in China) is built on top of a crap database, just like most of the websites nowadays are powered by crappy scriping languages (JS, Python, PHP). Whoever got it quick (and dirty most of the case) wins the market.
That's where Worse is better idiom [1], again, unfortunately shines: The world is not built on top of elegancy, but by brutality (in the same sense as brtualism architecture, not bloodlust) and rapidness.
Incidentally, RethinkDB in their postmortem[0] said MongoDB beat them by following Worse is Better.
[0]: https://web.archive.org/web/20170119021049/http://www.defsta...
Another important resource for developers looking for alternatives to MongoDB itself is Percona Server for MongoDB (https://www.percona.com/software/mongodb/percona-server-for-...), which is based on the MongoDB community edition (and is therefore still bound to the licensing issues with it) but adds almost all of the features found in MongoDB Enterprise for free, with costs paid by support licensing similar to Percona's other offerings.
As Percona's CEO I can say Percona Server for MongoDB is fantastic and has many MongoDB Enterprise equivalent features available free of charge, as it has MongoDB Community as Upstream it has to be licensed under SSPL rather than being Truly Open Source Project
I don't remember the exact issue that encouraged to finally abandon MongoDB but I do remember being super frustrated that I wasn't able to find a solution over several days.
I'm using RethinkDB these days (yes, I know it's a zombie database) and I friggin' love it.
RethinkDB is awesome and if people cared about quality it would have done better in the marketplace
Agreed!
Having a built-in Data Explorer is clutch. You can get visibility into your database without having a Ph.D in computer science. It's beautiful.
After I finish up a couple projects I want to help modernize the Data Explorer. It ain't broke but it needs some love.
Doing the $LORD's work. I haven't contributed much to RethinkDB but it's such a great piece of software. It was doing things right basically from the beginning -- also has great Jepsen reviews[0][1] (if you ever need to defend it -- it's one of the better ones).
The Admin GUI was one of the things that made it an instant click for me -- it's a fantastic tool and I want to run it as a service someday, feels like the only way it can gain marketshare again is if some company pushes it sustainably.
[0]: https://jepsen.io/analyses/rethinkdb-2-1-5
[1]: https://jepsen.io/analyses/rethinkdb-2-2-3-reconfiguration
Recently went deeep on efficient kv storage in postgres, there is an order of magnitude different in storage size between different approaches (naive skinny table, EAV, array values, mapped generic columns etc).
I wonder what approach this project takes, I’ll have to poke around!
Can you share some more about your learnings? I'm familiar with EAV as a concept but not the performance implications of EAV vs jsonb. Googling "mapped generic columns" didn't turn up anything that seemed relevant, and I'm curious what you mean specifically by "array values" as a solution in this space.
yeah sorry i just made up 'mapped generic columns',
my progression was trying to find a soln for immutable key/values (immutable enabling some different tradeoffs then others might have) where most of my values are bigints so only a couple of bytes to store.
I worked through approaches: 1. obvious skinny table with duplication 2. EAV optimisation to reduce duplication
The problem with both of these is that having 1 key/value per row with a small value (8 bytes~) meant 23-27 byte row overhead, which obviously increases your storage cost dramatically.
So i looked at how to have more values on each row, so maybe 23-27 bytes overhead for 500 values..
3. EAV with values grouped into an array per row, similar to EAV but instead of 1 value per row, map N values onto 1 row using an array column. So N values are all in one array on a row, and accessed by index. This has the lowest storage overhead, because of row compression you can get on average an 8 byte bigint stored for only 6 bytes per value (so no overhead, actual savings on the raw values..), but value access via array index isn't very efficient especially for sparse arrays, or sparse queries across millions of rows. And tom says maybe not: https://marc.info/?l=pgsql-performance&m=131229661705005&w=2
Good thing about 3 is that you can abstract the value -> row array mapping in SQL, so app doesn't need to care about it, but array access is slower than i'd like, so how to avoid that? Maybe map N values onto generic columns instead? No array access penalty, and less framework fighting..
4. So like 3 but instead of N values in an array per row, have values in N generic columns per row (value_1, value_2 etc). It is too hard/bad ergonomics to do this in SQL/pgplsql, so now the app has to be aware of what value is in which generic column name, which was ok for us and it has much better query performance. In terms of storage cost, there is a relationship between number of columns/values per row and how much data is required to be paged in to retrieve a value (performance) and row overhead and compression efficacy. We landed on 100 values per row I think, this meant bigint was 8-10 bytes to store instead of the more efficient for approach 3 is tunable tho upto the column per row limit of ~1600.
Can dig up proper numbers later if useful but thats the general idea.
Ah yeah it’s probably jsonb (duh). That’s not efficient, but sometimes you don’t care about that!
That demo repo https://github.com/MangoDB-io/example is forked from https://github.com/mariadb-corporation/dev-example-nosql-lis... which "allows a MariaDB server or cluster to be used as the backend of an application using a MongoDB client library".
So in other words the MangoDB project tries to port a MariaDB NoSQL example app to PostgreSQL.
EDIT: seems I mis-interpreted the Github repo. The example is indeed a fork of the MariaDB project but the underlying MangoDB is not.
When I hear of "MangoDB", I remember this: https://github.com/dcramer/mangodb
Funny how there's an actual project with the same name.
MariaDB built fantastic simple MongoDB demo application which MangoDB reused. MariaDB's "NoSQL Listener" is part of MaxScale which is not Open Source.
Really they should call this "PongoDB", it's less similar than mango and it's got a hint that this is backed by pg...
Keep ideas coming I'm not sure MongoDB Lawyers will allow this name to be used
really? they won't?
ah man, mangodb is a really awesome name. vastly better than mongodb if you ask me.
Yes. Mango is better than Mongo! could be project tagline :)
Or MongresDB.
MongreSQL flows better on my end.
Wait, I think we’re missing the obvious: Mongrel
Crossbreedb
CandygramDB? Avoids any trademark confusion, and a great callback to Blazing Saddles.
Unfortunately “pongo” is a commercial name of a product here in Italy (similar to playdoh)
"MangoDB"? Clearly that's trademark infringement.
I guess not if they're based in Estonia?
Whether or not legal redress is practical is a separate question. But MangoDB is obviously creating "confusion in the marketplace" and sponging off the goodwill created by somebody else. That's not cool whether it's a commercial entity abusing a FOSS trademark, or the other way around as in this case.
"and sponging off the goodwill created by somebody else."
Aren't they sponging off the ill will created by somebody else?
How many fruit-related names are available, anyways? There would surely be a different lawsuit coming their way if they named it AppleDB. (ok, I admit this is a terrible joke)
If "Mango" can get away with it, I think it is very cool to provide a graceful path to open source tech.
I don't have much pity for the $33B company that promotes its mediocre semi-proprietary database to unsuspecting devs/students who don't know better.
It is important to be consistent in the application of the rules. Some of us made a stink about the "Commons Clause" people abusing the ASF's trademark when they were promoting "Apache License 2.0 with Commons Clause" for something incompatible with the Apache License. It would be hypocritical to apply trademark rules for that but not in the case of "MangoDB".
Fundamentally I do agree with you. (especially with the mention of "Apache License 2.0 with Commons Clause", which was giving me a headache this morning)
But also I'm not lifting a finger to help companies like MongoDB, unless properly compensated.
Personally I hope that MongoDB does go for a trademark lawsuit, triggering the Streisand Effect. Then Mango can find a better name and attract attention.
Estonia is a member country of the European Union which has well established IP laws.
The chance of them being successfully sued for this is ~100%.
I agree with your point, but (pedant mode on) a cease and desist would be more likely in the first instance. You’d only sue first in an exceptional case.
Reminds me of other abandon things I’ve seen in this space before over the years like torodb[0] and pgmongo[1].
Peeking at this implementation, it seems very immature. There is a long road ahead. Good luck!
I always suspected this space never matured because the effort to rewrite a mongo app to use postgres was less than providing a drop in mongo translation layer.
Though I’ve never used mongo, I’ve always presupposed the set of people who pick mongo is a mutually exclusive from the set of people that pick Postgres. Perhaps this is proof of set intersection?
> I’ve always presupposed the set of people who pick mongo is a mutually exclusive from the set of people that pick Postgres.
I think that in the real world it’s not so black and white. These sorts of articles seem to trigger people.
Agreed. My set intersection joke was unacknowledged. It failed Jepsen.
What's the primary use case for this? I'd imagine it's pretty difficult to scale. How would it compare to something like FDB's document layer (which supports most of Mongo's wire protocol)? https://foundationdb.github.io/fdb-document-layer/known-diff...
There’s already a mongodb compatible document layer for FoundationDB: https://github.com/FoundationDB/fdb-document-layer
Yes. The Problem with Document Layer it implements MongoDB API v 3.0.0 and has not been significantly updated for years.
Plus if you use it you need to know how to Operate FoundationDB while MangoDB is stateless Proxy for PostgreSQL which lots of people are able to run.
Slightly off topic, but I notice a lot of "full stack" courses on Udemy all use Mongo as their backend. Yet, I've always heard (hearsay) that Mongo licensing and reliability are bad. Are there not established training and "stacks" that utilize, say, Cockroach or Postgres, or some other NoSQL? Clearly I could swap out db layer with some work; I'm just surprised that training seems to focus on a database so reviled on HN.
Mongodb is just as good or better than any other database out there.
Coinbase uses MongoDB, Barclays uses MongoDB, BBVA uses MongoDB, Capital One uses MongoDB. Charles Schwab uses MongoDB. FICO uses MongoDB. Goldman Sachs uses MongoDB. HSBC uses MongoDB. Intuit uses MongoDB. Uk Inland Revenue uses MongoDB. UK Dept of Work and Pensions uses MongoDB. What more proof do you need that MongoDB can stand toe to toe with any RDMS.
Pretty much any meaningful database technology can give similarly impressive list. The question is however how is it used ? It may range from the most sensitive mission critical data to being there because Rocket Chat requires it and 100 cases in between.
Many businesses use Oracle DB too. Many businesses also write their internal processes on papers that they keep only one copy of in the same location. Don't fall for the bandwagon effect.
I would bet $100 that all of the companies you've listed also have numerous Excel spreadsheets that should really be databases (if only for the sake of data integrity)...
> MongoDB is a life-changing technology for many Developers
Are there any legitimate citations for this claim? "Life-changing"? Please.
I quit a job one time because mongodb was heavily used there and it was constantly falling over. I can say my life was changed because of it.
Yeah, tbh I think this project is trying to polish a turd.
But isn't mongodb open source anyway?
Historically mongodb uses AGPL. A while ago they changed the license to their own SSPL, which does not satisfy the OSI open source nor the FSF free software definitions, in order to prevent cloud providers from offering managed mongodb offerings which would compete with mongodb atlas.
I do not know about OSI but SSPL most certainly fits the FSF free software definition.
It does not by my reading. It violates freedom 0 - "The freedom to run the program as you wish, for any purpose."[0]. You cannot run the program for the purpose of offering a cloud version.
[0] - https://en.wikipedia.org/wiki/The_Free_Software_Definition
Sure you can, just like the AGPL versions of mongodb. You just need to follow the terms of the license.
In this case how is Oracle different ? You can use it for any purpose... just follow the license.... which requires selling kidney, or two...
Still AWS and DigitalOcean offer managed MongoDB, am I missing something ?
AWS DocumentDB is mostly compatible with MongoDB, but isn't actually Mongo. When we migrated from Mongo to Document there were quite a few queries that failed to run, and we weren't even using complex features. Some indexes also failed to work in some queries.
Yes. AWS Has RDS Oracle Too It is different from Open Source where anyone could build DBaaS solution without any permission from the vendor.
I just moved from AWS DynamoDB to MongoDB serverless for a project due to the 400KB document size limitation on DynamoDB (as opposed to around 16MB on Mongo). Feeling nervous after reading all the comments.
MongoDB is much less trash nowadays than it used to be. If by "serverless" you mean Atlas, you could do worse. Atlas is supposedly quite expensive though.
Don't feel nervous. There are a lot of MongoDB haters on Hackernews. If you have any issues we can help out at http://mongodb.com/community/forums.
Marketing on HN is not cool
I don’t understand how defending their work and giving a link to their help page is marketing. Cloudflare is constantly on HN front page, I never saw one person saying this.
Now we just need a Past-Grass project to re-establish mongo as the backend. I vote the mascot be a hemp leaf with old-timey monocle.
Any performance benchmark? I know it is hard to compare, but I do wonder if it is actually already faster than MongoDB.
Highly doubt it.
a) MongoDB was the fastest database I had ever tried for many types of use cases e.g. tuple updates and in general significantly faster than
b) This is a Go layer in front of PostgreSQL which is fast but not faster than a native C socket server.
I'm not sure it's really an apples to apples comparison. The big selling point of MongoDB is that it sort of just works out of the box with horizontal scaling while Postgres is much more immature in that area.
You could try running https://github.com/mongodb-labs/py-tpcc to get an estimate. However, that might not reflect how people actually use MongoDB since TPCC is focused on transactions as opposed to analytics.
Note though you have Aurora PostgreSQL as well as CockroachDB and Yugabyte which speak PostgreSQL and may be able to support MangoDB
It’s not an apples to apples comparison it’s a mangoes to mongos one :)
Would it be hard to support MySQL as well?
I would imagine the hardest thing is interpreting MongoDB Protocol and converting to SQL - specific backend support like MySQL or might be go straight to Vitess to support sharding might be possible. Thought I think PostgreSQL is perfect database to get started
Probably. IIRC postgresql has better support for looking inside JSON documents than mysql does. Storing, searching, manipulating JSON is what mongodb is all about.
MongoDB has bugs, that part is OK because every software has bugs. However, MongoDB distinguishes itself by lying about the existence of its bugs: https://en.wikipedia.org/wiki/MongoDB#Technical_criticisms
also possible with Oracle
https://blogs.oracle.com/database/post/introducing-oracle-da...
If I install this and turn it on, will it scale right up?
FoundationDB document layer works on the same way.
Funnily this is what I use to call MongoDB, since "Mongo" is a racial and ableistic slur (at least in German).
This is f*cking awesome!
"MangoDB is a proxy which uses PostgreSQL as a backend. The proxy translates MongoDB wire protocol commands into SQL queries, and use PostgreSQL as storage."
You don't have to support MongoDB, but you can support apps that were only written with Mongo as backend? That's awesome. I can't imagine it's production-ready yet but it's a great idea.
I have seen multiple benchmarks that show PostgreSQL has better performance than Mongo in almost all use cases.
A simple wrapper in a language like Go or Rust is sufficient to surpass Mongo performance.
Personally, I have shifted database operations behind a GRPC service that uses Go language and PostgreSQL back-end. Allows me to customize the data store to suit the requirement.
PostgreSQL does not get enough love in this world.
It's plenty loved, I'd say the most loved, but still a fair way behind Oracle in terms of popularity just because of legacy stuff. Damn legacy code, hecking JQuery was still the most used JS framework until just this year!
Oracle and popularity don't really go together. Oracle is really common, just like root-canal treatments. Wouldn't refer to either as popular, though.
> but still a fair way behind Oracle in terms of popularity
I have a vague feeling that those who use Oracle are using it due to circumstance or corporate necessity.
One of the last straws for a job I had once was realizing that the oracle python client would convert money fields into float.
Oracle had its tentacles everywhere in that company. I think even they wanted to stop using it but it was just integrated to too much.
Oracle is a hot mess but it also has some really powerful features, like table sharding , that actually works if you manage to set it up correctly.
To be clear, Oracle's popularity isn't popularity in the sense of popular folk love. Unless you mean popularity in the most rancid disgust available en masse.
> in almost all use cases
Including horizontal sharding and vertical replication out of the box?
I've seen quite a few instances where a mongo deployment using both of those can comfortably be replaced by a single postgres primary (on about the same hardware as a single member of the mongo cluster) with a couple of read replicas and a connection balancer.
There are absolutely mongodb deployments out there that are at sufficient scale that they genuinely need those features in any storage backend, but I suspect the vast majority of them only need those features to work around mongo's mediocre straight line performance.
How close this comes to counting as "almost all" is of course highly arguable.
> can comfortably be replaced by a single postgres primary
And lose all the data in a single failure?
I said a single -primary- and explicitly mentioned having replicas.
I'm very confused why you might think that could "lose all the data" from a single one of those nodes failing.
I was reading your reply too quick, sorry. Anyway, even failover replication in PG is not there out of the box and have it's quirks.
I don't disagree at all with that statement although invetably what mongo does have out of the box definitely has its own quirks.
Getting operations right is tricky no matter what you're doing/using, and you always have to learn your backend's idiosyncracies no matter which one you choose.
It has both, but not out of the box.
More info?
What's vertical replication?
Having several read-only replicas in every shard to distribute reading load.
Off topic. What would you think of a 1 to 1 relation between gRPC functions and stored procedures? Keeping all the SQL together inside postgres is great for debugging and updates; you can see all dependencies. One to one would stop you from having to make a different API, and make the gateway a simple reusable service.
> You don't have to support MongoDB, but you can support apps that were only written with Mongo as backend? That's awesome. I can't imagine it's production-ready yet but it's a great idea.
You have just described AWS DocumentDB, which is a Mongo compatible frontend using Postgres as the backend (AWS coyly refer to it as Aurora, though); the wire protocol compatibility is at the version 4.0 level, with some extras thrown in. Change event streams also works like a charm. We have been using it for a couple of years and have found DocumentDB stable, performant with the AWS support being very good. Support for complex compound indices is still missing as well as support for complex query projections is somewhat missing, but we have decided to change ways of how we use use documents instead, so it has not become a major impediment for us.
The main disadvantage, though, is cost, especially for smaller datasets where spinning up a separate DocumentDB cluster quickly turns into a money wasting excercise. Although, for our primary use cases, DocumentDB is still more than 3x cheaper than a comparable Atlas MongoDB PaaS.
Except DocDB is not a drop-in replacement despite what Amazon says.
People have tried and failed to get our software running on DocumentDB, whereas another developer got it running on CosmosDB with minimal changes upstream.
Not affiliated with MS in any way, just sharing what I've witnessed secondhand.
Amazon do not say that DocumentDB is a drop-in replacement, neither do I. Moreover, I have outlined specific incompatibilites between Mongo and DocumentDB we have encountered for our use cases; RBAC controlled document filtering is not available in DocumentDB, either. Therefore, it won't suit everybody.
However, for simple to medium complexity projects, especially for brand new ones, DocumentDB is a viable and a more affordable alternative to Atlas MongoDB with a decent level compatibility.
Didn't the stripe team do something like this 5 or 10 years ago? I seem to remember them having a translation layer or doing some sort of streaming conversion from mongodb to pg?
Ah yes - https://github.com/stripe-archive/mosql
6 years ago
Does not look like the same thing - this looks like system to replicate from MongoDB rather than being able to talk to PostgreSQL as if it were MongoDB
Yes, that seems correct
"MoSQL imports the contents of your MongoDB database cluster into a PostgreSQL instance, using an oplog tailer to keep the SQL mirror live up-to-date. This lets you run production services against a MongoDB database, and then run offline analytics or reporting using the full power of SQL."
This also means you don't have to use PostgreSQL, you are using its wire protocol. So ideally, this could work with Cockroach, Yugabyte, Cloud Spanner, Crate DB, immudb and tens of others that I am missing.
There was another thing in that space aswell https://www.torodb.com
Yeah, I could imagine this being a useful step to migrate away from MongoDB. I suspect there are plenty of "resume-driven development" MongoDB installations out there that could use something like this.
> Yeah, I could imagine this being a useful step to migrate away from MongoDB.
What is the state of the art in this area? I did a little PoC of moving data from Mongo to a new schema in Postgres with Hexo and DBT. It worked nicely, but it was only a PoC.
Oh, I don't know about the state of the art, I was just speculating. I'd imagine this technique would only useful if you want to support a MongoDB app at the same time as building new features with Postgres, and then gradually phase out the MongoDB interface (e.g. gradually transitioning between a v1 prototype and a v2 rewrite)
If it's not much data (eg ~100k or something), and you don't need any sort of gradual transition, then I'd do something really KISS like dump into a CSV or something and then re-import with whatever the new database management system has for importing files
MongoDB is a 12 year old database. And yet people are still using this disparaging argument that anyone that chooses it is doing so for their resume and not because it meets their needs in any way.
But by all means replace your production system with MangoDB which is unsupported, significantly slower, has no built-in HA/clustering and written in Go which is a GC language.
Would you please not post in the flamewar style to HN? You have a long history of doing this, and I have the impression that it got better in the last few years (yay! thanks), but I also have the impression that you've been relapsing recently (boo, please don't). You can make your substantive points respectfully and without snark, and we'd be very grateful if you'd stick to that.
It's crazy how this "flamewar" perspective has changed on HN about Mongo DB in the last 10 years. It used to be that any comment critical of MongoDB would get a warning. Now it's any comment supportive of it!
> It used to be that any comment critical of MongoDB would get a warning
That can't possibly be true, or even close to true!
Hm, well, I never said that ANYONE who uses MongoDB is guilty of resume driven development. I specifically only indicated the ones that WERE chosen via resume driven development. Unless you were replying to the wrong comment?
No I am replying to the right comment.
I think it's disparaging to use the term resume driven development as though there is a large class of developers who are actively trying to harm projects by selecting inappropriate technologies.
I've worked with thousands of developers over the last 20+ years and never seen anyone do this.
Huh, so if we are trotting out experience credentials, I have also worked with thousands of developers (I guess?) over the last ~20 years as well. My first programming language was Apple BASIC on an Apple II, and I haven't stopped learning since!
I think we use this term differently, perhaps? This term is not intended to be an attack, but rather just an acknowledgment of a common type of technical debt that results from people getting influenced by marketing teams and choosing tech based on how "trendy" it seems. Sometimes this might be done explicitly since they are intending to jump ship anyway... I've had conversations at the bar out of earshot of "the suits" where this exact topic was discussed! Most of the time it's not intentional or explicit, but just novice engineers directed by poor management to greenfield apps, and then falling for marketing claims and choosing based on how "trendy" the marketing claims it is vs real, observed needs. MongoDB is still getting taught at many bootcamps and coding curriculums as an "SQL, but better for beginners since you don't need that annoying schema thing!"
I've worked with tens of developers over 8 years and I've seen this many times.
I don't think they're 'actively trying to harm projects', but the person you're responding to never implied that in any way.
Yeah, I think the person we are replying to is taking this a lot more negatively than I intended. I always sort of thought it was kind of an "open secret" that this stuff went on, at least here in SV / Bay Area. Perhaps elsewhere, where engineers don't hop around jobs every year or two, this sounds more like an insult or accusation?
Allow me to doubt that you have deep insight into the motivations of thousands of people that have all selected MongoDB for their projects. This seems unlikely for several reasons, if nothing else because of Dunbar's number.
I don’t need to have deep insights. Developers almost always have to justify why they pick certain technologies.
And given how old MongoDB is not sure how it benefits anyone’s resume.
If you don't understand their motivations, how can you claim to know their motivations?
There are thousands of projects where MongoDB was selected precisely because it was a new-shiny No SQL thingy.
For some of these things, it may have been the right thing. For most of them, it was a chance to play with new technologies. I have seen multiple commercial projects where MongoDB was chosen by the developers with _no_ oversight by management (I have killed a couple of those projects, too, because MongoDB was always the wrong technology).
The original comment about the number of projects where MongoDB was chosen under résumé-driven-development is absolutely correct. That doesn’t make it _bad_; how _else_ is one supposed to get experience with new technologies than to try something new? (Sticking with Mongo after multiple data-loss incidents due to the “architecture” of Mongo, on the other hand…)
Since you haven't seen it means it doesn't happen? Sad that 20+ years didn't teach you basics of logic.
From the HN guidelines:
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
Note MangoDB is a stateless proxy as such you can use it with any PostgreSQL setup. For example you should be able to use it with Amazon Aurora PostgreSQL as backend which has HA built in
If you are using the cloud then you can just use DocumentDB.
Which is the same proxy on top of PostgreSQL if I remember correctly. :) But MangoDB is cloud-agnostic. I imagine it has the same limitations as DocumentDB or more.
But then you have to use DocumentDB.
It depends. With MangoDB you can test on your laptop with PostgreSQL and deploy to Production to Aurora... or any other PostgreSQL compatible DBaaS.
"and written in Go which is a GC language" => Would it be better for you if it would be "written in JavaScript which is a GC language"?
I agree either stay with mongodb or if you really want to migrate then just switch to Postgres by obviously exporting the data and putting it into Postgres
I did something similar for fun 8-9 years ago as well: https://github.com/jerrysievert/mongolike
at the time it was much faster than native mongo.
But is it webscale? [1]
I don't trust developers who can't come up with a more creative, less confusing name.
Like, you can at least name it after another variant of Mango to make the name more interesting, or call it something similar but with a little more variation (like MangroveDB)
Still better than a name with which you have to explain to everyone what it actually is supposed to mean and that it is not meant as an insult (even if that is the first thing that comes to everyone's mind).
GIMP?
If that's what you're referring to, then yup #1 worst-named FOSS ever.
"Mongo" is a pretty bad slur for people with Down syndrome.
I've never heard that, though I've heard the racist "loid" version.
Though I do love the dictionary definition of "mongo":
"Items found in the trash that can be salvaged."
Sums up my views of mongodb pretty well, actually.
In sweden/norway/some other countries it is often shortened to mongo and used a slur.
And the version of the slur you're talking about is a pretty old one that I have not heard used in decades (of course that may be regional, generational, etc.)
But like you, I have never heard "mongo" used in the same pejorative context.
It might be rare in English but it is very common in other languages.
It is a very common slur among kids in Norway and originally means someone who has the "mongoloid" syndrome. These days it just means "you idiot" after "pro choice" succeeded where Hitler "failed" and got rid of most people with downs syndrome.
Oh wow, I had no idea! I've never heard of this. Thanks for letting me know.
I only knew it as the name of "Planet Mongo", the main planet in the Flash Gordon universe, an old science fiction comic that has been rebooted many times (which also had loads of extremely racist anti-Chinese elements)
In the Scandinavian countries "mongo" is used as both a slur and a general insult. However, since it manages the feat of being both ableist and racist at the same time, its popularity has waned quite a bit over the years.
I thought it was a jab at Cockroach DB
Could be that! Another terrible name hahah. Although in their defense I get the "cockroach" analogy, while "gimp" is just an offensive insult and/or a very NSFW BDSM term, and has no other meaning, which makes conversations even more awkward.
It reminds me of the Linux distribution called Lindows that advertised itself as a free alternative to Windows. Microsoft sued them pretty quickly