MongoDB has filed confidentially for IPO(techcrunch.com)
techcrunch.com
MongoDB has filed confidentially for IPO
https://techcrunch.com/2017/08/15/database-provider-mongodb-has-filed-confidentially-for-ipo/?ncid=rss
18 comments
They've made their share of mistakes, but they've stuck it out and have definitely improved their product over the years. I wish them all the best for their IPO. What would be really good to see As a measure of their business health is an indication of how their cloud business is doing with respect to their enterprise sales business. A healthy cloud business would signal less volatility in the face of high revenue garnered from fickle enterprise sales relationships that have been their bread and butter until the past couple years.
Reliability and implementation ideas aside, MongoDB popularized document stores and document stores can sometimes be a good thing (even if there's usually little to no reason to prefer them to plain SQL databases for most applications). So they deserve credit there.
Agreed; though the way they did their marketing early on the message they conveyed was that document databases were here to replace RDBMSs. It was extremely dishonest.
> early on the message they conveyed was that document databases were here to replace RDBMSs.
The CTO still thinks so. Quote[0]: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB"
[0]: https://www.nemil.com/mongo/2.html
The CTO still thinks so. Quote[0]: "MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB"
[0]: https://www.nemil.com/mongo/2.html
To be fair to them, it wasn't just them, it was everyone.
To be more fair to them, it was just them and the "everyone" you're referring to was a result of a fantastic blatant + guerilla marketing campaign. Or maybe I should say a MEAN success? :)
It may seem like that from a certain perspective, but I remember drowning in the hype in 1992. It was going to be the next big thing: everything is going C++; you want objects; why would you store relational tables, when you want objects?; relational databases are just slow, clunky and complicate your code base. The company I was working at even tried it... very briefly :-) Unfortunately, I don't remember what we tried, but there were several around at the time. This stuff wasn't invented by MongoDB.
That's only because you forgot about Lotus Notes. Perhaps they will have similar fates.
I thought filsystems popularised document stores ;-)
I haven't used MongoDB but I've listened to those who are pushing for it. Yes, that's unfortunate that mistakes have been made (especially when it comes to databases). But, better to find that mistake early on rather than later. And it speaks to the founders dedication to the project that they navigated the rough waters and saw it through.
It looks like the NoSQL movement was just a fad and plenty of startups got burned by it and some still stuck with this tech , writing inefficient workarounds for something that comes OTB with the regular SQL databases.
There are a good reason to use NoSQL, for example to replace EAV. But definitely not a good use to do everything on NoSQL so most companies opted out for 2 database solution = SQL + NoSQL and did not get burned.
The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no reason.
TL;DR
Use Postgres.
The thing however is that since Postgres released indexed BSON support (which is actually faster then MongoDB) there is absolutely no point in opting for 2 database solution and making things harder for no reason.
TL;DR
Use Postgres.
Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres, which outperforms mongo significantly on the same hardware. Plus, you can get read-only views on the Pg side to join with traditional relational data.
> Or, get the best of both worlds. ToroDB puts a mongo wire protocol in front of Postgres
Postgres alone is already the best of both worlds. With ToroDB, I am restricted to the MongoDB way of dealing with my data; with Postgres, I can mix SQL and NoSQL however I like, even in a single, simple SELECT query.
Postgres alone is already the best of both worlds. With ToroDB, I am restricted to the MongoDB way of dealing with my data; with Postgres, I can mix SQL and NoSQL however I like, even in a single, simple SELECT query.
I have to agree that there was a lot of noise in the nosql world and a lot of people got carried away by the ease of use metric. I guess people were lured by the prospect of not having to write SQL joins.
That said I found nosql databases extremely helpful for storing and querying large unstructured data. Mostly because it was really hard to build relations and to store this data in tables. Think Wikipedia for instance. Since then my way of choosing databases is to try and model data into a relational db as much as possible and if that doesn't work out choose a nosql equivalent.
That said I found nosql databases extremely helpful for storing and querying large unstructured data. Mostly because it was really hard to build relations and to store this data in tables. Think Wikipedia for instance. Since then my way of choosing databases is to try and model data into a relational db as much as possible and if that doesn't work out choose a nosql equivalent.
With Postgre you don't need to use a different database unless your workload is "bigdata". You can store relational data alongside unstructures json and query both.
99% of "Big Data" workloads will run happily in Postgres. There are petabyte Postreses (Postgri?) in Production, have been for a decade now...
Which amazes me how RethinkDB never eclipsed all of the other "nosql" offerings. A relational, realtime, document store. You get the benefits from both sides.
Depends on what you're doing. We've used it on at least one production product at work where it works fine and probably will not be replaced. (If it's not broken don't fix it TM)
DynamoDB seems to be the flavour of the day for this, people are using it even in cases where a non-sharded SQL system would work fine.
Can we get revived WebSQL support?
We can thank it a rough Mozilla devs that long moved one, that WebSQL got stopped and is support in Webkit and Blink (100% mobile devices, 80% notebook), but not on Firefox. Instead this NoSQL IndexedDB was introduced. Let's get over NoSQL fad, and support SQL in web browser!
We can thank it a rough Mozilla devs that long moved one, that WebSQL got stopped and is support in Webkit and Blink (100% mobile devices, 80% notebook), but not on Firefox. Instead this NoSQL IndexedDB was introduced. Let's get over NoSQL fad, and support SQL in web browser!
lol trello: https://news.ycombinator.com/item?id=3485186
well, there are so many... using mongodb for CRUD apps and realizing they can't do joins.
Sadly some do not come to that realization and manage to implement a join "solution" anyways.
that comment is over 2000 days old. wow
Startups got burnt by NoSQL because they wanted to use it for everything instead of thinking over use cases that fit. It's a good thing that this fad went away and now people would be more likely to educate themselves about relational vs. non-relational db before jumping into the fire pit.
I worked with one of the largest ad publishing companies. They wanted to track data about every client served an ad. This generated over 1.2 Terabyte per hour of data when the MySQL master started to max out. We had the largest possible multiple core system. It was going to cost my client $30k to upgrade to SSD drives to get more out of MySQL. Also note we had to store this data on an expensive SAN in order to feed the data at a reasonable rate to MySQL or PostgreSQL.
I had just learned of MongoDB and went to school at 10gen for their sys admin class. I talked to the developer about storing the data in NoSQL using a small sharded cluster on a Friday. Monday morning he asked me to setup a MongoDB cluster. Tuesday we moved over from MySQL. They ended up using much smaller servers, got rid of the 3par and epsilon SAN's and saving tons of money.
My point is there are certain situations where NoSQL is still the answer unless you can cluster your SQL write server. I've moved on from working with Ad publishing clients but, I'm sure there are other places where SQL databases are not adequate.
NoSQL might be or, have been, a fad but, like any tool when used for the right job it works.
I had just learned of MongoDB and went to school at 10gen for their sys admin class. I talked to the developer about storing the data in NoSQL using a small sharded cluster on a Friday. Monday morning he asked me to setup a MongoDB cluster. Tuesday we moved over from MySQL. They ended up using much smaller servers, got rid of the 3par and epsilon SAN's and saving tons of money.
My point is there are certain situations where NoSQL is still the answer unless you can cluster your SQL write server. I've moved on from working with Ad publishing clients but, I'm sure there are other places where SQL databases are not adequate.
NoSQL might be or, have been, a fad but, like any tool when used for the right job it works.
A production large scale ad. system system that was doing 1.2 TB per hour in writes, was migrated over from MySQL to MongoDB in roughly 24 hour window cool story Bro.
If more comments were like their story then this would be a way higher value comments section.
how can more made up stories result in higher value comments section?
sounds like the wrong tool. what you are producing was probably logs data, which is immutable. There are far more efficient (storage, cpu) write-only stores.
Such as?
Concider what a database does. It provides ACID properties and ability to query data. If all you need is writing data, the fastest you can do it write it directly to the disk, without the overhead a database comes with.
Using a loadbalancer in front of a farm of cheap logging machines, and aggreate the data you need for analysis to a suitable machine.
Using a loadbalancer in front of a farm of cheap logging machines, and aggreate the data you need for analysis to a suitable machine.
they'd still need to query their stuff, I guess, so you'd need to trow in there somewhere something to aggregate logs and get the metrics they're tracking out of it - which can totally be done in streaming, without the need of going trough the logs every time, for most metrics.
With that amount of data, streaming and only saving aggregated data is the only sane way. With 1.2TB/hour there is a limit to how much historical data that can be saved anyway, and we're talking about 30% utilization of a 10gbps network interface, so it's beyond using single machines for most usecases.
Query? Most likely not. At least not in the traditional "lets on the fly create a dashboard" sense.
query as in 'how much I bill this guy for it's click' - doesn't have to be sql nor on the fly of course
Was $30k a lot of money for one of the largest add publishers?
OTOH, if you're a consultant, and you can say 'hey guys I can save you 30k, my fee is only 15k', and you can do it in a week - I mean, there are weeks where I bill less than 15k...
3k a day consulting. I'm in!
How can MongoDB use that much less in such a situation? Especially prior to WireTiger?
An optimised schema in a relational database should be close to the minimum possible storage.
An optimised schema in a relational database should be close to the minimum possible storage.
The largest ad system ever, Google AdSense, used MySQL until circa 2014 when it moved to a completely custom DB backend, F1. F1 is also a SQL database, however.
Google does use bigtable and such where appropriate, but for anything more complex than dumb key/value you can't do much better than regular DBs. Some people think they can, but 99% of the time they're mistaken.
Google does use bigtable and such where appropriate, but for anything more complex than dumb key/value you can't do much better than regular DBs. Some people think they can, but 99% of the time they're mistaken.
Both Hortonworks & Cloudera are the most similar recent IPOs. Hortonworks is below the offering price, Cloudera has been basically flat. And this is in the context of an insane bull market for tech stocks and the market in general.
So we will see how this turns out. It's been a couple years since they last raised funding so its possible they didn't really have another choice. Chances are if the numbers on the S-1 were truly great they wouldn't have done it confidentially.
So we will see how this turns out. It's been a couple years since they last raised funding so its possible they didn't really have another choice. Chances are if the numbers on the S-1 were truly great they wouldn't have done it confidentially.
Do you have any info that companies that don't have great numbers tend to file S-1's confidentially compared to companies with great numbers?
In my experience, companies that can file confidentially will, regardless of their numbers (and I think all companies now have the option to do so).
In my experience, companies that can file confidentially will, regardless of their numbers (and I think all companies now have the option to do so).
Nutanix, Twilio are two recent ones (IPO'd in 2016). They both were great performers last year.
I don't have the time to dig up all the data and do a comparison of the correlation between returns on companies that used the confidentiality exception vs. companies that didn't, but it would certainly be an interesting analysis.
I don't have the time to dig up all the data and do a comparison of the correlation between returns on companies that used the confidentiality exception vs. companies that didn't, but it would certainly be an interesting analysis.
Are you sure Twilio or Nutanix didn't file confidentially before its S-1 was flipped public? I'm actually not sure if there's a way to tell, other than a leak.
It's worse than that, cloudera went public at a valuation below the price set during their last round of fundraising. Also, people are bullish on tech companies that are consumer tech related or are in the enterprise space serving industries not relating to tech directly. P/E ratios for companies like oracle, ibm and cisco aren't that high.
Not true. Oracle's P/E is 22, Apple's is 18, MSFT's is 27. Oracle is doing just fine.
MongoDBs market is not exactly the same as the Hadoop vendors' although there are overlaps. One of the biggest driver of adoption for mongo are projects that start out as small, rapidly done prototypes and then grow large. It's really easy to start with and scale to decent amounts of data with mongodb.
It's not the same exact market but its essentially the same business model - build a community around an open source system and then upsell enterprise customers on support, consulting & services.
Big difference is in fact apparent right there in your original post: There are two (actually three plus more) vendors backing hadoop, an amorphous community based around an Apache foundation project that no commercial entity controls. This means the Hadoop ecosystem, while generating plenty of value, is not one that can be captured by a particular firm. Plus, the operational database market is ultimately far larger than the Hadoop ecosystem, and so taking a reasonable bite out of it means a materially different market. Finally, it's not just about control of the market, but the software license. Hadoop vendors have little defense of an Apache licensed stack, and face massive threats from new cloud offerings.
Good points. For what its worth there are other successful MongoDB hosting providers - mLab (originally MongoLab), compose (originally MongoHQ), and ObjectRocket - so they (MongoDB, Inc) don't have complete control over the ecosystem, despite the AGPL licensing. Well, they do have the market for support cornered, but long term the margins on that are much lower than DBaaS.
I think a larger issue for MongoDB (& Hortonworks/Cloudera/MapR) is Amazon/GCS/Microsoft hosted services that obsolete them for many use cases. MS already has Azure DocumentDB that supports ACID transactions and has a MongoDB compatible API.
I think a larger issue for MongoDB (& Hortonworks/Cloudera/MapR) is Amazon/GCS/Microsoft hosted services that obsolete them for many use cases. MS already has Azure DocumentDB that supports ACID transactions and has a MongoDB compatible API.
think it is a bad fit and a bad time for an IPO, their market just isnt big enough and their losing a lot of steam as of late.
most importantly in terms of numbers, there is nothing going for them. they arent exactly redhat level in terms of support, nor rackspace level for subscriptions, and nor snapchat level in terms of market reach. this looks like some last effort cash out sort of deal to me. weird to say that its somewhat of a sad outcome for an once promising opensource company.
most importantly in terms of numbers, there is nothing going for them. they arent exactly redhat level in terms of support, nor rackspace level for subscriptions, and nor snapchat level in terms of market reach. this looks like some last effort cash out sort of deal to me. weird to say that its somewhat of a sad outcome for an once promising opensource company.
They recently passed a suite of jepsen tests that finally gives them legitimacy they needed (the latest server release has very good consistency now). MongoDB is in a good place from a technical position.
That's interesting. I've always avoided Mongo because of the general perception that it loses data, but I'll take Jepsen's tests over hearsay anyday.
Well MongoDB is working with Jepsen...
After several Jepsen's article on how bad MongoDB is with the Taylor Swift reference.
Also the notorious wave of MongoDB hacked with terrible security defaults and several programmers blaming bootcamp coders for terrible set up.
I think MongoDB had to do some damage control and wake up.
They apparently are working with him now.
Quick google as proof: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3
After several Jepsen's article on how bad MongoDB is with the Taylor Swift reference.
Also the notorious wave of MongoDB hacked with terrible security defaults and several programmers blaming bootcamp coders for terrible set up.
I think MongoDB had to do some damage control and wake up.
They apparently are working with him now.
Quick google as proof: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3
>their market just isnt big enough
the database market is one of the biggest software markets out there, if not the biggest.
>their losing a lot of steam as of late
at least according ot google trends, mongodb is more popular than ever.
>last effort cash out sort of deal to me
they're hiring like crazy and looking to grow a ton in the next year, so I don't think that's the case.
the database market is one of the biggest software markets out there, if not the biggest.
>their losing a lot of steam as of late
at least according ot google trends, mongodb is more popular than ever.
>last effort cash out sort of deal to me
they're hiring like crazy and looking to grow a ton in the next year, so I don't think that's the case.
>the database market is one of the biggest software markets out there, if not the biggest
They only address a very small subset of the database market.
They only address a very small subset of the database market.
Passing the Jepsen tests mean they'd say they're addressing the larger part of that market, rather than document stores specifically.
(I still think MongoDB, the company, isn't particularly great for the usual reasons re their past behaviour, I'm just imagining what they'd tell their investors)
(I still think MongoDB, the company, isn't particularly great for the usual reasons re their past behaviour, I'm just imagining what they'd tell their investors)
Did you consider that perhaps projection of growth is exactly what you'd do in the event of an IPO? Or that Google trends isn't a sensible heuristic for a valuation?
I've down-voted you not because I disagree fundamentally (although I don't rate MongoDB) but because you are dismantling an argument badly. I hope that isn't too rude.
I've down-voted you not because I disagree fundamentally (although I don't rate MongoDB) but because you are dismantling an argument badly. I hope that isn't too rude.
it is exactly what you'd do in the event of an IPO. I just don't understand how investing tons of money in human capital could be considered a "cash out" as the person I was replying to put it. If anything, it's the opposite.
Google Trends indicates how many new projects look for a database. Database companies typically make money with existing projects (subscription fees or occasionally new versions).
I agree that MongoDB is considered for many new projects but they will have very low market share for existing enterprise projects (which is where the money is).
I agree that MongoDB is considered for many new projects but they will have very low market share for existing enterprise projects (which is where the money is).
[deleted]
Congrats. I wish them all the best.
I know MomgoDB is not very favored in HN but if there is one thing Mongo taught us, is that a nice and simple API to access your data makes a world of difference.
I know MomgoDB is not very favored in HN but if there is one thing Mongo taught us, is that a nice and simple API to access your data makes a world of difference.
Wow I had no idea they were a for profit corp, rather than an open source project. And my startup uses mongo. Mind blown! Good for them.
There's no reason a for profit company can't ship an open source project. :)
MongoDB is an open source project, and the MongoDB company is a for profit corporation that ships the database and sells support and services related to it.
MongoDB is an open source project, and the MongoDB company is a for profit corporation that ships the database and sells support and services related to it.
Yes this is true, although what happens when the profit motivated corporation doesn't make profits or loses revenue?
Isn't it more likely that a profit motivated OSS project will lose resources in this case, potentially affecting the product?
Isn't it more likely that a profit motivated OSS project will lose resources in this case, potentially affecting the product?
Check out RethinkDB, a competing product which had exactly this happen earlier this year. I don't follow the project closely, but the Linux Foundation picked up stewardship and development appears to be continuing, if at a reduced pace.
MongoDB is pretty popular, so while it would certainly be disruptive in the short term for the sponsoring company to go out of business, continued community development is all but assured.
MongoDB is pretty popular, so while it would certainly be disruptive in the short term for the sponsoring company to go out of business, continued community development is all but assured.
That's a really good question.
I think the reality is that many large OSS projects are corporate sponsored, either directly or via companies paying developers to work in the project.
In a case like MongoDB, if the company faced difficultly or even went out of business, the product would undoubtedly be affected.
But since it's a popular open source product that many companies depend on, it seems unlikely it would die. For some of the successful companies using MongoDB at scale, paying developers to work on the project could very well be cheaper than migrating to something else.
I think this is true for large open source projects generally. It's nice to at least have the option of taking the code into your own hands if the company or people developing it decide to stop for any reason.
I think the reality is that many large OSS projects are corporate sponsored, either directly or via companies paying developers to work in the project.
In a case like MongoDB, if the company faced difficultly or even went out of business, the product would undoubtedly be affected.
But since it's a popular open source product that many companies depend on, it seems unlikely it would die. For some of the successful companies using MongoDB at scale, paying developers to work on the project could very well be cheaper than migrating to something else.
I think this is true for large open source projects generally. It's nice to at least have the option of taking the code into your own hands if the company or people developing it decide to stop for any reason.
Really? I thought the MongoDB fad had gone away, that common sense returned, and people either used proper document stores, or proper relational databases, or graph databases.
Could you be a little more specific as to what a proper document store is? Mongodb has impressed me after using it for two years in a highly concurrent and rapidly changing big data production system. It's not without its significant headaches, but I've yet to find a database that is.
There are many articles out there on the web, over the last 5 years, addressing the many problems specific to MongoDB. For example:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
https://news.ycombinator.com/item?id=9912842
http://developer.olery.com/blog/goodbye-mongodb-hello-postgr...
https://www.andreas-jung.com/contents/goodbye-mongodb
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
https://news.ycombinator.com/item?id=9912842
http://developer.olery.com/blog/goodbye-mongodb-hello-postgr...
https://www.andreas-jung.com/contents/goodbye-mongodb
So what do you recommend instead?
This is huge -- we haven't actually had that many open source based IPOs!
I hope at some point they realize the value in queueing writes versus prioritizing. Maybe I did it wrong but that totally put me off
Will be interesting to see if Datastax follows with an IPO of their own.
I hope their IPO filing doesn't get lost before it gets synced to disk.
Now we know for certain that we are in a bubble
[deleted]
Get ready for another SNAP!
I don't see why. SNAP hasn't really figured out how to make money and their features were easy to copy (and copy better) in Facebook's properties.
MongoDB is far longer established, has a large enterprise business and likely has a sizable cloud business. These are not "features" you slap onto another product and then simply have users come flooding to you. No, databases are pretty critical pieces of infrastructure.
As long as the business is solid this IPO should work out well, IMO.
MongoDB is far longer established, has a large enterprise business and likely has a sizable cloud business. These are not "features" you slap onto another product and then simply have users come flooding to you. No, databases are pretty critical pieces of infrastructure.
As long as the business is solid this IPO should work out well, IMO.
Will meet similar fate like Twitter, Snapchat...
Perhaps, but wouldn't it make sense to compare them to another software infrastructure company, rather than social networks?
I am not comparing them but simply predicting the fate based on overblown expectations that were similar to Twitter and SnapChat.
I think it's easy to equate, because in our bubble we hear so much Mongo hype, but to the much larger world, they know as much about Mongo as they do Firebase or New Relic. Also, Mongo the technology has a different set of expectations than Mongo the publicly traded company.
Wow interesting. Anybody have their S-1 filing? Interested to see how their hosted/managed offering Atlas[1] is doing vs support contracts.
[1] https://www.mongodb.com/cloud/atlas
[1] https://www.mongodb.com/cloud/atlas
I have never heard of a confidential IPO, how does this differ from any other IPO that is in the news?
Starting with the JOBS Act (in 2012), certain smaller companies under a revenue threshold were allowed to file their initial draft registration statements with the SEC confidentially. It was meant to encourage startups to go public and avoid the public eye while they negotiated their registration statements with the SEC. It all goes public before the IPO.
Thanks for this information.
It's just an earlier announcement. The banks involved leak it almost every time.
Why is it in their interest to leak the announcement? Wouldn't that discourage other companies from filing through them in the future?
The leak builds up hype and investor curiosity about the IPO. It's like how visits by politicians to an area are 'leaked' so that the press is there to cover them.
You may be assuming that every employee of a company cares about the company's best interests. I find it unlikely that a janitor, intern, disgruntled employee, etc. would be unwilling to spill juicy details for a small fee or feeling of importance.
It's an intentional leak. Part of the "game".
If you send a press release, everyone thinks you're lying and boring.
If it's "leaked" it's sexy and ends up on TechCrunch as a "Report: Anonymous Source shows interesting financials"
If you send a press release, everyone thinks you're lying and boring.
If it's "leaked" it's sexy and ends up on TechCrunch as a "Report: Anonymous Source shows interesting financials"
A side note: MongoDB now dominates the famous framework benchmark in the read benchmarks.
https://www.techempower.com/benchmarks/
https://www.techempower.com/benchmarks/
Here is where I point out that MongoDB dominated write benchmarks when it first came out. And then everyone complained loudly that the benchmark was writing to PostgreSQL and flushing to disk while Mongo turned off safe writes so they'd do better on the benchmark. Once that was fixed, Mongo plummeted towards the bottom of the rankings.
Best marketed database ever.
Best marketed database ever.
With 1.4% more performance than PostgreSQL, and far less guarantees w.r.t. schema.
Yeah, that's not hard. It's surprising it took them this long.
EDIT: The performance comparison that was linked, and that I was referring to: http://i.imgur.com/Thk5DlU.png
Yeah, that's not hard. It's surprising it took them this long.
EDIT: The performance comparison that was linked, and that I was referring to: http://i.imgur.com/Thk5DlU.png
Edit: I'm dumb (and bad at reading words).
I don't believe this assessment is entirely fair -- MongoDB essentially commits every write to a majority quorum of nodes.
Remind me again how many machines a standard Postgres INSERT/UPDATE commits to?
(Disclaimer: I still like Postgres better.)
I don't believe this assessment is entirely fair -- MongoDB essentially commits every write to a majority quorum of nodes.
Remind me again how many machines a standard Postgres INSERT/UPDATE commits to?
(Disclaimer: I still like Postgres better.)
The benchmark measures almost exclusively read performance, so that's not really a question.
Now the real question is why mongodb isn't faster than postgresql in this test. MongoDB gives so many guarantees up just to get more performance, and then looses to PostgreSQL? This is the worst trade deal in the history of trade deals.
Now the real question is why mongodb isn't faster than postgresql in this test. MongoDB gives so many guarantees up just to get more performance, and then looses to PostgreSQL? This is the worst trade deal in the history of trade deals.
Oh oops, totally misread "read" as "write" :P
well I wouldn't account that benchmark. Not for mongodb and especially not for PostgreSQL.
TechEmpower Benchmarks are mostly not really showcasing real world.
Just looking at their PostgreSQL config will highlight that. (Especially: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...)
And also most of the time their libraries/frameworks are outdated or not even configured correctly.
It shouldn't be taken as a reference in any way without additional benchmarking.
Yep exactly. People fall for these benchmarks too easily (especially the ones released by 10gen themselves)