MangoDB: An open-source MongoDB alternative
mangodb.io
mangodb.io
If this project is real they chose the worst name possible.
The license for that is so great.
2: Do not use the collection distributed lock for chunk merges
https://jepsen.io/analyses/mongodb-4.2.6
> 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
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.
I don't see anything on on MangoDB.io that would result in commercial gain. Maybe I'm missing something though.
I think they‘ll hear from lawyers sooner than later, if this gathers more attention…
If you don't protect your trademark you can lose it.
If anything I think it's a shame that the joke MangoDB took the name.
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
Hmm... how about Mongo 2000? https://en.m.wikipedia.org/wiki/MONDO_2000
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.
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
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.
EDIT: I was wrong about this.
I don't believe that nobody has ever done this... And google delivers: https://github.com/wasmerio/wasmer-postgres
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.
[0]: https://web.archive.org/web/20170119021049/http://www.defsta...
I'm using RethinkDB these days (yes, I know it's a zombie database) and I friggin' love it.
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.
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
I wonder what approach this project takes, I’ll have to poke around!
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.
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.
Funny how there's an actual project with the same name.
ah man, mangodb is a really awesome name. vastly better than mongodb if you ask me.
Aren't they sponging off the ill will created by somebody else?
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.
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.
The chance of them being successfully sued for this is ~100%.
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 think that in the real world it’s not so black and white. These sorts of articles seem to trigger people.
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.
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.
Are there any legitimate citations for this claim? "Life-changing"? Please.
[0] - https://en.wikipedia.org/wiki/The_Free_Software_Definition
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.
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.
https://blogs.oracle.com/database/post/introducing-oracle-da...
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.
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.
I have a vague feeling that those who use Oracle are using it due to circumstance or corporate necessity.
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.
Including horizontal sharding and vertical replication out of the box?
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.
And lose all the data in a single failure?
I'm very confused why you might think that could "lose all the data" from a single one of those nodes failing.
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.
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.
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.
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.
Ah yes - https://github.com/stripe-archive/mosql
6 years ago
"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."
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.
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
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.
That can't possibly be true, or even close to true!
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.
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 don't think they're 'actively trying to harm projects', but the person you're responding to never implied that in any way.
And given how old MongoDB is not sure how it benefits anyone’s resume.
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.
at the time it was much faster than native mongo.
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)
If that's what you're referring to, then yup #1 worst-named FOSS ever.
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.
But like you, I have never heard "mongo" used in the same pejorative context.
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)