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.
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.
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
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...
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)...
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.
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.
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.
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.
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.
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.
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.
"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!
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.
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.
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.
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?
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
"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.
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!
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?
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!"
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.
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…)
> 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
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.
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 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).
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 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.
Correct, and not only them but also certain others who weren't perfectly healthy. In Germany parents who were NSDAP party members brought their kids in voluntarily.
For more details look up Tiergartenstraße 4 or Aktion T4, but be aware that the details are ugly.
Too late to edit and also only tangentially related but I think it is worth mentioning that Nazis also tried to get rid of Jehovas Witnesses, Gypsies and probably a number of others as well.
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.
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.
If this project is real they chose the worst name possible.