Long time lurker, (I think?) first time poster.
Just figured I would note, I added to MongoDB today:
– They have a ridiculously large short position against them. If they have a beat on earnings, that could result in some fireworks.
– I have seen a bunch of use cases where they are fitting quite nicely in enterprise architectures.
No question, this will move a lot earnings.
I for one am bullish for 2 specific reasons.
Database creation is booming, and I believe NoSQL is the future. For those that don’t know, databases have primarily been in SQL language. NoSQL is different where it allows storage of “unstructured data”. I am not expert, but from what I gather this is a much more flexible storage system than the original SQL databases. That’s not to say NoSQL is altogether better than SQL, their use cases are different, and SQL might be better for certain cases.
Whenever something becomes something you see on a resume, I think it has staying power. I’m a junior in college, and while looking at certain job offerings, I see some requiring NoSQL/MongoDB experience. To me this is a great sign for the company’s future. The other company I compare to this point is Salesforce (CRM) who have had great results since their IPO.
I strongly believe in both the long term and short term prospects for MDB, and I expect their run to continue.
-Brennan
Long MDB (Shares + some 9/21 call options)
Brennan do the requirements on the resume specifically state “NoSQL/Mongo” or just No/SQL?
When you read on the internet it is the former similar to how Oracle became the SQL in the end as it became such the standard.
Thanks.
Tinker
Depends on the application, some do specifically state MongoDB by name. I’m mostly looking at consulting, not computer engineering jobs, so I haven’t looked at a crazy enough number to give you an accurate breakdown on this.
I figure I would weigh in on Mongo’s long term prospects – as a software engineer for 25 years.
First off, in most cases, I see any technology edge a company has as being less than five years. There are technology themes that companies can ride, but they have to change with it. The core to all these revenue beasts is solving a a) fortune 500 problem b) saves time/dev cost, and c_) lets you build something maintainable. The whole Mongo plus Node does a and b, but not c. But it doesn’t matter for another five years, because you don’t learn the mess you made for that long. Plus, all the kids in school like it.
The place Mongo fits in is as a quick layer for presentation… You aren’t going to use it for heavy back end lifting, but for certain areas that are throwaway/always changing…presentation tiers, data ingest, product and images for presentation, simple fast event stores, etc. It’s an area where doing a full database in Oracle/Maria/SqlServer/Postgres is probably not worth it…but a lot of older folks would argue that’s not the case…and I am going to guess once the 21 years olds are 31 year olds, after they have built systems, and watch the pain the made for themselves operationally, and moved on to their third or fourth company, they may reconsider…
Career wise, coming out of school, great, learn Mongo. …but realize you will change it out 20 ways to Sunday over the next 10 years…with JSON and more optimized formats (avro, etc.) holding course (they won’t go away…
So what do I expect of Mongo? If enterprises are going to give the next generation of software engineers the tools they want, this is one of em. They have a place in the stack. But Mongo’s best way to long term life will be to get eaten by Oracle (and then destroyed). But right now, they are the nosql choice for document store, and can probably make a run at some IOT use cases. So they have a chance to, at least for one or two business cycles, earn some moolah.
Career wise, coming out of school, great, learn Mongo. …but realize you will change it out 20 ways to Sunday over the next 10 years…
That’s the way IT has always been. My business partner used to say that change is the only constant around here.
Denny Schlesinger
Indeed, one use be agile. However, SQL with Oracle lasted for multiple decades. Seems to me that if NoSQL becomes more and more important, that the leading such vendor will become the standard because it is just efficient that everyone not need to learn how to use multiple NoSQL databases, but rather one or two. Such is as it has been in software since software became such a thing.
Tinker
Without making any predictions, let me offer a few comments as a software development professional whose start in the biz significantly predated Oracle having its dominant position.
First of all, the focus on SQL or not SQL is really misdirected. The real distinction here is relational vs something else. Something else sounds a big vague, but is actually appropriate since there are multiple concepts for alternatives to relational databases. Mongo’s is document oriented, which is one of the more successful alternatives, but certainly not the only one. SQL is, as the name indicates, a query language, not the technology of the database. Most relational database manufacturers rely on SQL as the way to get data in and out of the database. But, not all. In particular, Progress has a relational database which supports SQL for reporting tools and the like, but which supports a language called ABL that not only provides the data in and out requirements, but which can be used to support the entire application. These days, the client is often non-ABL because of mobile clients and the like, but with Windows computers and such one can even write the client in ABL. So, the important distinction here is relational vs document, not SQL vs non-SQL, despite the tendency for that to be the common nomenclature.
One might also note that despite the expectation of SQL being a standard … and yes, there is a standard and various levels of meeting the standard … that each vendor supports both different levels and often idiosyncratic non-standard features. These features add to capability, but create lock-in and present issues for tool makers.
One should also note that there are tools, e.g., DataDirect, who provide tools for connecting to both relational and non-relational data sources and providing query tools which are SQL based. This includes adapting to the unique interface requirements of a large number of proprietary cloud-based packages like SalesForce.
https://www.progress.com/datadirect-connectors-1?utm_expid=…
A relational database is organized into tables and each table has a rigid structure. The structure can change over time, but at any given instant it is fixed and every record in the table has the same structure. A document oriented database has “tables” where each entry is about the same thing, but which can have a different structure internally. This may sound a bit chaotic, but is less different than it might seem. It is often the case, for example, that a relational database will have tables that support records of different types, e.g., internal vs external orders or other various kinds of order types. In poorly designed relational databases this will mean large numbers of fields per record with only some of those fields being relevant depending on the “type”. In better designed relational databases, the type-specific data will be moved to child file records which will either exist or not depending on the type of the order. A document oriented database will put all the orders in one table and not care that one instance has some properties and another different properties based on “type”.
While Oracle is certainly a dominant force in the relational database market, in part because many of its commercial competitors have effectively ceased to exist, it is also not the case that it is anything like the only relational database vendor. In particular, one has SQL Server, which has a large market in smaller, in-house systems, Progress, who has a large market through ISVs, and options like PostgeSQL and MySQL which are open source and are used very widely, though not making anyone any money. Given that Mongo has an open source version, their ultimate success is based on becoming a primary source for a supported version in a similar fashion to what Red Hat has done for Linux.
I took a garner at this post since it got 5 Recs. The entire premise is wrong from an investment perspective.
NoSQL, SQL, or any variety thereof is irrelevant, utterly. What is relevant is what makes money. What makes money in the database is the dominant vendor. Oracle became the dominant SQL vendor to the point that nearly everyone else went out of business. The other SQL vendors that exist are on the niches and make little money. The query tools and other tools that may allow further features not normally in an SQL or NoSQL, or further integration or whatever, create further complications and expense and points of failure.
SQL became the standard, and Oracle dominated the standard and thus the database world.
NoSQL is only as good as what it does. Any database that is not an SQL is an NoSQL. What matters however, is who dominates the standard in the end. And the standard that matters is who dominates the standard that large enterprises use. The rest is a niche and have at it.
The standard is the only place real money will be made, and if Mongo is correct at their last earnings call, other NoSQL databases have become largely irrelevant to enterprise business. Sure, Netflix may use Cassandra, but then again Apple uses both Cassandra and Mongo. Great for them, they have the finest IT resources and budgets in the world.
What enterprises need is a piece of software that everyone knows, that they can standardize on, and that they can use to bring product to market and efficiencies to the business.
Enterprises have no interest in mixing up Cassandra with Mongo with anyone else. They will still have their SQLs (not going anywhere) but like with Oracle, the whole notion that “there are still many SQL options out there”is utterly irrelevant to an investment perspective. What matters is who is predominant in the enterprise, as that is the vendor that will become the standard and make 90% of the money in the industry.
That also corrects a fallacy often said that it is a myster if Mongo can monetize its database sufficiently. Mongo can care less if everyone decides to use their commercial version. They really and utterly don’t care. What they care about is that enterprises will use it, because enterprises pay, and enterprises need the extra features that the enterprise versions have.
The other, non enterprise versions are simply a sales pipeline, and a way to make Mongo the most wanted database in the world for developers, so that the employers of developers want Mongo as well, and it is a virtuous circle. Let them use it for free. Because enterprises will pay for it.
The value in MongoDB is that, like Oracle before it, it is becoming the standard bearer in the business world for the new standard of database. SQL was once novel and held dominance for 40 years, mostly with Oracle, because software needs a standard. Now NoSQL (of whatever form) needs to standardize as it becomes more important and mission critical for enterprises, and the only candidate that currently exists to carry that standard is Mongo.
Should what is the inevitable (as happens in most OS and database markets) play out, then MongoDB is the winner.
Who cares about the rest who can have their niches. No one ever has 100% of any market. It is having dominance in the market that counts that matters and nothing else does.
Tinker
Tinker’s point is very good, the winner is the winner! I’m not joking. Two circumstances govern “increasing returns” businesses, path dependence and the market picking a winner at random. The technicalities that Tamhas talks about help create the path these technologies and products take but in the end there is only one winner and a bunch of wannabees, a long tail of niche products.
As far as I can see the SQL vs. NoSQL discussion is moot. SQL is a very fine technology for what it does and it will keep on doing it. It might or might not be displaced in time. NoSQL is very fine for what it does. SQL is for structured data. NoSQL is for unstructured or losely structured data. They don’t compete but coexist.
That also corrects a fallacy often said that it is a myster if Mongo can monetize its database sufficiently. Mongo can care less if everyone decides to use their commercial version. They really and utterly don’t care. What they care about is that enterprises will use it, because enterprises pay, and enterprises need the extra features that the enterprise versions have.
I’m one of the people who holds this “fallacy!” My worry as to Mongo’s ability to monetize Freemium is based on MySQL’s failure to do so. MySQL is a great product that I have used for free for at least 15 years never paying a single penny. Apple installs it in Macs for free. If you want the latest version, just download it. When Oracle acquired MySQL which came bundled with SunMicro, my web host switched to MariaDB and I didn’t even notice, a perfect drop in replacement. This is one of the difficulties of doing business with open source software.
But my Mongo worry is not set in stone. I’m looking at earnings reports to tell me when it is safe to invest in MDB. Some people worry they might miss the boat. There is no need to hurry to buy great companies. If Mongo takes over the NoSQL world, it will hold it for well over a decade and that’s a long enough time horizon for my portfolio. Oracle went public in 1986, 32 years ago! If you look at the chart, and make sure you are looking at a semi-log chart*, you’ll see that around five years later was a good time to invest and the year 2000 was a good time to get out. Those ten years, 1991-2000, were the fast rising middle of the “S” curve.** Of course we cannot predict these things in detail but the “S” curve growth pattern is very real.
Let’s suppose this bull ends in a year or two, how about buying MDB after the next bear? It will be safer and there are sufficient other stocks that don’t worry me to fill my portfolio. And there is a good likelyhood that MDB will still have a ten year runway. I’m not disagreeing with Tinker, only expressing how one can use the information at hand.
Denny Schlesinger
** It might well be pure coincidence but the “S” curve strategy holds that the middle third is the time to be invested, Ten out thirty two years? A coincidence? Maybe.
I took a garner at this post since it got 5 Recs. The entire premise is wrong from an investment perspective.
Well, I see somethings in your post we are in violent agreement on… not sure which part is incorrect from an investment perspective, but let me try to pull out points we agree and disagree on (I think):
Agree:
– Enterprises with cash will pay for a standard enterprise tool if it fills a hole.
– Mongo is one dominating the niches for queryable json document stores.
Disagree:
– Mongo is standard barer for noSQL. I disagree here. It would take a longer post, but ultimately, the standard barer for noSQL is…SQL. and SQL isn’t exactly standard when it comes to implementation. There won’t be a standard for nosql… there’s a whole range of products already dealing with this…see Google’s Beam/Apache Beam, Dremel, Drill etc.
– Mongo will be an Oracle replacement.
As I see Mongo in the above context, it won’t dominate like an Oracle, but
it’s worth a ride in the next 2-5 years. It was the first to go to IPO in its space.
Final thoughts:
– There are two particular co.'s that I think will slightly compete but ultimately be side by side and have wider enterprise use than Mongo. RedisLabs (open source product Redis, which is already dominant), and Confluent (Open source Kafka). Both of these have key spaces that align along side of Mongo, but could replace it for a set of use cases.
– I think the single biggest likely competitive technology to subsume Mongo in the enterprise is Postgres. I can write why at some point if anyone is interested.
– Long Mongo, but no blinders.
– I keep a sign on my monitor: “Someday, this will all come crashing down”. It’s my reminder of 2000, 2002, and 2008. It keeps me from getting too optimistic.
– Enterprise features, especially security, are going to be interesting…right now Mongo can say its enterprise ready, but ultimately the security layer (Okta, and Watch for Tigera (or whoever becomes the IPO in front of Istio open source, backed by google).
What makes money in the database is the dominant vendor. Oracle became the dominant SQL vendor to the point that nearly everyone else went out of business.
I think you oversimplify. Oracle got off to a good start, but was hardly massively dominant out of the gates. Even after it had become quite dominant, others persisted for years with niche markets and there are some relational vendors which are still going strong in their particular domain, e.g., Progress in vertical applications and MSFT’s SQLServer in more modest implementations. Indeed, there are lots and lots of MySQL and PostgreSQL implementations; they just aren’t making any database vendor money.
Plus, one needs to remember that far from all of Oracle’s money comes from selling databases. Relational DBs have become a largely non-differentiated product.
Again, this emphasis on SQL instead of relational distorts the picture, particularly when it comes to NoSQL. NoSQL is a bunch of different technologies and the term really means nothing other than not relational. There is certainly room for more than one non-relational technology to prosper if segregated by use case.
So, you are right that what matters for Oracle is not any standards, but the fact that Oracle won the game for a set of use cases. The same will be true for Mongo, we hope.
– Mongo will be an Oracle replacement.
I would agree with your disagreement (although I don’t think Tinker will agree that this is one of his claims) with a qualification. There are quite a few document store implementations which have used some relational database because they were either done before there was any real choice or because the shop that implemented them was familiar with relational technologies and not familiar with other approaches. This is one class of relational implementations, at least, which may actually migrate from relational to document store technology.
Oracle’s current dominance as a company is because of their full breadth of products, not just their database, which has become something of a commodity offering. Where Mongo gets in 25 years is a wee bit hard to forecast at this point.
RedisLabs (open source product Redis, which is already dominant), and Confluent (Open source Kafka).
These are, of course, potentially significant for the market share and use cases they might fit, but irrelevant as investment alternatives. But, I don’t see them as particularly competitive. Redis is in memory … fast, but limited in the amount of data one can store.
Denny, you are not an enterprise customer, and Oracle, that owns MySQL also owns the only SQL database that makes real money. Not expecting Oracle to use MySQL to cannabalize its core product. This said, we do not know how much MySQL makes, and again, users like you are not the ones that MySQL or Mongo are trying to monetize. You obviously do not require the extra enterprise features and the product is designed so that it is not practical for an enterprise to use the product in real commercial applications on any real scale without the enterprise features.
I tried to find out how much money MySQL makes and I still do not know. We know that Oracle bought it for a marketcap that is larger than MongoDB’s marketcap is today enough years ago now that the price would have been materially higher today, perhaps at $8-$10 billion vs. what was it $7.4 billion or something like that (the majority of that was MySQL that SUn had bought a few years earlier for $1 billion - thus it is not like MySQL did not do very well.
Opinion is however that MySQL. Will do better under Oracle:
https://www.zdnet.com/article/mysql-why-the-open-source-data…
Funny that though, even in this article MongoDB gets a specific mention despite the article having nothing whatsoever to do with Mongo and the article is from 2014. Even that far back MongoDB was dominating the mindset of the market:
Despite MySQL’s standing and qualities, it still comes up short against NoSQL databases in certain areas, Zaitsev said, for example with location data.
“A lot of applications have been made these days to be location-aware. They’re mobile, they always want a location in the mix and frankly MySQL for a long time hasn’t been very good at dealing with location data. It’s only in MySQL 5.7, which is in development, that it’s been implemented well and in high performance. MongoDB could provide that much faster,” he said.
I think it is safe to say that MySQL is worth more today than when Oracle bought it, and also that Oracle is looking not to cannabalize its every expensive and market dominant database, and thus is not going to create a true commercial alternative with MySQL. Instead uses MySQL to upsell and to sell into the base other products while making sure MySQL does not always meet the needs of real enterprises so that they need to go Oracle.
But what a coincidence, even when I am not looking for MongoDB, in an article 4 years old, there is MongoDB!
Must be a fluke, as clearly nothing to commercialize here. Earnings call will of course tell, as it tells with all companies.
Tinker
I think it is safe to say that MySQL is worth more today than when Oracle bought it
I wonder about that. Certainly, quantity-wise, the vast bulk of MySQL installations are paying nothing. E.g., it underlies the Drupal software with which our websites are built and it just came for free as a part of obtaining the web hosting. And, if one decides that one’s application is too enterprise to use MySQL or PostgreSQL, how many companies are going to reach for enterprise MySQL instead of Oracle, which they are probably already using for other purposes?
Enterprises have no interest in mixing up Cassandra with Mongo with anyone else. They will still have their SQLs (not going anywhere) but like with Oracle, the whole notion that “there are still many SQL options out there”is utterly irrelevant to an investment perspective. What matters is who is predominant in the enterprise, as that is the vendor that will become the standard and make 90% of the money in the industry.
I agree with most everything Tinker wrote, but this comment when looked at from the perspective of having lived IT in a big enterprise since the days of serial batch sequential file systems is somewhat misleading.
Ted Codd, and IBM mathematician invented the relational database model in 1970. DB2 (IBM’s relational database product) was released in 1983. It was named DB2 because IBM was already successfully selling a hierarchical database product called IMS, Information Management System. DB2 was originally designed to run under OS1/MVS on IBM mainframes.
The company now known as Oracle (first named SDL, Systems Development Laboratory, later renamed RSI, Relational Software Inc, and ultimately renamed Oracle) released its first relational database product, called Oracle v2 (so named as they thought a 1st version would inhibit sales) in 1979. It ran on a PDP-11 from the now defunct Digital Equipment Corp. Oracle released a product that ran in a UNIX distributed server environment as well as IBM mainframes (I think, the history is little hard to uncover) until v5 in 1985. But it wouldn’t be until they introduced row level locking in 1988 that the product became a serious contender in the big enterprise market.
In that the two products ran on entirely different platforms for a number of years, they peacefully coexisted. They both made money.
Meanwhile, Microsoft joined forces with Aston-Tate in efforts to port the relationals database Sybase to run under IBM’s OS/2. SQL-Server was released by Microsoft in 1989. Only a year after Oracle was ported to IBM’s big metal. I have no way of knowing if this product was profitable, but my impression was that it struggled against DB2 and Oracle. This is certainly no longer true. SQL-Server is presently a robust, enterprise level RDBMS. I know of more than one Fortune 500 company that has migrated from Oracle to SQL-Server as the Microsoft product is not only significantly cheaper, but also offered a level of functionality not available in Oracle (although my information is dated, this may no longer be true).
Separately, Teradata, yet another RDBMS which is a strong competitor in the data warehouse and business analytics space. One might call it a semi-RDBMS in that is was optimised for querying against a 3NF database design (this is a design that minimizes redundancy). Nevertheless, Teradata is also a very fast transactional database although I am unaware of it being widely used in OLTP (online teleprocessing) applications. The company is profitable and traded on the NYSE (TDC).
Microsoft released Access, it’s desktop RDBMS that ran under Windows in 1992, making it yet another successful RDBMS. I personally knew the product manager of Access as his daughter and my daughter were friends. Access was and remains a successful (profitable) product, although it is now incorporated to Office. I don’t believe it is available as a stand alone product anymore. Microsoft licensed the R-Base technology from which it developed the Jet database engine which was the underlying datamanager of Access (the product has since been completely re-coded). Access in very short order pretty much decimated all the x86 contenders (e.g., Rbase, Paradox, FoxPro, etc.) much the same as Excel killed off Lotus (actually, IBM) in the spreadsheet market.
The company I worked for had in production DB2, Oracle, SQL-Server, Teradata and tons of desktop and department level Access DBMSs (as well as some legacy IMS). The idea that big shops live with only one DBMS of a type is inaccurate. There are any number of reasons for more than one DBMS to exist in a large enterprise. But they come down to three things, cost, functionality and vendor choice. Dassault Systemes’ Catia has an underlying DB2 database (Catia is a highly sophisticated CAD package). If your shop wants to run Catia, you get DB2. A number of years ago SAP bought Sybase. I don’t know if that is the default RDBMS for SAP or if they provide options. Some COTS application vendors give you a choice of RDBMS others do not.
So what does all this mean for MongoDB? First, NoSQL will not displace traditional RDBMSs. Business transactions (the stuff that used to be on paper forms) are perfectly suited to RDBMS column/row tables. I don’t perceive NoSQL taking over this use case. And, if nothing else, I think it should be pretty clear that the jury is still out on NoSQL DBMS contenders. It should also be pretty clear that there will be more than one viable, profitable vendors in the business. I pretty much stopped analyzing IT products when I retired, so I’ve not made an effort to try and understand exactly what Mongo is good at and what its shortcomings might be. As a document manager (I get the impression this is the long suit for Mongo) it certainly has a large market, but it might be less well suited when it comes to geophysical data or image management or biometrics or any number of other use cases and data types. I don’t know. I’m not saying it is or isn’t. I am saying it will be good for some use cases and not so good for others. But I’m 100% confident it won’t be the only NoSQL DBMS to be profitable (assuming that someday MongoDB will be profitable).
To Tinker’s point, will MongoDB be dominant and rule 90% of the available market. I’ll give that a resounding maybe. At present, it looks that way. I’m long 6.5%. But watch this space closely. I’m not nearly so sanguine as Tinker on this one.
Great point re: MDB as an acquisition target as offered by this TMF author.
…“Big database vendors like Oracle and Microsoft aren’t going to sit idly by while MongoDB takes away their market share. These companies have enormous financial resources to develop competing technology.
MongoDB also still isn’t profitable. The company lost more than $29 million in its latest quarter. Unfortunately, its bottom line isn’t trending in a positive direction yet. MongoDB does have plenty of cash – $271.5 million in cash, cash equivalents, short-term investments, and restricted cash at the end of April. However, it won’t be able to lose money indefinitely before having to raise more cash through taking on debt or conducting a stock offering.”
https://www.fool.com/investing/2018/09/02/if-i-could-buy-onl…
sjo
If you are not sick of it yet, here are my $0.05:
The real difference MongoDB makes is that you can store data flexibly. With a SQL (relational) data base you have to define your data structure beforehand: your customers table will have a name field, address field, unique identifier field and that unique identifier will then come up in the “purchases” structure together with the unique identifier of the item sold, a date/time etc. You have to define which fields are mandatory, what data types there are and what relations are there between the different tables. First you define this whole structure and after that you start filling it with actual data. The problem is that changing the structure of the data after you filled your database is extremely tricky.
In Mongo you don’t need to define much beforehand. You can pretty much start storing your data as it comes. Changing the structure of your data is simple.
So why would you want rigid data structure and why would you want it flexible?
There are cases where flexible structure is essential - where changing the structure of your data is your whole use case. The number one case for this is blending data for data mining. If you look at what the Alteryx designer is doing - each step you take in the graphical interface is changing the structure of the data. MongoDB would be perfect for that case (though Alteryx does not use it because it was developed before Mongo was a viable option). But it’s not just data preparation - collecting data for the purpose of later data mining is better of left flexible in general. The other big use case is prototyping - where you are building a software application prototype just to find out what your options and what the pitfals are. Using a rigid relational database would be a drag to change on the fly all the time.
Using a relational database would be advisable for almost everything else. Like traditional billing/booking systems, really anything implemented in the traditional data layer/logic layer/user layer approach is better off with SQL database. What you typically do is let somebody who really knows what they are doing define and oversee the database and then use lower payed people to do the everyday implementation crunch - they are bound by the rigid data structure so they have less possibilities to mess up.
There is a term in programming, “spaghetti code” - it’s what you get when lower skilled coder whacks at a problem for weeks or months without truly understanding what they are doing until it finally kind of works. The code is so messy that even the person who created it will not understand what it actually does after a couple of months. When you give a flexible database to a person like this, they will create “spaghetti data” - a true nightmare for anybody who comes after that t clean it up. This has already happened with Mongo, I can see it in between the lines in this article where Etsy tried to apply Mongo to a case better served by a traditional database:
http://mcfunley.com/why-mongodb-never-worked-out-at-etsy
So I think Mongo is a niche use case - an important one, but niche nonetheless.
On the other hand there is JavaScript. In one sense JavaScript is the MongoDB of programming languages - it does not enforce data types/structures. It was supposed to be used for a niche use case as well but because using it was so simple it kicked off a lot of projects and never left them. over time it morphed into a widely used tool and even though it’s spaghetti code prone it’s being used in large traditional projects. Maybe Mongo will get to this status as well.
The important question is - will Mongo make money?
I don’t know. It’s risky. Definitely riskier than anything in Saul’s portfolio. Wide usage does not necessarilly mean earnings. JavaScript itself is not making money. I do have a small MDB position but I’m tryig to understand what the management plans to do with the product and how viable that plan is. I’m not quite convinced but I need to study it more. They are losing a lot of money…
Here is what I have seen historically. The beginning complaints about MongoDB was that it was so unstructured that it was like, and I am paraphrasing here but using the same analogy, like how my son cleans his room by throwing everything into the closet (my son as well apparently, but he also misses the closet frequently by some fluke of really bad, bad, aim).
That was 2014, then it was NoSQL is not secure enough, not mature enough, it will not replace SQL, it does not have ACID, etc.
Well, overtime, despite all of this, MongoDb has become more and more adopted by enterprises and has moved up to mission critical roles within enterprises. And with the latest update, it now does multi document ACID, and less spoken about is the analytical abilities that MongoDB has programmed into its database to make it a superior BI database.
What disruptive technologies do is disrupt. They disrupt by finding something that the existing standard technology does not do well enough, and that they can do better. Otherwise the product is considered unwieldy, or too expensive, or too unsecure, etc.
What happens, over time, is that disruptive product gets better and better, more mature, and suddenly what once was a niche, becomes a larger niche, and a larger niche, until it is no longer a niche.
What also happens is that insiders in the industry are skeptical, they do not like change, have seen such claims before, and they end up behind the change that occurs as the product becames better and better, and the decision makers move it to more and more and larger and larger niches, until it is no longer a niche. Happens almost every time.
No, existing ERP is not going to move to MongoDB. But what will move to MongoDB is all many new iterations of problems that otherwise would have gone to SQL, but now NoSQL can handle. And NoSQL is not only more cost effective license wise, not only easier to work with programming wise, it is also far more scaleable. And Big Data, AI, require enormous scaleablility to be economical. SQL does not provide this, and SQL does not provide the capability of fully exploiting Big Data and AI.
Look at Met Life, the 360 degree view of the customer. They tried for years to build a produce on SQL databases to consolidate all their customer data in an easy to use CRM. They failed for years. Then they tried MongoDB, and within a few months they succeeded!
That is what disruptive technologies do. The fact that mainframes continue to exist, does not take away from the fact that they were disrupted long ago. SQL will still exist, and it will dominate for many functions for a very long time. WHO CARES. SQL cannot do what Met Life needed it to do. And since MongoDB, alone in the entire world of NoSQL can also do ACID on multiple documents, more work that may have gone SQL, overtime, will go to MongoDB.
The market is so large, that like with ANET, it only requires one percent, two percent, ten percent of the market. You know that ANET is only about 16% of the market or less at present, it does not take 1005 of the market.
It seems that people analyze MongoDB as if it only needs to be taking 100% of the market from SQL. It will be a $65 billion market in 4 years or so. 10% of that is $6.5 billion. That would exceed expectations for MongoDB. Nevertheless, it appears that whatever marketshare NoSQL databases gain in enterprise, MongoDB will obtain the vast majority of it. 50%, 75%, 90%, I do not know. But the majority of it, and the chunk will be worth billions by then. If Gartner is correct of course.
And this marketshare will only increase as confidence in what Mongo can do grows, and Mongo continues to increase its capabilities, and the need for databases continues to move to unstructured.
Postgres, #4 database is a hybrid solution, but it cannot scale as well as MongoDB. At some point Since MongoDB is also ACID, companies will decide why not use that capacity as well with MongoDB to go along with its unstructured capabilities. 1%, then 5%, then 10% and so on.
That is how disruptive technologies work. Let me know when Cassandra has ACID for multiple documents, or has the analytical capabilities that Mongo creates, or has the ear of C level executives in enterprises that MongoDB states that they have.
Tinker
The problem is that changing the structure of the data after you filled your database is extremely tricky.
Actually, with at least some modern relational databases one can not only add to the schema easily, but even do it on-line. The tricky part is often a result of not using the right principles. E.g., it is very tempting to just add another field in an order-line, for example, in order to implement some new functionality, but there are circumstances where this should be done in a new table instead. Do too much of the former when you should have been doing the later for some years and you will have a real mess.
I like the idea of “spaghetti data”!