[HN Gopher] MongoDB Wire Protocol Specification License
___________________________________________________________________
MongoDB Wire Protocol Specification License
Author : aleksi
Score : 73 points
Date : 2021-07-21 16:09 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jmull wrote:
| It's seems a bit pointless to publish a protocol with a
| restrictive license.
|
| The basic purpose of a protocol is interoperability, yet the
| restrictive license works directly against that.
|
| I also wonder about the reach of this kind of license. It's a
| license on the published work. So suppose I read this, whole-
| heartedly agree to the terms of the license, and use it to create
| a MongoDB Interop framework. I include attribution and release it
| under BSD.
|
| Am I good?
|
| I did not use the work for a commercial purpose and provided
| attribution, etc.
|
| Now suppose some commercial cloud provider picks up my framework
| and uses it to implement MongoDB interop. Aren't _they_ good too?
| They followed my license. They may not even be aware of the
| protocol specification, much less have viewed or used it in any
| way.
|
| So what exactly has the protocol specification license
| accomplished?
|
| (I am not a lawyer, so I'm sure I don't understand, but I'd like
| to.)
| gbuk2013 wrote:
| There's the ShareAlike part of the license - presumably that
| means your derivative work must be licensed the same?
| wmf wrote:
| The purpose is probably to allow alternative clients but not
| alternative server implementations.
| floatingatoll wrote:
| Is the wire protocol exclusive to server<->server
| communication, or is it used for server<->client
| communication? If the latter applies, then alternative
| clients would not be any more or less free of restrictions
| than alternative servers would be.
|
| Note that I'm not addressing _whether_ the wire protocol 's
| license affects server/client implementations -- that's being
| discussed in a different top-level thread -- I'm only
| addressing whether a difference _could_ exist between server
| /client.
|
| (I am not your lawyer, please do not treat social media
| comments as legal advice, etc.)
| comprev wrote:
| A company I worked at was hounded by MongoDB to the point where
| the sales rep turned up unannounced and talked his way to the dev
| department. He was quickly escorted off site.
| Diederich wrote:
| Wow, I'd love to hear more details about this if you can share
| them.
| [deleted]
| belltaco wrote:
| We had a far worse experience. We were thinking about upgrading
| to the Enterprise edition. The sales reps took all our details
| and several months later complained to our federal client using
| the details we provided making bs claims about security of the
| Community edition and licensing to them. All under the guise of
| "you didn't respond to us about the price quote".
|
| We lost face because of that, although finally the client
| understood that it was all bs. Stay away from MongoDB and if
| you have to contact them make sure they sign a strict NDA and
| don't reveal any details to them.
| AgentK20 wrote:
| We had a pretty bad experience with our company as well, being
| bounced along nearly half a dozen sales reps (each of whom
| insisted on having a meeting) before actually managing to get a
| quote, which was ludicrously high for the one or two features
| we wanted. For anyone who IS looking for MongoDB enterprise,
| just use PSMDB
| (https://www.percona.com/software/mongodb/percona-server-
| for-...) instead. OSS version of all the enterprise features of
| MongoDB.
| gentleman11 wrote:
| Out of curiosity, why did Mongo get so popular? I used it in
| university when it was hyped and it was pleasant to get started
| with. The ability to query your data is so inconvenient though, I
| switched to SQL and I'm confused about what made experienced
| developers switch from SQL to mongo in the past. Is it just
| because you can scale up more easily when your database gets
| massive?
|
| Like NodeJS and many web technologies, almost everything I read
| about it years ago turned out to be hype and not based on facts
| (eg, nodejs being faster for large numbers of requests than
| traditional backends is not true, but it was widely repeated on
| the first 10 pages of google search results)
|
| edit: very well said, thanks for all the replies!
| ithrow wrote:
| IMO, nodejs today is a reliable tech for many different kinds
| of server side workloads, I wouldn't compare it to mongodb.
| gentleman11 wrote:
| I wouldn't say mongo is unreliable, and I enjoy node a lot.
| Its just that, years ago, everybody said it was amazing for
| certain things and it wasn't based on anything
| MildlySerious wrote:
| Mongo popped up around the time node started growing more in
| popularity. Around 2012, 2013 I started hearing it everywhere,
| and it felt like a hard pressed marketing attempt to make Mongo
| the database for node, and by extension the database for the
| internet.
|
| The web-scale meme came from them actually trying to position
| themselves like that, and it partially worked given that it is
| not only still around, but the prevalence of the MEAN/MERN
| stack, at least in (tech) pop culture and social media.
|
| To this day my opinion is that Mongo is a snake oil PR firm
| with a "database" and I have not yet seen anything that has
| convinced me otherwise.
| tayloramurphy wrote:
| Reading why RethinkDB failed may provide additional context as
| to how Mongo was successful.
|
| https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...
| whydid wrote:
| Junior developers are terrified of their application running
| slow, and not having the technical aptitude required to debug
| and fix the performance problem.
|
| Additionally, Junior developers do not care about data
| integrity (the customer's problem), or operational complexity
| (the SRE's problem).
|
| Finally, Junior developers consider software to be much like
| bread. Older software is bad (such as SQL relational
| databases), and newer software is good (NoSQL).
|
| Combine all three of these flawed systems of thinking, and you
| have MongoDB adaption.
|
| ... also before Kafka, the defacto queue broker was ActiveMQ,
| which was a pain to deploy, so many people used Mongo as a
| queue.
| vel0city wrote:
| You don't use a screwdriver to drive a nail, and you don't user
| a hammer to drive a screw. Its good to use the right tool for
| the job. In many instances, a relational database (often SQL)
| makes a lot of sense and is the right tool for the job. _Some_
| workflows, a NoSQL /Non-relational database design can be nice.
| Document databases, K/V stores, etc can be more optimized for
| those specific use cases which can lead to some better
| experiences. That said, lots of relational databases are quite
| powerful and quite performant that unless you _really_ need the
| particular use cases the NoSQL databases focus on, it may just
| be better to use the tooling available in your relational
| database.
|
| There are a few instances where I've really preferred using a
| document database. Things like logs are often really useful to
| have in a document database like MongoDB. In one collection I
| can stick all kinds of logs. The schema of all the different
| fields in the document are really relevant to what kind of
| things I'm logging. If I were to have a column for every field
| I _might_ have in the log message, each row would have a ton of
| null columns. If I wanted to add a new field to easily search
| on, I might have to add a new column. A "schemaless" design
| can then be very useful. Of course this is true of pretty much
| any document database and not necessarily only MongoDB, and
| these days some relational databases have decent JSON document
| database functionality as well. There are always certain kinds
| of tradeoffs to be made when choosing one database technology
| over another.
|
| Another thing I've found useful with MongoDB in particular is
| GridFS, that has been pretty neat to use. These days there are
| other systems of handling binary blob storage, but as mentioned
| earlier there are always tradeoffs with choosing any particular
| technology.
| gbuk2013 wrote:
| (Just finished their M121 course for my newish job).
|
| Their aggregation pipelines are pretty pleasant to use. You
| basically get a bunch of data transformation code that you can
| avoid writing and you can work with your data without it going
| out on the wire.
|
| I would probably be able to do most of that in SQL and I'm sure
| someone who really knows SQL can do everything it can do but I
| suspect the query involved will be significantly gnarlier. :)
|
| Not sure about how the two would compare performance wise but I
| do know that you can't use "$lookup" (Mongo equivalent of
| joins) with sharding which strikes be as quite unfortunate for
| scalability.
| rapsey wrote:
| Because like NodeJS it has a low barrier to entry. This is by
| far the most important feature for rapid product uptake.
| mcintyre1994 wrote:
| I think a lot of it is how easy it is to insert, query and
| update nested objects compared to a normalised SQL database. I
| know that Postgres' JSON field has come on a lot in the mean
| time though.
| mjburgess wrote:
| Rapid application development.
|
| During which, data is naturally hierarchical and schema-less
| (ie., not defined, changing).
|
| Mongo makes it easy just to "save your dictionary"
|
| It's really just an "sqlite for hashmaps", and should have
| remained this.
| fennecfoxen wrote:
| More specifically, it's an mmap()ed series of linked lists of
| BSON documents, with some relatively simple B-tree indexing,
| a little journaling, and an unfortunate tendency to drop data
| on the floor.
| flowerlad wrote:
| SQL relies on joins. Joins are fine for reasonably sized
| databases, but on internet scale joins have miserable
| performance. "Document" based databases such as Mongo are
| designed to avoid joins.
|
| MongoDB has automatic sharding, which is very important for
| horizontal scaling of writes. For MySQL you have to do manual
| sharding which is extremely hard.
|
| And finally, document oriented databases are schemaless, which
| means there is no downtime when you add/remove fields.
| fredros wrote:
| > but on internet scale joins have miserable performance.
|
| Please define internet scale. Joining 10s of billions of rows
| using clickhouse here.
| flowerlad wrote:
| Clickhouse is OLAP. We are talking OLTP.
| McGlockenshire wrote:
| This entire post sounds like the "MongoDB is web scale" video
| that is now a decade old. "Internet scale" is meaningless
| jargon. "Joins are slow" is a meme based on now-ancient MySQL
| performance.
|
| Schemaless / document databases have a place and a purpose,
| but nine times out of ten the data we're dealing with day to
| day has a known and rigid structure that changes
| infrequently.
| ksec wrote:
| >For MySQL you have to do manual sharding which is extremely
| hard.
|
| Vitess [1] and PlanetScale [2] ?
|
| [1] https://vitess.io
|
| [2] https://www.planetscale.com
| gbuk2013 wrote:
| That's the theory, in practice "no schema" in my recent
| painful experience translates to "move the schema into the
| apps" which really sucks when you have a bunch of
| interdependent services owned by different teams.
|
| And you still need to do joins to enrich data from different
| collections.
|
| I want Postgres back. :(
| flowerlad wrote:
| > _really sucks when you have a bunch of interdependent
| services owned by different teams._
|
| That's true. The strictness of SQL lets you use SQL as the
| integration point. Without it you'd have to write a service
| on top as the integration layer.
| jjav wrote:
| > "move the schema into the apps"
|
| Exactly. There is always a schema, there has to be. It's
| just a question of whether it can easily be seen or if it
| is buried in a thousand places in the code.
| laichzeit0 wrote:
| It's exactly that. Shifting the problem from schema-on-
| write to schema-on-read. It's like dynamic vs statically
| typed. Personally, I don't like it at all, none of your
| problems have magically disappeared, you just shifted it to
| runtime (or the application layer, as you say).
| vel0city wrote:
| In many document databases these days you can have
| required fields and types enforced by the database to
| ensure all documents in the collection have _at least_ a
| certain schema.
|
| https://docs.mongodb.com/manual/core/schema-
| validation/#rest...
| danpalmer wrote:
| This appears to be the licence for the documentation on the wire
| protocol, not the actual wire protocol itself. That would be
| essentially a part of MongoDB itself, or likely as the Google vs
| Oracle case decided, not something that can be licenced.
|
| At least that's my understanding. Am I missing something here?
| It's fairly reasonable for a company to licence their docs with a
| non-commercial licence like this.
| yuubi wrote:
| The "You may not use or adapt this material for any commercial
| purpose, such as to create a commercial database or database-
| as-a-service offering" language suggests that they think the
| license covers more than just distributing the document, which
| I believe is an unusual interpretation of what a spec copyright
| allows the author to prevent.
|
| Lawyer repellent (I hope): The quote comes from
| https://github.com/mongodb/docs/commit/50e48200cde7e2eaffdc6...
| , and anyone who receives this comment may copy it as they
| like.
| chippiewill wrote:
| I think they just stuffed up the wording. I think the whole
| "can't use it to create a commercial database" means you
| can't use the document itself (i.e. "this material") as part
| of your own commercial database offering but you can
| absolutely adapt the protocol and share the document that
| Mongo created under the same terms (i.e. share-alike).
|
| Because it's already in source form and isn't "compiled in"
| into a derived form I don't think it has the same potency
| from an infectious license perspective as GPL does. If you
| bundle this document as part of your commercial database I
| think they can't do diddly squat as long as you make clear
| that the document itself is still under the CC sharealike
| license.
| yuubi wrote:
| I (not a lawyer) understand copyright law to mostly
| prohibit us from copying the spec document without
| permission, and then the license provides permission for
| some copying of the document.
|
| I'm pretty sure the authors really want to prevent
| competing implementations that make money for someone else,
| and the wording expresses their intent. I believe that
| copyright on the document won't let them stop a company
| that can afford decent lawyers from implementing the spec,
| but it certainly doesn't make me any more likely to touch
| anything related.
| tedivm wrote:
| It's pretty explicitly written that they mean for this to apply
| to the specification, not just the documentation.
|
| > You may not use or adapt this material for any commercial
| purpose, such as to create a commercial database or database-
| as-a-service offering.
|
| It'll be exciting to see Oracle vs Google turn into Mongo vs
| AWS, which is clearly where this is eventually going.
| [deleted]
| jchw wrote:
| The specification itself _is_ documentation.
|
| edit: I mean, it's not that I strongly care, but why not
| explain if you disagree? How exactly is a specification not a
| form of documentation?
|
| The relevant definition for spec would probably be:
|
| > a detailed description of the design and materials used to
| make something.
|
| That sounds an awful lot like documentation.
|
| Maybe you are implying that you can't read it and then make
| your own implementation of that reading, but that's not true.
| IANAL, but I'd be willing to bet my lawful ass it means you
| can't _reproduce_ the document for your own commercial
| implementation. Not that you can't reference it. I don't
| think "derivative" is that strong.
| derefr wrote:
| Presuming the wire-protocol specification contains things
| like schemas for Protobuf/Avro/etc. data formats (the kind
| of formats where most compiled-language libraries for them
| do compile-time code-generation against the schema to
| create efficient codec modules), it would be very hard to
| make a conforming implementation that doesn't breach
| copyright by embedding those schemas byte-for-byte.
| adambatkin wrote:
| If you reverse-engineered the protocol (either from
| scratch, or by looking at existing implementations) and
| happened to (independently) come up with an identical
| looking data schema, that would _not_ be protected by
| copyright.
| jchw wrote:
| How would making a byte-compatible protobuf by simply
| looking at the existing one be different than say,
| creating metric-compatible fonts, or, for example, pretty
| much exactly what Google did in the Oracle lawsuit? (Copy
| them verbatim because they shouldn't be copyrightable...)
|
| Even if you subscribe to the belief that the protobufs
| are eligible for protection under copyright law, which is
| fair since it seems to be the current understanding even
| if it is relatively new, I still don't understand how
| creating compatible specs without reversing is illicit.
| It's fair use, no? I thought interoperability was a valid
| claim for fair use.
| _flux wrote:
| Does the linked license https://creativecommons.org/licenses/by-
| nc-sa/3.0/us/ really mean you cannot read it, and then write a
| piece of software that implements it?
|
| My reading of the license implies it covers _the document_, like
| a book or a song could be licensed that you cannot modify and
| redistribute the results, or maybe not redistribute at all: not
| what you make with the information you gain from reading it.
|
| https://wiki.creativecommons.org/wiki/NonCommercial_interpre...
| makes me think the license is about _copyright_, not about what
| you make with the document. The page also has the explanation
| about "Explanations of NC do not modify the CC license".
|
| Even if the NC clarification somehow held true, then I still
| don't see how it would prevent someone from writing e.g. a MIT-
| licensed library implementing the interface (the non-commercial
| use bit) and then someone else just takes it and uses it for
| whatever, within the limitations of the MIT license.
| rolleiflex wrote:
| I think yours is the widely agreed upon definition of Creative
| Commons. I am likewise bewildered by their interpretation -- it
| seems that they are suggesting anyone that reads this document
| is forever poisoned and thus cannot design or implement a Mongo
| compatible software. To my humble legal knowledge (not a
| lawyer) that sounds pretty specious at best.
| floatingatoll wrote:
| HN is reacting as if this licensing change was made today, but it
| was made back in _2012_ , when they licensed their specification
| under a Creative Commons non-commercial variant. Today's linked
| commit is merely a text blurb reminding human beings of that
| license.
| skunkworker wrote:
| This feels restrictive, especially in comparison to Postgresql.
| Where you have projects like CockroachDB which utilize the
| Postgresql wire protocol because of how well documented it is.
| jrockway wrote:
| I think if you know your product is good, you're not too
| worried about someone developing a drop-in replacement for it.
| The opposite is also true.
| Yoric wrote:
| It is my understanding that AWS very nearly killed
| ElasticSearch. If I were [working at] MongoDB, I wouldn't
| want that to happen to my product, either.
| jrockway wrote:
| I'm perfectly OK with the "you can't run this code as a
| service" licenses, but when you get to restricting the spec
| about the wire format, I think other factors are at play.
|
| Like, if Amazon wants to spend millions of dollars writing
| their own version of MongoDB that is drop-in compatible for
| existing MongoDB applications, that is great for customers.
| You, the customer, now have two choice -- options when
| things don't work out with one implementation. When you use
| license agreements to restrict that ability, I think it's a
| statement about the quality of your product -- you think
| Amazon can do it better than you, so you're going to use
| the legal system to prevent them from trying. As a database
| user, that is a signal for me to stay away. It means that
| when I'm having a scaling emergency there is only one way
| to fix it -- give most of my revenue to one company. That's
| scary.
|
| Yes, Amazon did almost kill Elasticsearch. I sometimes
| wonder if the set of circumstances translates 1:1 to other
| companies. The products have similar names -- AWS has the
| Elastic Compute Cloud, and then there's this Elastic
| Search. That's not their product? Nope, just an unfortunate
| naming choice. And, Elasticsearch was particularly
| difficult to run at the time, so a hosted option was
| clearly valuable. And finally, Elasticsearch had a lot of
| company-killing problems: basically not doing what it said
| it did. https://aphyr.com/posts/317-call-me-maybe-
| elasticsearch At the time, Elasticsearch was losing
| acknowledged writes. That's a company killer if your only
| product is a database.
| hodgesrm wrote:
| It's useful to compare MongoDB's text with another vendor known
| for restrictive licensing, namely Oracle. Here's the legalese
| on the MySQL internals documentation. It has restrictions on
| dissemination but not actual use.
|
| https://dev.mysql.com/doc/internals/en/preface.html
|
| It does not restrict you from building applications that derive
| knowledge from MySQL internals documentation.
| toomuchtodo wrote:
| PostgreSQL is organized as a non profit [1], Mongo is a for
| profit enterprise attempting to stem cloud providers from
| providing a wire protocol compatible service without
| compensating them for their work [2].
|
| [1] https://www.postgresql.org/about/donate/ ("PostgreSQL is an
| affiliated project of Software in the Public Interest. Funds
| donated to PostgreSQL are used to sponsor general PostgreSQL
| efforts. These funds are managed by the Fund raising group.")
|
| [2] https://www.computerweekly.com/news/252455700/AWS-pushes-
| Mon... ("AWS pushes MongoDB compatible alternative as licences
| change")
| Spivak wrote:
| If the courts enforce this then this is basically death to
| adversarial interoperability.
| tyingq wrote:
| I assume that's the idea, to try and stop AWS from keeping
| their "Aurora Like" version of Mongo updated. See
| https://aws.amazon.com/documentdb/
| jedberg wrote:
| The original version of MongoDB valued speed over durability,
| which was not a good look for a database. Since then I have never
| been able to trust them, even though I've been told repeatedly
| that "they have changed now".
|
| They have great marketing and appear to solve problems for some
| customers, but they also seem to cause major problems for
| customers.
|
| So I'll just keep advocating to stay away from it.
| winnie_ua wrote:
| What this makes to current version of Mongo? Whoch is far more
| reliable. AFAIK there are soem issues with transactions,
| especialy in case of sharding. But disregard transaction in has
| many leverls of write concern. I'm not sure regarding bugs, but
| it claims to have diferent write concern levels that could suit
| different scenarios. So AFAIK it is reliable now, if used
| correctly.
| dabfiend19 wrote:
| what does this have to do with the linked article?
| rubyist5eva wrote:
| Just another reason why mongodb is trash - does it even go
| without saying anymore?
|
| Every single company I've ever worked for was crushed by the
| unreliability of mongo. They're ultra-expensive consulting is
| also a ripoff - in one case the guy came, suggested a bunch of
| stuff w.r.t. changing up our queries and indexes, left, then a
| day later the database exploded and we had to roll back
| everything he suggested. We tried again piecemeal, which
| eventually lead to the same thing happening again. Eventually
| spending the cash to train the engineers and admins to be able to
| do the tuning ourselves - which ended up being completely
| different than the garbage the consultant suggested. Let me
| emphasize that this consultant was from the MongoDB company - not
| some third party. Completely incompetent company at all levels.
|
| Mongodb exists to extort money from idiots on their cloud
| offering where costs balloon out of control. It was easily 40% of
| our monthly infrastructure bill and what we got out of it
| definitely did not reflect that.
|
| We refused to pay them. Don't ever give Atlas money.
| lmilcin wrote:
| I am tech lead for for large scale trade processing system
| based on MongoDB for one of the largest banks in the world. We
| have billions of documents and tens of terabytes of data, which
| is all processed both daily in huge batches as well as in real
| time, for various reasons (regulatory, for example).
|
| MongoDB is an immature product, yes.
|
| But it is good at some things.
|
| As long as you learn what things it is good at and what things
| it is not good at it can be quite viable solution, depending on
| your problem.
|
| Learn and plan accordingly.
| rubyist5eva wrote:
| > As long as you learn what things it is good at and what
| things it is not good at it can be quite viable solution,
| depending on your problem.
|
| My experience is that the things that mongo is "good at",
| there are competing products that are just as good. Mongo
| downsides - such as not giving a crap if you lose data - make
| it a non starter when there are so many better products that
| actually protect your data.
| lmilcin wrote:
| > My experience (...)
|
| So what is your experience? I have stated mine.
|
| > My experience is that the things that mongo is "good at",
| there are competing products that are just as good.
|
| So what does that mean? Nothing.
|
| Every product is a set of compromises. The one that is
| suitable doesn't need to be perfect in every (or any)
| respect. It just needs to have the set of compromises that
| suits your project.
|
| > Mongo downsides - such as not giving a crap if you lose
| data - make it a non starter when there are so many better
| products that actually protect your data.
|
| Database do not (typically) "protect" data. There are some
| database that make it impossible to remove data once
| stored, but in general if you count on your database to
| prevent data loss, you are just waiting for a junior
| engineer to make a blunder and remove half your database,
| whether it is MongoDB or Oracle.
|
| What all this means is that you cannot count on _any_
| database to prevent data loss and you have to organize some
| kind of way to protect your data. This usually means some
| kind of backup, snapshotted replica, redo log, etc.
| rubyist5eva wrote:
| > Database do not (typically) "protect" data.
|
| This is a laugh. There is decades of work and research
| put into databases and making sure that what you put in
| comes out correctly and consistently. Things which mongo
| referred to as "not web scale" for years.
|
| Obviously you can lose data when you make stupid mistakes
| or God decides to smite you - that's not what I was
| referring to. Pretty good strawman though.
| ithrow wrote:
| Same story with Datomic. My conclusion is that databases are
| hard and require lots of time and resources to be reliable.
| mkl95 wrote:
| I have worked for a couple of companies that swear by Mongo,
| with similar results.
|
| Mongo is just a poorly designed piece of software you shouldn't
| trust for any mission critical service, unless you are willing
| to dedicate a lot of resources to constantly put out fires.
| jart wrote:
| Remember in the early 2010's when every bro on the Internet
| became an expert on scalability because he used MongoDB?
| https://youtu.be/b2F-DItXtZs (sort of like how Rust users are
| security experts today) I've been working on building a
| better database than MongoDB and it's called redbean.
| https://redbean.dev/ It supports web-scale nosql because you
| can use the executable pkzip structure as a document object
| store. It also embeds SQLite for SQL too.
| altdataseller wrote:
| Why do they swear by it then?
| HideousKojima wrote:
| Because they don't understand RDBMSes and how to turn them
| for performance and have bought into cargo cult thinking.
| rubyist5eva wrote:
| Because they drank the kool-aid that joins are bad (so
| implement them in your application instead!)....oops, mongo
| has joins now. It's still trash.
| gqewogpdqa wrote:
| Out of curiosity from somebody watching, what makes you
| say it's still trash?
| [deleted]
| mkl95 wrote:
| Sometimes tech companies have the wrong people at C-level.
| These people constantly make bad decisions, and have their
| subordinates pay for them.
|
| Investors are often oblivious to these details. If the
| company is not doing as well as expected due to crippling
| tech debt, high turnover rates, dumb decisions, etc. the
| CEO will come up with an excuse (since COVID, this is
| easier than ever).
| ksec wrote:
| But somehow they are fifth in DB Ranking [1]. So despite all
| the hate on HN, they are quite widely deployed. The same goes
| to MySQL as well.
|
| [1] https://db-engines.com/en/ranking
| rubyist5eva wrote:
| Just because something is popular doesn't make it good.
| Especially in web development where even the fads have fads.
| Managers and non-techs also eat up the sales pitch and force
| it on teams that don't know any better.
| Thaxll wrote:
| "Don't ever give Atlas money."
|
| Atlas works fine and it's reliable, on the consultant thing I
| can't comment, but MongoDB as it is today is a good DB.
| danpalmer wrote:
| I did my masters research project at university on the issues
| with MongoDB's distributed consensus protocol (or lack
| thereof). One of my friends suggested the title "Distributed
| Cisterns".
|
| That said, I think that the wire protocol is probably ~fine for
| a schemaless document store if that's what you want. I know
| that Apple implements MongoDB with FoundationDB, so that there
| are much stronger guarantees behind it, but they can still use
| MongoDB drivers in various languages, and that seems
| reasonable.
| nextaccountic wrote:
| Can you share the pdf? Thanks.
| rjzzleep wrote:
| Different author but definitely worth a read:
|
| https://jepsen.io/analyses/mongodb-4.2.6
|
| https://jepsen.io/analyses
|
| Older discussion for an older version of mongodb:
|
| https://news.ycombinator.com/item?id=9417773
| FinalBriefing wrote:
| Is there an alternative that is easy-ish to migrate to?
| [deleted]
| BozeWolf wrote:
| We use mongodb in my current clients cloud product. I agree
| mongo sucks big time. It has nothing to offer for our
| relational data (sql please) or for our little search index
| (elastic, or postgres please). Except for the database, the
| rest of our architecture is quite alright.
|
| What i do not agree on is that their atlas product is bad. It
| has a very nice and helpful dashboard. Atlas is quite solid
| when used from google cloud (downtime/slow performance just
| once in 2 years) and their consultant was very helpful. Not
| really fast response times, but it was not urgent. Also their
| offering is not super expensive, but we only have 50-100gb of
| data. Consultancy was good value for money.
|
| Dont give atlas money because you probably want a relational
| database for relational data and use elastic (or postgres if
| small scale) for search or statistics. Mongodb also sucks with
| scaling, it suffers from the same issues as normal databases,
| except that they dont call it a problem. Which means, you, the
| developer should fix it. It also sucks with scaling, because
| expertise on using mongo is scarce.
|
| Almost done at this client. Learned a lot about mongo. Would
| never recommend it to another client. Would recommend running
| managed sql databases by a cloud provider if their offering was
| as good as atlas.
| altdataseller wrote:
| Do you or anyone else have any opinions of Elastic's Cloud
| offering?
| adambatkin wrote:
| Is the wire protocol copyrightable? If not, then this license
| only affects the _document_ itself, not downstream
| implementations that may _use_ the document.
|
| And if there is a differently-licenses _implementation_ of the
| protocol, one would assume that it is possible to implement (or
| just use directly) that implementation without any reliance on
| this specific specification document.
|
| In other words: IANAL but I don't think this will accomplish what
| they want (which is Amazon re-implementing a wire-compatible-
| with-MongoDB database)
|
| As an example: I (probably) can't scan and redistribute an entire
| cookbook, but I can bake cookies from a recipe in the cookbook
| and sell them.
| calvinlh wrote:
| If the "You may not use the material for commercial purposes"
| clause applies to the wire protocol itself, does MongoDB itself
| get an exception to that for Atlas/MongoDB Enterprise?
| tyingq wrote:
| The copyright owner/holder can do whatever they want. That's
| essentially how you're able to have things like Gitlab
| Enterprise or CockroachDB Enterprise use their open source
| base in an extended not-open-source premium product.
|
| It does require you manage outside contributions to the open
| source part carefully and get approval for those
| contributions to land in the not-open-source part.
| laurowyn wrote:
| The license is for the published version available publicly
| only. There's no reason why it can't be separately licensed
| to an individual/entity to grant commercial use on a case by
| case basis. This is no different from negotiating a contract
| - the license defines the terms under which you are allowed
| to use the provided software.
| PeterZaitsev wrote:
| I wonder if this MongoDB's interpretation of Creative Commons is
| even correct. Typically restrictions apply to reuse at the
| specific material not use of the knowledge derived from the
| material.
| gentleman11 wrote:
| AWS benefits heavily from a rich foss ecosystem, but foss systems
| also makes it easier for users to migrate to similar platforms.
| If they were to disrupt the foss ecosystem enough, do we enter a
| world of heavy reliance on proprietary cloud-based systems?
|
| If you were intending to create a profitable business, and really
| wanted your product to be foss, and Amazon might just fork your
| project, honestly, what are your options? I'm honestly curious,
| it seems like such a difficult situation
| hocuspocus wrote:
| The AGPL guarantees the four freedoms and specifically prevents
| (cloud) companies from running a proprietary fork.
| aks_tldr wrote:
| Foss have many licenses, you can choose strict ones.
| gentleman11 wrote:
| Which in specific would help here? From a 4 freedoms point of
| view, where anybody can use or modify the software for any
| purpose, it seems tricky.
| tpxl wrote:
| GNU AGPLv3
|
| Wiki quote:
|
| > GNU Affero General Public License is a modified version
| of the ordinary GNU GPL version 3. It has one added
| requirement: if you run a modified program on a server and
| let other users communicate with it there, your server must
| also allow them to download the source code corresponding
| to the modified version running there.
|
| >The purpose of the GNU Affero GPL is to prevent a problem
| that affects developers of free programs that are often
| used on servers.
| flowerlad wrote:
| Could this be targeted against people who implement Mongodb API
| without being Mongodb? See https://docs.microsoft.com/en-
| us/azure/cosmos-db/mongodb-int...
___________________________________________________________________
(page generated 2021-07-21 23:02 UTC)