17 ms·

Homebrew removes MongoDB from core formulas

252 points by codyogden 7y ago

olliej 7y ago
Play stupid license games, get stupid prizes?
thiscatis 7y ago
Would love to see an overview of companies that fell into the mongoDB trap and have / are migrating to another DB store.
- mikeryan 7y ago
  Over the last few Months we’ve switched over to amazons document db just to have a managed service. We don’t regret it.
  - nailer 7y ago
    DocumentDB is still really expensive as there's no pay what you use option. I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake. They really need to come up with a per mb per hour option.
    - qeternity 7y ago
      What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?
      - smnrchrds 7y ago
        The cheapest option is 0.277$/hr just for the instance. https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/
        chii 7y ago
        It's interesting that people would pay amazon, but not mongodb...
        threeseed 7y ago
        I work in the enterprise and we spend tens of millions a year with AWS. Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product. With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.
        chii 7y ago
        I guess nobody got fired for buying IBM is still true to this day and age.
        nevi-me 7y ago
        This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in? There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes". We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.
        mbreese 7y ago
        If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.
      - rad_gruchalski 7y ago
        https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.
    - cj 7y ago
      I spend somewhere around $30-40k / yr on AWS (EC2) for a 3 member replica set. I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK). Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.
    - farisjarrah 7y ago
      Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.
  - threeseed 7y ago
    Super expensive and orders of magnitude slower in some cases. As much as I love a managed service this was a very disappointing effort from AWS.
- benologist 7y ago
  I would love to see open source developers and companies supported because it's not really tenable to replace all the open source we rely on - we probably need 20 million lines of open source to serve a HTML page. If we were actually enabling and empowering open source developers, and especially the people learning, it would be awesome. Enabling people like Torvalds and Stallman to grow into their role of writing stuff that benefits billions of people. But we can do Hunger Games too. There's no wrong answers.
  - mruts 7y ago
    I dunno, I could do it in 200 of good code in C.
    - est31 7y ago
      Including kernel, network driver, etc?
      - mruts 7y ago
        I guess not no, I was thinking of userland.
        est31 7y ago
        You can make a simple HTTP/1.1 server in 200 lines of good C. Not one that runs HTTP/3.0 including QUIC and TLS.
        cameronbrown 7y ago
        HTTP 3 isn't even in production yet.
        xchaotic 7y ago
        Define production and define HTTP3. The beauty of open source is that you can be already serving pages using QUIC and TLS1.3 while the standard is being finalised.
- shanev 7y ago
  Coinbase comes to mind.
- taylorlapeyre 7y ago
  Didn’t Stripe go down this road?
  - enraged_camel 7y ago
    Yes, in addition they apparently use a pretty outdated version of it. (Several people mentioned this on a related HN thread that I'm having trouble locating.)
    - delhanty 7y ago
      It was claimed here [0] >... they continue to build on top of a broken foundation (MongoDB) ...but last I heard Stripe was still running a very outdated version ... [0]https://news.ycombinator.com/item?id=20820879 https://news.ycombinator.com/item?id=20820879
- threeseed 7y ago
  If you are looking for a document store there aren't many alternatives. And one of the positive elements of MongoDB has been that they acknowledged their many issues and have over the years been fixing them one by one. Whilst alternatives have largely been stagnating. And I am still yet to find any database that even comes close to its single tuple update speed.
  - mfer 7y ago
    Have you looked at postgresql document store? Amazon put a mongodb API on that and made a service after all
    - threeseed 7y ago
      1) No that's not what AWS did at all. They implemented the MongoDB API on top of their own storage layer. It doesn't use PostgreSQL. 2) Of course. But MongoDB is orders of magnitude faster in some cases, has better horizontal scalability capabilities, better drivers and some nicer semantics e.g. around streaming.
      - species9606 7y ago
        It’s webscale!
        hombre_fatal 7y ago
        I actually recognize threeseed's name over the past five years as being a staunch MongoDB proponent. https://hn.algolia.com/?sort=byPopularity&prefix&page=0&dateRange=all&type=comment&query=threeseed%20mongodb https://hn.algolia.com/?sort=byPopularity&prefix&page=0&date... No hate, just always amused me that someone on HN had MongoDB as their hobby horse.
      - phonon 7y ago
        https://news.ycombinator.com/item?id=18870397 https://news.ycombinator.com/item?id=18870397
- Thorrez 7y ago
  What you do mean by the "mongoDB trap"? Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?
  - zxcvbn4038 7y ago
    A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought. Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license. If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.
    - scarface74 7y ago
      But Mongodb is so different from anything else that you need a major rewrite to get away from it. Well actually.... One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.
      - 6nf 7y ago
        So why not just use a RDMS from day one?
        scarface74 7y ago
        Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? In C# var seniorMales = from c in context.Customers where c.Age > 65 && c.Sex == “M” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. You get autocomplete and compile time checks. When you want to add an record to your Mongo collection, you work with strongly typed IMongoCollection<Customer> And the compiler will ensure that your collection stays consistent.
- peteretep 7y ago
  Include in that any of the many companies still using Perl, for whom MongoDB have dropped library support.
- pfarnsworth 7y ago
  Ubiquiti is one of those companies. They use MongoDB for their controller app, which has been a pain in my side for a couple of years now.
- truth_seeker 7y ago
  I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not depend upon bashing of any X DB on the internet. I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB" Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for. Following are the things most people miss: 1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API. 2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2. 3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it. 4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data. 5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?
  - deleted 7y ago
    [deleted]
  - octohedron 7y ago
    As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said. Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet. People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases. Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time. Also it's what's taught in courses as superior to non relational databases. I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.
- IloveHN84 7y ago
  A lot of startups for sure
- Benjamin_Dobell 7y ago
  I inherited a MongoDB Ruby (Mongoid) stack that was a terrible choice for the data stored (i.e. relational data). Actually, I'm not really sure why Mongoid exists at all. After several years of pain e.g. cursor timeouts (even when supposedly disabled), iterating over the same document multiple times in the one query etc. and of course no transactions (since added). I eventually migrated to PSQL (using some custom scripts) and everything is so much easier to maintain, much more stable and much faster. We're still using MongoDB for our analytics though, as it's inherently unstructured non-relational data, so MongoDB does actually do an okay job. Well, except for the run away memory usage which leads to k8s killing the DB server for violating memory constraints every so often. Yes, MongoDB itself is configured with memory constraints, it seems WiredTiger ignores them. Licensing was considered, however honestly MongoDB itself is (or at least was) so bad that licensing wasn't the primary motivating factor. EDIT: Just to clarify, most of our data is relational, however we do have some unstructured data in PSQL stored in JSONB columns. They work a treat and in some cases have complex indexes on them - they far out-perform anything MongoDB was able to offer us.
  - SergeAx 7y ago
    What is the point of running containerized DB server in production? Isn't it an anti-pattern?
    - Benjamin_Dobell 7y ago
      I wouldn't go as far as saying it's an anti-pattern. However, doing it properly is extremely difficult. Why do we do it? Cost saving. It's that simple. For your information, I wouldn't say we do it "properly" either. We do a decent job though. Basically, for us (and many other businesses) DBs are not the bottle-neck. Our business model facilitates a heap of static content that's served (via a CDN) without even hitting the DB. When the DB is used, it's 99% read-only; except for the analytics which aren't business critical. As with all things, it's a trade-off.
      - SergeAx 7y ago
        Sounds not that cost-saving for me when you mention that your not critical DB OOM-crashes here and there. How much do you saving, like $150/year on dedicated host?
- bszupnick 7y ago
  For my side project/startup (volunteer management and organisation for NGOs and political campaigns) I fell right into the trap. I'm not enough of a DB person to know if it was Mongo, or the ORM I was using (Waterline), but my data is extremely structured and relational. Once I switched over to Knex/Objection with a Postgres DB, everything went much smoother. The transition, though, took around two months, was hell, and I almost turned back many times.
worldsayshi 7y ago
What are the best alternatives to mongo db going forward? Are there any forks with momentum?
- awinter-py 7y ago
  depends on your requirements IMO the use case for mongodb in its heyday was great support for schema-less storage, which was perceived as a way to give your team velocity. And also great support for operating a cluster over primary keys. (The performance story vs SQL is overstated -- a lot of their early benchmarks were from tuning down safety margins like fsync. You can do that in SQL DBs too). postgres has pretty good json support these days and mysql is getting there (managed mysql tends to lag a version).
- chrischen 7y ago
  FoundationDB supports mongodb Query syntax.
- dividuum 7y ago
  There's a document layer for FoundationDB that seems to expose a MongoDB compatible API: https://www.foundationdb.org/blog/announcing-document-layer/ https://www.foundationdb.org/blog/announcing-document-layer/ No idea how that works as I don't have any experience with either of them.
- danenania 7y ago
  My current thinking is to consider postgres as the default choice, especially for an MVP. It can handle just about any MVP-level scenario and helps you avoid over-engineering. But if you really do need NoSQL to deal with scalability or more advanced requirements, I like DynamoDB. I like it not because it’s user-friendly (it’s not very), but because its limitations are very clear and out-front, and if you try to do something it’s not suited for, you’ll quickly realize it’s hopeless. Mongo is the opposite—it gives you the impression that you can use it for all kinds of things, and it feels easy in the beginning. But without careful planning, it will lead you merrily into awful traps, because its underlying limitations are glossed and patched over by the api rather than being made explicit.
whoevercares 7y ago
Should I sell MongoDB? In around $29 last year and have seen 450% return... The concern was always it becomes next X
- hxegon 7y ago
  I mean I'd argue if you're questioning it then you should get out because you A) already perceive enough risk that you consider it questionable and B) It sounds like you're sticking with it because you already have it and it's been a winner historically. But that doesn't mean you should stick with it :P Downsize or diversify Good luck!
- vosper 7y ago
  Can't tell you whether to sell or not, but I think there are going to be plenty of companies struggling under Mongo DB for a while (I work for one: we know it sucks, dislike using it, don't have the significant resources needed to get off. And the product is still growing rapidly, so we're getting more locked-in). At this point I think it's a coin-toss whether we move to an RDBMS or try to use their newish JSON Schema support (and other features) to achieve some sanity. And, to be fair, Mongo's hosted management console is really good, the support has been excellent, and since we switched over to their hosted solution I don't think we've had a single problem that wasn't of our own making.
- ISL 7y ago
  Hold what you are willing to hold if the market remains closed for the next five years.
- bongobongo 7y ago
  If you are asking questions like this you probably should not be buying individual stocks
  - deleted 7y ago
    [deleted]
- twblalock 7y ago
  They report earnings on Wednesday. We'll see if the license change had an impact on revenue. My guess is it won't have a big impact, because customers who care about the license being open source probably wouldn't have been paying MongoDB in the first place.
mlevental 7y ago
asked this on a sqllite thread before but: anyone know a single file nosqldb that has good python bindings. i know I could just write to json or something but I'd like something that supports queries. right now I'm using MongoDB and it's completely Overkill
- codefreakxff 7y ago
  Postgres supports querying json
  - paulhodge 7y ago
    Has anyone actually used json-based queries in PG in a nontrivial way, and had a good experience? I looked into it but the SQL syntax for doing json operations was crazy complicated, and I had trouble finding an ORM that did a good job of simplifying it.
    - nicoburns 7y ago
      What kind of non-trivial use cases do you have. I've found you generally just need to pick out a field using the JSON syntax, then you can use all of the normal SQL tools for fancier stuff...
    - striking 7y ago
      Yeah, I don't mind it. Oftentimes when you want to manipulate JSON, you'll embed a raw snippet of PG-specific SQL into the query you're building with your ORM. I do wish the operators were a little more ergonomic though. One of these days I'll print out the list and stick it to my monitor.
    - lacampbell 7y ago
      If your queries are that complicated are you not better off normalising your data, then writing views to jsonify it?
    - choicenotchance 7y ago
      For millions plus rows, the queries get crazy slow. If your jsonb field contains lot of data, JOINs on toast storage tables takes chunk of the query times. My 2 cents: Best to keep data normalized and in separate columns. If you gotta keep data in jsonb, keep only the data that you don't need to query on. Anything you need to query, you better put it as a column. You'll thank me later.
benatkin 7y ago
With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than millions of records. It's because of Django, not postgres, that I decided to use varchars to store the IDs rather than bytes or integers. Django is flexible but there are always tradeoffs from going outside the framework. Finally, and this is my favorite thing about how I went about it: all BSON ids have the column name of "id" and all integer primary keys have the column name of "pk", whether or not they have a BSON ID (through tables don't need their IDs exposed to the API).
- ldng 7y ago
  PostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.
  - pkrefta 7y ago
    This is exactly how it is. You can find confirmation in Postgres docs [1] [1] https://www.postgresql.org/docs/9.1/datatype-character.html https://www.postgresql.org/docs/9.1/datatype-character.html
  - benatkin 7y ago
    Interesting. When is there an advantage of using varchar in postgres, other than limiting the field length?
    - nicoburns 7y ago
      I think never, except if you want your SQL to be portable to other dbs.
zucker42 7y ago
Serious question: can someone explain why the server side public license is not an open source license, with specific reference to AGPL? Is it because of the provision forcing the source code release of auxillary software used to run the software as a service? As far as I can tell, it meets the FSF's free software definition and the only that seems questionable in the OSI's open source definition is point 9.
- chrisseaton 7y ago
  > can someone explain why the server side public license is not an open source license Depends on what you think 'open source' licence means. The source is literally openly available. There are just some extra restrictions on what you can do with it. The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
  - gwd 7y ago
    > The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence. Ref please? The FSF was certainly around pushing for "free software" long before "open source" was commonly used to refer to copyleft / permissive licenses. And the sole purpose for OSI's existence is exactly to define what is and is not "open source". In any case, it is very important to define terminology and protect its use. The goal of "open source" is certainly not to simply let people look at the source, but to let people use the source in certain ways. People have thought long and hard about exactly what the minimum standards are to consider something "free software" or "open source". You can find the core criteria for OSI here: https://opensource.org/osd https://opensource.org/osd And the "Four Freedoms" for the Free Software Foundation here: https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html
    - chrisseaton 7y ago
      > Ref please? Both ESR and the OSI will tell you this. For example http://www.catb.org/~esr/open-source.html http://www.catb.org/~esr/open-source.html > Yes, we're aware of the specialized meaning "open source" has in the intelligence community. This is a feature, not a bug. The OSI tried and failed to trademark 'open source' - because it's simply a description. https://opensource.org/pressreleases/certified-open-source.php https://opensource.org/pressreleases/certified-open-source.p... > We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive Maybe it turned out to be a bug after all!
trpc 7y ago
Can somebody tell me what is wrong is SSPL? I just don't understand what this hostility is all about. A company creates a crucial infrastructure component which is a database, open sources it, everybody can use it for free, cloud vendors started just installing it on their servers or making clones of it and making profit off it, everybody is using a component that took years and millions of dollars to develop but the company that created it cannot even get profit from its own product. I just can't understand why would a company open sources its products if this is the result. The product is free to use, but for profit entities using this product MUST pay the maker if they are using it as a SaaS which is a zero effort operation. This just doesn't happen in any other industry, if you go to a baker, you must pay for the bread, you can't in most cases even ask how this bread was made or know for sure that price was fair or not, and mind you this is just slice of bread, while in technology it takes years of experience and knowledge just to create something as crucial as a database, and yet people expect everything to be free, very liberal licensing to even profit from the product without sharing it with the original maker. I don't even like or even respect MongoDB as a database, but the amount of hostility towards anybody trying to make money off a FREE and OPEN SOURCE complex software is totally beyond me.
- alluro2 7y ago
  I, too, don't understand the hostility...It's not like they pulled parts of the code out and closed it (looking at you, Elastic), or even have "enterprise" paid features - they just want to prevent AWS et al. from hugely profiting off of their work, which is, in the long term, bad for everyone involved except partially AWS who would have to pay to sell it, thus keeping the development going...I'd expect this to be something that OS community would stand behind, as long as it's very defined and narrow-scoped like it seems it is to me...If anyone could give more color to explain the reasons for hostility, I'd be grateful
- tedivm 7y ago
  I don't think your baker metaphor holds up though, because a major component of open source software is that people outside of the companies support it. A better metaphor would be if the bakery had started by using volunteers to create all the recipes, and then the baker decided that people could only use those recipes if they followed his terms so that the baker could stop other bakeries from competing. This obviously upsets the people who contributed to the recipes thinking they would be open for anyone to use. Mongo started as an open source project, used that openness to build community (and indeed their product itself), and then pulled the rug out from under everyone to gain a competitive advantage.
orf 7y ago
From their official formula: https://github.com/mongodb/homebrew-brew/blob/master/Formula/mongodb-community%403.4.rb#L9 https://github.com/mongodb/homebrew-brew/blob/master/Formula... Every time I run `brew update` (or perhaps _any_ brew command), I make 6 requests to "https://downloads.mongodb.org/current.json" https://downloads.mongodb.org/current.json" (one for each version of the formula), and one request to get the SHA for mongdb-shell? This defaults the whole point of a formula - metadata describing an installable. If that .json file is compromised in any way then suddenly you are downloading anything from _anywhere_ with no checks. By embedding the hash and the download URL in the formula, like literally every other formula does, the download will fail if the release is modified. And there is a git audit trail of any formula modifications. No thanks.
elamje 7y ago
What’s the executive summary of what’s going on with Mongo, and why other commenters are referring to using mongo as a mistake?
- tedivm 7y ago
  MongoDB changed their licensed from an open source license to one that has restrictions specifically aimed at busting up Mongo (the company)'s competitors who offer managed MongoDB services. These restrictions mean it is no longer an open source project. It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money. Since mongo has reached the point where they're competing on license terms, not on service or via their product, mongodb may not be the best choice for someone starting a new project. At this point lots of other options exist, with stable and open source solutions like postgres having document store features built in as well. In fact for a lot of use cases postgres already performs much better than mongodb, leaving the real question to be why anyone would choose to use mongodb at this point.
  - SamReidHughes 7y ago
    > It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money. Ultimately this is only a worry for people who choose software that is apparently not good enough right now, but hope it will become good enough in the future.
    - makomk 7y ago
      It's a worry for people who choose software that they need to work in the future full stop. As someone else pointed out elsewhere in the thread, this is being removed partly because the previous open source version of MongoDB no longer builds from source, apparently due to some change to the toolchain or libraries. Normally you'd upgrade or backport upstream's fix, but that's no longer possible in a situation like this.
  - 7y ago
craigching 7y ago
A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.
- reaperducer 7y ago
  I may have a project coming up that will include a document store component. It's in-house, with the maximum number of simultaneous users under 15, so scalability that way isn't a concern. However, the number of documents is large, and for some documents previous versions will have to be stored, as well. With Mongo out, do you have any suggestions? Is PostgreSQL the best option here? I'm fairly new to this space.
  - edoceo 7y ago
    I do like this, millions of record, prime fields in the table, then a jsonb column as the document-store. Just add a row for a new version. And extracting detail from jsonb is pretty easy, usable in SqL queries and materialized views
  - kitotik 7y ago
    I just recently deployed a cockroachdb, and have been very happy with the results. For my use case, the JSONB columns are fantastic, and has much less deploy and admin overhead than Postgres.
- McGlockenshire 7y ago
  I asked myself this a few years ago and went to see who had thought of it first. At the time, the prevailing opinion was that this was a bad idea. Elasticsearch had no ACID data integrity guarantees at all at the time. Has this changed?
  - craigching 7y ago
nevi-me 7y ago
I understand the removal of non-OSS-compliant software from core distributions, and see little controversy in that, as it's the risk of changing a license. What I don't understand is the many people who are talking about AWS' replacement being a solution for people migrating from MongoDB. From the comments, it seems: - it's expensive to use. Someone spent $15 for 2KB data over 3 days [https://news.ycombinator.com/item?id=20862196 https://news.ycombinator.com/item?id=20862196] - it's only compatible with MongoDB 3.4, which seems not to be enough for some people. What are the reasons to move to AWS' very offering that MongoDB (and others) are trying to prevent from making money off their investment? Is it a feeling of 'betrayal' that the license has now changed? MongoDB has had an attitude that the source for the community product is available, but that they mostly develop their product using their core team. [https://www.techrepublic.com/article/mongodb-ceo-tells-hard-truths-about-commercial-open-source/ https://www.techrepublic.com/article/mongodb-ceo-tells-hard-...] So, did the change to their Server License thing result in people having to pay for the Community Edition? Is the move from MongoDB because it's incompatible with one's data needs (in which case, why didn't one do enough research)? Why move to AWS' offering instead of 'supporting' these companies? If AWS and Azure thought to create MongoDB Compatible abstraction layers, then surely they saw something useful/good in parts of the database? Then why punish the companies that innovated in creating these technologies? Lastly, the idea that companies will be fully-OSS and make money from unicorn dust fails once those holding these opinions are on the driver's seat. How many foundations do you donate to, that support the OSS that you use? The current trend of continuing to want things for free from companies, but being willing to spend an extra fee for a 'managed service' from a cloud provider will hurt a lot of otherwise innovative companies in the coming decade.
- truth_seeker 7y ago
  Ditto
- DangitBobby 7y ago
  If people accept that what MongoDB did with its license is acceptable because the OSS model failed for them, then the viability and future of the OSS model might come into question. People tend to come to believe something organically and then later cherry-pick facts and observations that back those beliefs up. So even if MongoDB did what it had to do, or did what would otherwise be morally defensible in the most popular moral frameworks (as I personally believe to be the case), people who have a personal or emotional stake in the future of OSS will be looking outwardly for a villain. If it failed, it must be a failure of someone who crossed OSS. MongoDB seems the only choice for a villain in that regard.
mark_l_watson 7y ago
I have a question: has anyone simply forked MongoDB from the time just before the license change? Owners of open source software can change the license, but can they change the license of old code?
- zeta0134 7y ago
  IANAL, but this happens fairly often within the community. My loose understanding is that code released under the AGPL remains licensed under the AGPL; the license can't just be retroactively revoked like that. The company may require that active forks adopt a new name and branding due to trademark disputes, but this is a different matter not covered by the license. I was not able to find an active fork; the closest thing I'm finding so far is here, but it hasn't seen any activity for 7 months: https://github.com/normousdb/normous https://github.com/normousdb/normous
  - mark_l_watson 7y ago
    Very cool, thank you. It seems like the original AGPL license should have worked for companies like MongoDB. But, their company, they can do what they like and lose users.
Proven 7y ago
WTF, people just want to install stuff, that's what a package manager is supposed to do.
elevenbits 7y ago
I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale? Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice? If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.
- kentrado 7y ago
  I have no pity for MongoDB, they chose to license their stuff open source. Which means they should have no problem with people profiting from their work, that's the spirit of FOSS. Of course, this is just one of the many so called "open source" companies that chose open source because they thought it would get them more users but in reality don't care much about FOSS.
- bad_user 7y ago
  We live in the world where we can see a bait and switch for what it is. MongoDB was advertised as being Open Source and Free Software, distributed under an OSI-compliant and FSF-compliant license. Now they are trying to eat their cake and have it too. > "then are lambasted when they try to prevent a competitor from copying it wholesale?" Because that's not what open source is about. Open source is about contributing to the commons, such that your competitors can make a profit from your work. If your competitors aren't able to do that, then the software is not open source. Period. And in this case, we should point out that MongoDB Inc by owning the copyright doesn't have to play by the same rules, they aren't beholden to the same rules as everyone else. > "If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be?" Why the fuck should we care what their business model would be? That's for them to figure out. But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, like lock in, etc. So I hope somebody forks MongoDB from the version when it was open source.
holografix 7y ago
Can’t we trace a clear line that says: “Here is my new tech. It’s FOSS you can access the code and use it for free to build other technologies with it. You may not simply provide my tech as a service and charge money for that’s my biz model” Example: Here’s a fantastic new mixing machine. You can make your own for free and use it in other applications such as making smoothies or cakes. You may not start an industrial mixing biz and charge money for it. That’s my biz model.
- OJFord 7y ago
  My understanding (from asking the same before) is that: * Yes, but that's de facto _not_ open source, because all OS licences allow commercial use by definition; * A licence isn't a magic bullet, you can have this model but if you're not prepared to enforce it it's useless.
  - filleduchaos 7y ago
    > Yes, but that's de facto _not_ open source, because all OS licences allow commercial use by definition; The idea is probably that one would have to pay for commercial usage, which absolutely is compatible with open source.
  - holografix 7y ago
    Thanks for letting us know!
PeterZaitsev 7y ago
I think this article is very relevant to this discussion https://opensource.com/article/19/8/open-source-licensing#comments https://opensource.com/article/19/8/open-source-licensing#co...

252 points by codyogden 7y ago

Play stupid license games, get stupid prizes?

Would love to see an overview of companies that fell into the mongoDB trap and have / are migrating to another DB store.

mikeryan 7y ago
Over the last few Months we’ve switched over to amazons document db just to have a managed service. We don’t regret it.
- nailer 7y ago
  DocumentDB is still really expensive as there's no pay what you use option. I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake. They really need to come up with a per mb per hour option.
  - qeternity 7y ago
    What?!? I’m a big AWS skeptic for most people but this sounds insane. Details?
    - smnrchrds 7y ago
      The cheapest option is 0.277$/hr just for the instance. https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/
      - chii 7y ago
        It's interesting that people would pay amazon, but not mongodb...
        threeseed 7y ago
        I work in the enterprise and we spend tens of millions a year with AWS. Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product. With a managed MongoDB (even though it's on AWS) you need to get buy in from dozens of people and go a vendor comparison to get through Procurement. It's why for many companies AWS dominates and in the future could well end up owning everything under the application layer.
        chii 7y ago
        I guess nobody got fired for buying IBM is still true to this day and age.
        nevi-me 7y ago
        This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in? There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of processes". We had a large local bank choose not to pursue a good opportunity because "our procurement process takes too long". This instead of investing in fixing the procurement process.
        mbreese 7y ago
        If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.
    - rad_gruchalski 7y ago
      https://aws.amazon.com/documentdb/pricing/ https://aws.amazon.com/documentdb/pricing/ At $0.277 it’s $19.94 for 72 hours.
  - cj 7y ago
    I spend somewhere around $30-40k / yr on AWS (EC2) for a 3 member replica set. I evaluated DocumentDB and price wasn’t the issue (at our scale, the price is OK). Main blocker is that it’s locked at Mongo 3.4 API compatibility, which is several major versions behind. But worse, their implementation of the 3.4 API is incomplete, so while they advertise “Mongo Compatible”, it really isn’t a drop in replacement.
  - farisjarrah 7y ago
    Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.
- threeseed 7y ago
  Super expensive and orders of magnitude slower in some cases. As much as I love a managed service this was a very disappointing effort from AWS.
benologist 7y ago
I would love to see open source developers and companies supported because it's not really tenable to replace all the open source we rely on - we probably need 20 million lines of open source to serve a HTML page. If we were actually enabling and empowering open source developers, and especially the people learning, it would be awesome. Enabling people like Torvalds and Stallman to grow into their role of writing stuff that benefits billions of people. But we can do Hunger Games too. There's no wrong answers.
- mruts 7y ago
  I dunno, I could do it in 200 of good code in C.
  - est31 7y ago
    Including kernel, network driver, etc?
    - mruts 7y ago
      I guess not no, I was thinking of userland.
      - est31 7y ago
        You can make a simple HTTP/1.1 server in 200 lines of good C. Not one that runs HTTP/3.0 including QUIC and TLS.
        cameronbrown 7y ago
        HTTP 3 isn't even in production yet.
        xchaotic 7y ago
        Define production and define HTTP3. The beauty of open source is that you can be already serving pages using QUIC and TLS1.3 while the standard is being finalised.
shanev 7y ago
Coinbase comes to mind.
taylorlapeyre 7y ago
Didn’t Stripe go down this road?
- enraged_camel 7y ago
  Yes, in addition they apparently use a pretty outdated version of it. (Several people mentioned this on a related HN thread that I'm having trouble locating.)
  - delhanty 7y ago
    It was claimed here [0] >... they continue to build on top of a broken foundation (MongoDB) ...but last I heard Stripe was still running a very outdated version ... [0]https://news.ycombinator.com/item?id=20820879 https://news.ycombinator.com/item?id=20820879
threeseed 7y ago
If you are looking for a document store there aren't many alternatives. And one of the positive elements of MongoDB has been that they acknowledged their many issues and have over the years been fixing them one by one. Whilst alternatives have largely been stagnating. And I am still yet to find any database that even comes close to its single tuple update speed.
- mfer 7y ago
  Have you looked at postgresql document store? Amazon put a mongodb API on that and made a service after all
  - threeseed 7y ago
    1) No that's not what AWS did at all. They implemented the MongoDB API on top of their own storage layer. It doesn't use PostgreSQL. 2) Of course. But MongoDB is orders of magnitude faster in some cases, has better horizontal scalability capabilities, better drivers and some nicer semantics e.g. around streaming.
    - species9606 7y ago
      It’s webscale!
      - hombre_fatal 7y ago
        I actually recognize threeseed's name over the past five years as being a staunch MongoDB proponent. https://hn.algolia.com/?sort=byPopularity&prefix&page=0&dateRange=all&type=comment&query=threeseed%20mongodb https://hn.algolia.com/?sort=byPopularity&prefix&page=0&date... No hate, just always amused me that someone on HN had MongoDB as their hobby horse.
    - phonon 7y ago
      https://news.ycombinator.com/item?id=18870397 https://news.ycombinator.com/item?id=18870397
Thorrez 7y ago
What you do mean by the "mongoDB trap"? Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?
- zxcvbn4038 7y ago
  A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought. Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license. If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.
  - scarface74 7y ago
    But Mongodb is so different from anything else that you need a major rewrite to get away from it. Well actually.... One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.
    - 6nf 7y ago
      So why not just use a RDMS from day one?
      - scarface74 7y ago
        Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? In C# var seniorMales = from c in context.Customers where c.Age > 65 && c.Sex == “M” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. You get autocomplete and compile time checks. When you want to add an record to your Mongo collection, you work with strongly typed IMongoCollection<Customer> And the compiler will ensure that your collection stays consistent.
peteretep 7y ago
Include in that any of the many companies still using Perl, for whom MongoDB have dropped library support.
pfarnsworth 7y ago
Ubiquiti is one of those companies. They use MongoDB for their controller app, which has been a pain in my side for a couple of years now.
truth_seeker 7y ago
I am neither for MongoDB or for any famous ABC or XYZ DB. But before I make my decision to change to any other DB, i evaluate my using my own conscience and not depend upon bashing of any X DB on the internet. I had the opportunity to redesign the architectures of few productions running apps because of this superstition "Companies are falling due to MongoDB, lets switch to another DB" Every single time, as an architect I have found that developers are just being fancy about their first-hand experience with some other database and they are unable to think in new direction which MongoDB is built for. Following are the things most people miss: 1. MongoDB is not safe/secure. Anyone can hack it -> the default configuration were not optimized in previous MongoDB version but it doesn't mean it lacked User security API. 2. MongoDB does not support JOINs or query API just sucks -> No, it doesn't. First, You need to learn about denormalization and schema handling. Second, MongoDB supports JOIN semantics such as $lookup & $graphLookup. Third, it supports ElasticSearch like text searching capabilities and scoring. Fourth, it supports data aggregation pipelines with various ways to compose the data transforming operations including above 2. 3. It does not have triggers like RDBMS -> It has "change streams" which is more flexible than Trigger. This feature also enables multiple application servers in microservice architecture to use MongoDB as a central store. Want a custom ETL streaming pipeline? You got it. 4. It does not scale like ABC or XYZ DB -> Again understand point #2. Also, look into docs how distributed sharding works across replica sets. Spend some quality time figuring out what should be the KeyField to be used for distributed sharding of Data. 5. Licencing sucks -> Have you understood the whole project cost and complexity ? Have you actually looked at all the terms and conditions or are you just a big fan of OSS and for that you can support any stupid alternative?
- deleted 7y ago
  [deleted]
- octohedron 7y ago
  As someone with several years of experience with both RDBs and mongodb, I totally agree with everything you said. Also, you got downvoted by the same people that upvoted the stackoverflow post on the problems of downvoting on technical problems on the internet. People might not like or know the technology and are guided by older tech gurus from the previous generation such as Edgar Frank "Ted" Codd, although he was a genius, now the market is much larger and there's a lot more use cases. Additionally, most people know RDBs such as mysql and that's what they are comfortable with, i.e. can't get out of their comfort zone and give an honest and good try to something else or don't even have time. Also it's what's taught in courses as superior to non relational databases. I would not change our MongoDB clusters for Postgres/MySQL/etc even if I could do it with a single command. In this case it's not relational data though, for a large business relational model I would stick with RDBs.
IloveHN84 7y ago
A lot of startups for sure
Benjamin_Dobell 7y ago
I inherited a MongoDB Ruby (Mongoid) stack that was a terrible choice for the data stored (i.e. relational data). Actually, I'm not really sure why Mongoid exists at all. After several years of pain e.g. cursor timeouts (even when supposedly disabled), iterating over the same document multiple times in the one query etc. and of course no transactions (since added). I eventually migrated to PSQL (using some custom scripts) and everything is so much easier to maintain, much more stable and much faster. We're still using MongoDB for our analytics though, as it's inherently unstructured non-relational data, so MongoDB does actually do an okay job. Well, except for the run away memory usage which leads to k8s killing the DB server for violating memory constraints every so often. Yes, MongoDB itself is configured with memory constraints, it seems WiredTiger ignores them. Licensing was considered, however honestly MongoDB itself is (or at least was) so bad that licensing wasn't the primary motivating factor. EDIT: Just to clarify, most of our data is relational, however we do have some unstructured data in PSQL stored in JSONB columns. They work a treat and in some cases have complex indexes on them - they far out-perform anything MongoDB was able to offer us.
- SergeAx 7y ago
  What is the point of running containerized DB server in production? Isn't it an anti-pattern?
  - Benjamin_Dobell 7y ago
    I wouldn't go as far as saying it's an anti-pattern. However, doing it properly is extremely difficult. Why do we do it? Cost saving. It's that simple. For your information, I wouldn't say we do it "properly" either. We do a decent job though. Basically, for us (and many other businesses) DBs are not the bottle-neck. Our business model facilitates a heap of static content that's served (via a CDN) without even hitting the DB. When the DB is used, it's 99% read-only; except for the analytics which aren't business critical. As with all things, it's a trade-off.
    - SergeAx 7y ago
      Sounds not that cost-saving for me when you mention that your not critical DB OOM-crashes here and there. How much do you saving, like $150/year on dedicated host?
bszupnick 7y ago
For my side project/startup (volunteer management and organisation for NGOs and political campaigns) I fell right into the trap. I'm not enough of a DB person to know if it was Mongo, or the ORM I was using (Waterline), but my data is extremely structured and relational. Once I switched over to Knex/Objection with a Postgres DB, everything went much smoother. The transition, though, took around two months, was hell, and I almost turned back many times.

worldsayshi 7y ago

What are the best alternatives to mongo db going forward? Are there any forks with momentum?

awinter-py 7y ago
depends on your requirements IMO the use case for mongodb in its heyday was great support for schema-less storage, which was perceived as a way to give your team velocity. And also great support for operating a cluster over primary keys. (The performance story vs SQL is overstated -- a lot of their early benchmarks were from tuning down safety margins like fsync. You can do that in SQL DBs too). postgres has pretty good json support these days and mysql is getting there (managed mysql tends to lag a version).
chrischen 7y ago
FoundationDB supports mongodb Query syntax.
dividuum 7y ago
There's a document layer for FoundationDB that seems to expose a MongoDB compatible API: https://www.foundationdb.org/blog/announcing-document-layer/ https://www.foundationdb.org/blog/announcing-document-layer/ No idea how that works as I don't have any experience with either of them.
danenania 7y ago
My current thinking is to consider postgres as the default choice, especially for an MVP. It can handle just about any MVP-level scenario and helps you avoid over-engineering. But if you really do need NoSQL to deal with scalability or more advanced requirements, I like DynamoDB. I like it not because it’s user-friendly (it’s not very), but because its limitations are very clear and out-front, and if you try to do something it’s not suited for, you’ll quickly realize it’s hopeless. Mongo is the opposite—it gives you the impression that you can use it for all kinds of things, and it feels easy in the beginning. But without careful planning, it will lead you merrily into awful traps, because its underlying limitations are glossed and patched over by the api rather than being made explicit.

whoevercares 7y ago

Should I sell MongoDB? In around $29 last year and have seen 450% return... The concern was always it becomes next X

hxegon 7y ago
I mean I'd argue if you're questioning it then you should get out because you A) already perceive enough risk that you consider it questionable and B) It sounds like you're sticking with it because you already have it and it's been a winner historically. But that doesn't mean you should stick with it :P Downsize or diversify Good luck!
vosper 7y ago
Can't tell you whether to sell or not, but I think there are going to be plenty of companies struggling under Mongo DB for a while (I work for one: we know it sucks, dislike using it, don't have the significant resources needed to get off. And the product is still growing rapidly, so we're getting more locked-in). At this point I think it's a coin-toss whether we move to an RDBMS or try to use their newish JSON Schema support (and other features) to achieve some sanity. And, to be fair, Mongo's hosted management console is really good, the support has been excellent, and since we switched over to their hosted solution I don't think we've had a single problem that wasn't of our own making.
ISL 7y ago
Hold what you are willing to hold if the market remains closed for the next five years.
bongobongo 7y ago
If you are asking questions like this you probably should not be buying individual stocks
- deleted 7y ago
  [deleted]
twblalock 7y ago
They report earnings on Wednesday. We'll see if the license change had an impact on revenue. My guess is it won't have a big impact, because customers who care about the license being open source probably wouldn't have been paying MongoDB in the first place.

mlevental 7y ago

asked this on a sqllite thread before but: anyone know a single file nosqldb that has good python bindings. i know I could just write to json or something but I'd like something that supports queries. right now I'm using MongoDB and it's completely Overkill

codefreakxff 7y ago
Postgres supports querying json
- paulhodge 7y ago
  Has anyone actually used json-based queries in PG in a nontrivial way, and had a good experience? I looked into it but the SQL syntax for doing json operations was crazy complicated, and I had trouble finding an ORM that did a good job of simplifying it.
  - nicoburns 7y ago
    What kind of non-trivial use cases do you have. I've found you generally just need to pick out a field using the JSON syntax, then you can use all of the normal SQL tools for fancier stuff...
  - striking 7y ago
    Yeah, I don't mind it. Oftentimes when you want to manipulate JSON, you'll embed a raw snippet of PG-specific SQL into the query you're building with your ORM. I do wish the operators were a little more ergonomic though. One of these days I'll print out the list and stick it to my monitor.
  - lacampbell 7y ago
    If your queries are that complicated are you not better off normalising your data, then writing views to jsonify it?
  - choicenotchance 7y ago
    For millions plus rows, the queries get crazy slow. If your jsonb field contains lot of data, JOINs on toast storage tables takes chunk of the query times. My 2 cents: Best to keep data normalized and in separate columns. If you gotta keep data in jsonb, keep only the data that you don't need to query on. Anything you need to query, you better put it as a column. You'll thank me later.

benatkin 7y ago

With MongoDB's license there is another reason to migrate away from it. I migrated an app from MongoDB to postgres. I ended up just using a varchar to store the IDs. The Mongo style IDs are in addition to an integer primary key, so joins happen with integers, but every time a user is shown the IDs, in the URLs, it's a BSON ID. It hasn't caused any issues, performance or otherwise, but there are thousands rather than millions of records. It's because of Django, not postgres, that I decided to use varchars to store the IDs rather than bytes or integers. Django is flexible but there are always tradeoffs from going outside the framework. Finally, and this is my favorite thing about how I went about it: all BSON ids have the column name of "id" and all integer primary keys have the column name of "pk", whether or not they have a BSON ID (through tables don't need their IDs exposed to the API).

ldng 7y ago
PostgreSQL do have a variable unlimited length datatype : text. AFAIK, Varchar is internally a subtype that bound the text type. So in extreme situations you might even get a very slight performance advantage using text instead of varchar.
- pkrefta 7y ago
  This is exactly how it is. You can find confirmation in Postgres docs [1] [1] https://www.postgresql.org/docs/9.1/datatype-character.html https://www.postgresql.org/docs/9.1/datatype-character.html
- benatkin 7y ago
  Interesting. When is there an advantage of using varchar in postgres, other than limiting the field length?
  - nicoburns 7y ago
    I think never, except if you want your SQL to be portable to other dbs.

zucker42 7y ago

Serious question: can someone explain why the server side public license is not an open source license, with specific reference to AGPL? Is it because of the provision forcing the source code release of auxillary software used to run the software as a service? As far as I can tell, it meets the FSF's free software definition and the only that seems questionable in the OSI's open source definition is point 9.

chrisseaton 7y ago
> can someone explain why the server side public license is not an open source license Depends on what you think 'open source' licence means. The source is literally openly available. There are just some extra restrictions on what you can do with it. The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence.
- gwd 7y ago
  > The FSF and the OSI don't own what 'open source' means, of course - the term predates them and comes from intelligence. Ref please? The FSF was certainly around pushing for "free software" long before "open source" was commonly used to refer to copyleft / permissive licenses. And the sole purpose for OSI's existence is exactly to define what is and is not "open source". In any case, it is very important to define terminology and protect its use. The goal of "open source" is certainly not to simply let people look at the source, but to let people use the source in certain ways. People have thought long and hard about exactly what the minimum standards are to consider something "free software" or "open source". You can find the core criteria for OSI here: https://opensource.org/osd https://opensource.org/osd And the "Four Freedoms" for the Free Software Foundation here: https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html
  - chrisseaton 7y ago
    > Ref please? Both ESR and the OSI will tell you this. For example http://www.catb.org/~esr/open-source.html http://www.catb.org/~esr/open-source.html > Yes, we're aware of the specialized meaning "open source" has in the intelligence community. This is a feature, not a bug. The OSI tried and failed to trademark 'open source' - because it's simply a description. https://opensource.org/pressreleases/certified-open-source.php https://opensource.org/pressreleases/certified-open-source.p... > We have discovered that there is virtually no chance that the U.S. Patent and Trademark Office would register the mark "open source"; the mark is too descriptive Maybe it turned out to be a bug after all!

trpc 7y ago

Can somebody tell me what is wrong is SSPL? I just don't understand what this hostility is all about. A company creates a crucial infrastructure component which is a database, open sources it, everybody can use it for free, cloud vendors started just installing it on their servers or making clones of it and making profit off it, everybody is using a component that took years and millions of dollars to develop but the company that created it cannot even get profit from its own product. I just can't understand why would a company open sources its products if this is the result. The product is free to use, but for profit entities using this product MUST pay the maker if they are using it as a SaaS which is a zero effort operation. This just doesn't happen in any other industry, if you go to a baker, you must pay for the bread, you can't in most cases even ask how this bread was made or know for sure that price was fair or not, and mind you this is just slice of bread, while in technology it takes years of experience and knowledge just to create something as crucial as a database, and yet people expect everything to be free, very liberal licensing to even profit from the product without sharing it with the original maker. I don't even like or even respect MongoDB as a database, but the amount of hostility towards anybody trying to make money off a FREE and OPEN SOURCE complex software is totally beyond me.

alluro2 7y ago
I, too, don't understand the hostility...It's not like they pulled parts of the code out and closed it (looking at you, Elastic), or even have "enterprise" paid features - they just want to prevent AWS et al. from hugely profiting off of their work, which is, in the long term, bad for everyone involved except partially AWS who would have to pay to sell it, thus keeping the development going...I'd expect this to be something that OS community would stand behind, as long as it's very defined and narrow-scoped like it seems it is to me...If anyone could give more color to explain the reasons for hostility, I'd be grateful
tedivm 7y ago
I don't think your baker metaphor holds up though, because a major component of open source software is that people outside of the companies support it. A better metaphor would be if the bakery had started by using volunteers to create all the recipes, and then the baker decided that people could only use those recipes if they followed his terms so that the baker could stop other bakeries from competing. This obviously upsets the people who contributed to the recipes thinking they would be open for anyone to use. Mongo started as an open source project, used that openness to build community (and indeed their product itself), and then pulled the rug out from under everyone to gain a competitive advantage.

orf 7y ago

From their official formula: https://github.com/mongodb/homebrew-brew/blob/master/Formula/mongodb-community%403.4.rb#L9 https://github.com/mongodb/homebrew-brew/blob/master/Formula... Every time I run `brew update` (or perhaps _any_ brew command), I make 6 requests to "https://downloads.mongodb.org/current.json" https://downloads.mongodb.org/current.json" (one for each version of the formula), and one request to get the SHA for mongdb-shell? This defaults the whole point of a formula - metadata describing an installable. If that .json file is compromised in any way then suddenly you are downloading anything from _anywhere_ with no checks. By embedding the hash and the download URL in the formula, like literally every other formula does, the download will fail if the release is modified. And there is a git audit trail of any formula modifications. No thanks.

elamje 7y ago

What’s the executive summary of what’s going on with Mongo, and why other commenters are referring to using mongo as a mistake?

tedivm 7y ago
MongoDB changed their licensed from an open source license to one that has restrictions specifically aimed at busting up Mongo (the company)'s competitors who offer managed MongoDB services. These restrictions mean it is no longer an open source project. It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money. Since mongo has reached the point where they're competing on license terms, not on service or via their product, mongodb may not be the best choice for someone starting a new project. At this point lots of other options exist, with stable and open source solutions like postgres having document store features built in as well. In fact for a lot of use cases postgres already performs much better than mongodb, leaving the real question to be why anyone would choose to use mongodb at this point.
- SamReidHughes 7y ago
  > It is also worrying for a lot of people that mongo was willing to change license terms like this, as it means they may be willing to do so in the future if it brings them more money. Ultimately this is only a worry for people who choose software that is apparently not good enough right now, but hope it will become good enough in the future.
  - makomk 7y ago
    It's a worry for people who choose software that they need to work in the future full stop. As someone else pointed out elsewhere in the thread, this is being removed partly because the previous open source version of MongoDB no longer builds from source, apparently due to some change to the toolchain or libraries. Normally you'd upgrade or backport upstream's fix, but that's no longer possible in a situation like this.
- 7y ago

craigching 7y ago

A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.

reaperducer 7y ago
I may have a project coming up that will include a document store component. It's in-house, with the maximum number of simultaneous users under 15, so scalability that way isn't a concern. However, the number of documents is large, and for some documents previous versions will have to be stored, as well. With Mongo out, do you have any suggestions? Is PostgreSQL the best option here? I'm fairly new to this space.
- edoceo 7y ago
  I do like this, millions of record, prime fields in the table, then a jsonb column as the document-store. Just add a row for a new version. And extracting detail from jsonb is pretty easy, usable in SqL queries and materialized views
- kitotik 7y ago
  I just recently deployed a cockroachdb, and have been very happy with the results. For my use case, the JSONB columns are fantastic, and has much less deploy and admin overhead than Postgres.
McGlockenshire 7y ago
I asked myself this a few years ago and went to see who had thought of it first. At the time, the prevailing opinion was that this was a bad idea. Elasticsearch had no ACID data integrity guarantees at all at the time. Has this changed?
- craigching 7y ago

nevi-me 7y ago

I understand the removal of non-OSS-compliant software from core distributions, and see little controversy in that, as it's the risk of changing a license. What I don't understand is the many people who are talking about AWS' replacement being a solution for people migrating from MongoDB. From the comments, it seems: - it's expensive to use. Someone spent $15 for 2KB data over 3 days [https://news.ycombinator.com/item?id=20862196 https://news.ycombinator.com/item?id=20862196] - it's only compatible with MongoDB 3.4, which seems not to be enough for some people. What are the reasons to move to AWS' very offering that MongoDB (and others) are trying to prevent from making money off their investment? Is it a feeling of 'betrayal' that the license has now changed? MongoDB has had an attitude that the source for the community product is available, but that they mostly develop their product using their core team. [https://www.techrepublic.com/article/mongodb-ceo-tells-hard-truths-about-commercial-open-source/ https://www.techrepublic.com/article/mongodb-ceo-tells-hard-...] So, did the change to their Server License thing result in people having to pay for the Community Edition? Is the move from MongoDB because it's incompatible with one's data needs (in which case, why didn't one do enough research)? Why move to AWS' offering instead of 'supporting' these companies? If AWS and Azure thought to create MongoDB Compatible abstraction layers, then surely they saw something useful/good in parts of the database? Then why punish the companies that innovated in creating these technologies? Lastly, the idea that companies will be fully-OSS and make money from unicorn dust fails once those holding these opinions are on the driver's seat. How many foundations do you donate to, that support the OSS that you use? The current trend of continuing to want things for free from companies, but being willing to spend an extra fee for a 'managed service' from a cloud provider will hurt a lot of otherwise innovative companies in the coming decade.

truth_seeker 7y ago
Ditto
DangitBobby 7y ago
If people accept that what MongoDB did with its license is acceptable because the OSS model failed for them, then the viability and future of the OSS model might come into question. People tend to come to believe something organically and then later cherry-pick facts and observations that back those beliefs up. So even if MongoDB did what it had to do, or did what would otherwise be morally defensible in the most popular moral frameworks (as I personally believe to be the case), people who have a personal or emotional stake in the future of OSS will be looking outwardly for a villain. If it failed, it must be a failure of someone who crossed OSS. MongoDB seems the only choice for a villain in that regard.

mark_l_watson 7y ago

I have a question: has anyone simply forked MongoDB from the time just before the license change? Owners of open source software can change the license, but can they change the license of old code?

zeta0134 7y ago
IANAL, but this happens fairly often within the community. My loose understanding is that code released under the AGPL remains licensed under the AGPL; the license can't just be retroactively revoked like that. The company may require that active forks adopt a new name and branding due to trademark disputes, but this is a different matter not covered by the license. I was not able to find an active fork; the closest thing I'm finding so far is here, but it hasn't seen any activity for 7 months: https://github.com/normousdb/normous https://github.com/normousdb/normous
- mark_l_watson 7y ago
  Very cool, thank you. It seems like the original AGPL license should have worked for companies like MongoDB. But, their company, they can do what they like and lose users.

Proven 7y ago

WTF, people just want to install stuff, that's what a package manager is supposed to do.

elevenbits 7y ago

I'm astonished at all the comments that vilify MongoDB Inc and then talk about moving to AWS's MongoDB clone. What sort of twisted world are we living in where a company makes a service, tries to sell the service, and then are lambasted when they try to prevent a competitor from copying it wholesale? Cloud providers have been able to stand on the shoulders of giants, profiting immensely from millions of lines of open source code while giving little of it back, and we seem to be largely fine with this. Will we be fine depending on their services when the cloud providers become the new Oracle, free to raise prices extravagantly when we have no other choice? If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be? Licensing to cloud providers would have been ideal, but the response from AWS in this case wasn't encouraging. By boycotting MongoDB in this case are we telling future innovators that their work will simply be stolen and resold for profit if it gets popular? That scares me a lot more than some project changing their license.

kentrado 7y ago
I have no pity for MongoDB, they chose to license their stuff open source. Which means they should have no problem with people profiting from their work, that's the spirit of FOSS. Of course, this is just one of the many so called "open source" companies that chose open source because they thought it would get them more users but in reality don't care much about FOSS.
bad_user 7y ago
We live in the world where we can see a bait and switch for what it is. MongoDB was advertised as being Open Source and Free Software, distributed under an OSI-compliant and FSF-compliant license. Now they are trying to eat their cake and have it too. > "then are lambasted when they try to prevent a competitor from copying it wholesale?" Because that's not what open source is about. Open source is about contributing to the commons, such that your competitors can make a profit from your work. If your competitors aren't able to do that, then the software is not open source. Period. And in this case, we should point out that MongoDB Inc by owning the copyright doesn't have to play by the same rules, they aren't beholden to the same rules as everyone else. > "If MongoDB Inc can't compete in the enterprise cloud market simply because they are not AWS (as mentioned by threeseed), what should their business model be?" Why the fuck should we care what their business model would be? That's for them to figure out. But if they sell something as open source and they close source it, then we, the schmucks that bought into it, will point out that MongoDB is no longer open source and treat it as a proprietary piece that comes with the caveats of proprietary software, like lock in, etc. So I hope somebody forks MongoDB from the version when it was open source.

holografix 7y ago

Can’t we trace a clear line that says: “Here is my new tech. It’s FOSS you can access the code and use it for free to build other technologies with it. You may not simply provide my tech as a service and charge money for that’s my biz model” Example: Here’s a fantastic new mixing machine. You can make your own for free and use it in other applications such as making smoothies or cakes. You may not start an industrial mixing biz and charge money for it. That’s my biz model.

OJFord 7y ago
My understanding (from asking the same before) is that: * Yes, but that's de facto _not_ open source, because all OS licences allow commercial use by definition; * A licence isn't a magic bullet, you can have this model but if you're not prepared to enforce it it's useless.
- filleduchaos 7y ago
  > Yes, but that's de facto _not_ open source, because all OS licences allow commercial use by definition; The idea is probably that one would have to pay for commercial usage, which absolutely is compatible with open source.
- holografix 7y ago
  Thanks for letting us know!

PeterZaitsev 7y ago

I think this article is very relevant to this discussion https://opensource.com/article/19/8/open-source-licensing#comments https://opensource.com/article/19/8/open-source-licensing#co...