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.
Including horizontal sharding and vertical replication out of the box?
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.
Ah yes - https://github.com/stripe-archive/mosql
6 years ago
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.
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.
at the time it was much faster than native mongo.
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.
> 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.
ah man, mangodb is a really awesome name. vastly better than mongodb if you ask me.
If this project is real they chose the worst name possible.
The license for that is so great.
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.
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.
The chance of them being successfully sued for this is ~100%.
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.
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.
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.
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.
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.
Are there any legitimate citations for this claim? "Life-changing"? Please.
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
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.
https://blogs.oracle.com/database/post/introducing-oracle-da...
