gqewogpdqa

This is a huge change - the rewrite in Rust is like… wow. More and more software is being rewritten in Rust it seems.

Lol. When did you last use MongoDB and why is it a thumbtack?

MongoDB is used by enterprises all over the world. It's true that it's the easiest DB to get started with, and it's also true that in the distant past (pre 3.0, back in ~2015), they had some issues. But they now run the financial backends of companies as varied as banks and coinbase and... https://www.mongodb.com/who-uses-mongodb

absolutely true that this is an area of improvement for MongoDB - moving from a "replica set" (a single shard cluster but without the config server cluster) to a sharded cluster can be hard. Atlas does it for you, but even then it can be hard. My info says they are working very hard on this.

Live resharding indeed helps for a sharded cluster that already exists.

Do you have recent data on this auditing stuff you're referencing? MongoDB is growing much faster than Oracle, so maybe it won't fade...

>>>MongoDB also provides single document atomicity.

And multi-document, in sharded clusters. 2018: https://www.mongodb.com/blog/post/mongodb-multi-document-aci...

>>>But in RDBMS you can configure the ACID properties. https://www.mongodb.com/docs/manual/reference/write-concern/

It's happened 15+ times before :-) I agree - talking about actual facts - i.e. licenses - is far better. I think SSPL (and AGPL) for that matter, protect freedoms - the freedoms of small companies to innovate and not have their work gobbled up and used by gorillas who have the power of distribution and platform. I don't know about the deals MongoDB has made with these 15+ cloud providers, but clearly it's working somehow. That said, maybe they would indeed not license to the three "biggies". Though it's unclear that those will be the three biggies for too much longer. Thanks for the clear comment back - sorry for being snarky in my note.

>This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane.

Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.

> It's also not open source under almost anyone's definition.

Enter the OSI. While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters. A nit, but an important one - the capitals force us to realize that it's not a word in Webster's Dictionary. It's a proper noun definiton put forth and pushed by one organization. I can certainly say "...oracle is lying..." but if I say "...Oracle is lying...", I expect the black cars to drive up to my house pretty quickly.

Nope it’s implemented on the server side. I think that they are going to talk more about it at a session and maybe even in a keynote

"bike shedding" is a well known term of art in many places. That said, it might not be as prevalent as I think (or obviously OP thought). But, I was able to find that it's quite common with a quick Google: https://en.wikipedia.org/wiki/Law_of_triviality

Haha. Key-value is meant (IMO) to show the connection between the key and the value. You're right, it's not a "key value" store, where "key" is an adjective modifying "value" to show that is only stores the most important values. The "-", again IMO, shows that there is a mapping between each key and each value. But geez, I think we knew what was meant :-)

Yeah, I think MongoDB went through a set of steps - atomically consistent at document level (which is fine for many apps as you have most related data in the single document anyways) - atomically consistent within a collection - and now, with MongoDB 4.0 and higher (released in 2017? 2018? whatever, a long time ago), MongoDB supports full transactional consistency across documents, collections, and shards. It took them awhile, but they got there.

Google didn't acquire Snowflake - unless you know something the rest of the world doesn't ;-) But if they did, how would it be "an answer to MongoDB"? i.e. MongoDB Atlas. AFAIK, MongoDB is focused mostly on the operational database market, not the offline analytics market. Would love to understand that part - thanks!

Lol. I heartily endorse people making proper choices based on their needs. With the proliferation of shiny things for developers, it's really important for people to have this focus. Very good point.

Oracle V2 was known as the "roach motel of databases". Data went in and it didn't come out. By V5, Oracle was a solid database. Why do people not give MongoDB the credit for growing up from a memory-mapped db to something far more serious, where they say they have ACID transactions, HA, a managed cloud service, etc? The industry memory of that meme is impressive, hilarious...and misplaced.

Amazon didn't implement an entirely new database. As you can see on https://en.wikipedia.org/wiki/Amazon_DocumentDB, they just built an (admittedly clever) PostgreSQL plugin on top of Aurora PostgreSQL.

AWS never hosted MongoDB, under AGPL or SSPL.

Thanks for that info. Statistics, misunderstandings, lies, benchmarks, database benchmarks...

As, surprisingly, did so many other databases and operating systems. VAX/VMS was "FIELD/SERVICE" on all new systems for many years.Then all these systems got connected to DECNet/BITNET, etc and all heck broke loose. No real excuse for anybody to have ever configured their systems this way.

What does “eat section 13” mean? The SSPL part? Are you looking to offer a cloud-based managed MongoDB database service to the public? If not, you can do pretty much anything you want with the code. There has been a lot of FUD posted but really, taking the community code and offering a parasite service like Amazon did with other databases is the only thing prohibited by section 13. And unless you have a lot of energy and time you probably can’t be competitive with Atlas, their managed service, as it has a lot of stuff built around the database. Just my opinion, but I am curious about the “eat” part. Of course if you are just allergic to anything different than pure Apache 2.0 regardless of the fact that SSPL has no business impact on you, that’s completely ok

Can you explain?

Awesome book

I think that makes sense. Using the technology as designed without the “compatibility” layer is likely a better option. Thanks for sharing as many I think wonder about these DocumentDB and CosmosDB MongoDB imitators.

However, CosmosDB is a managed service, easier than setting up your own database. Did you exclude Atlas from your conclusion for some reason? Ie did AKS do things that Atlas could not?

Totally think it's good to have lots of options. PostgreSQL using JSONB however is a way to hurt your head. Using SQL to manipulate JSON is pretty painful. Why would MongoDB Community not be an ok choice? Unless you're planning on offering MongoDB as a cloud service, what would the concern be?

What's the bad reputation of MongoDB that you're concerned about?

Also, you seem to have a really strong bias against it - can you explain?

Out of curiosity from somebody watching, what makes you say it's still trash?

I get your point, and thanks for the discussion. My thought is that even software with an OSI approved license can be moved to a non-OSI license at any time. So you can't actually insure against the dystopian future you are concerned about. The only way to insure against that is if the software IP is not owned by a company. It will be interesting to see how this plays out with TimescaleDB, Confluent, Starburst, Grafana, and a host of others - none of their code is owned by a foundation (like PostgreSQL is) but is instead owned by a company. And those companies have ( and will continue to ) do thing that protect their customers, employees, and stakeholders. Thanks for the clarifications - I understand now better the concerns of the OSI-favorable community.

I really appreciate the constructive response back.

From reading all the press, it feels like MongoDB did not do this to garner more revenue but to instead prevent open-source parasites from causing MongoDB to lose money or even go out of business. When I read Eliot's posts in 2018, it feels like he's trying to stay in business, not be greedy.

From a commercial point of view, databases have been shown to need management. Maybe someday somebody will write a database that has a magic simple-to-use endpoint, stays up 100% of the time, and doesn't require a cadre of people dancing around the database chanting spells to operate it. None to date... So the cloud providers capitalize on that need, and wrap control planes around databases - often hurting the people who are working hard to innovate on that software - and deserve to be paid for their work.

As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products. I.e. why would anybody want to improve PostgreSQL or MySQL when Amazon Aurora PostgreSQL and MySQL exist, CloudSQL and Azure SQL all exist - and may or may not take the changes - and even when they do, it takes many months or years.

Finally, I guess I'm puzzled by your last two paragraphs.

You mention that "all the dev hours invested into MongoDB post 2018 likely will have been invested in vain" - why? They go into the community edition, which anybody can use. They go into the EA and Atlas version, which customers who want enterprise-quality software with enterprise-quality support can use.

Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't. Or that it prevents them using MongoDB as much as they want. It doesn't, with one exception - and that exception probably affects <0.01% of the users of the software. The MongoDB license (and the Elastic and TimeScaleDB and many other licenses) don't even prevent anybody from wrapping up the software into a cloud service and offering it for money. In fact, many companies (SAP, IBM, Tencent, Alibaba, to name a few, apparently do). It just means you have to talk to the company before doing it.

I personally love MongoDB and I think the SSPL ended up preserving the company and preserving innovation, which is good for the open source community. At least it's not a complicated mess like MySQL and MariaDB.

That said, I'd love to hear more about how SSPL actually damages anybody in a meaningful way. I haven't yet seen anything except a philosophical argument. I'd love to hear it.

Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?

That doesn't make sense as far as I can tell. You would need to release the source code of the managed service you built around MongoDB.

>Annual YoY revenue growth is flat too at around $500m. 2018: $154M 2019: $267M 2020: $421M 2021: $590M Source: https://finance.yahoo.com/quote/MDB/financials?p=MDB