Thanks all for the responses and questions. Feel free to hit the smiley face by my name to “Favorite Fool” me, I kinda like this trophy-chalice icon that has appeared next to my name recently.
Here are some answers to the questions up-thread from Dreamer, Jebbo, Lafluer, Duma and apwickman26.
Dreamer:
Why not own both mdb and estc longterm, as they dont quite overlap? What if they are literally the #1 and #2 best stocks you could buy for next few years. Just trying to understand why you are leaning towards either/or vs holding both?
I probably didn’t put it very elegantly - holding both is exactly my plan, ultimately in roughly equal allocations. MDB has been on a huge tear, so clearly wins on relative strength. ESTC is likely still held back by share lock-up so I (and many others posting portfolios here, including Saul, Gaucho, Fleiberman, and Bear) have been slow to build up a position more than a starter 2-3%. After this deep dive, I was impressed enough to start increasing my allocation now, rather than wait for lockup to pass. What I meant in my closing statements was that we should be able to have a good view into their execution & strategies by comparing their trajectories from here, so if one falters we can act appropriately. I really like basket situations like this, like buying both SHOP and SQ and watching them both succeed.
I argued against selling MDB in late Feb, due to AWS and Lyft news (it then popped at earnings), and bought more Okta early April after my review – both of those decisions have turned out VERY nicely. I hope the same for ESTC. I nibbled back in the mid-60s back in Nov, needing to research them more. It has been very range-bound the last 2 months since peaking in late Feb. Once past the lockups and having another Q or two of stellar numbers, and I think we’ll be sitting pretty.
Jebbo:
So what is your best guess of TAM? I am not a computer guy, so I have no idea. But it seems to me the number of people who would need to slice and dice hundreds of terabytes of data is not that large.
More companies than you’d think. Having to churn through terabytes of data is why Hadoop got created. I’d say all the Fortune 2000 and then many IoT or analytics oriented companies have datasets that size. Elasticsearch is built for large datasets, but any data that starts to outgrow the native search capabilities where it is stored can leverage it (say, anything more than 20 million rows or over 20Gb, and it may start exceeding the limits of the database it is in). Since I just had to look it up for work, I’ve got 33Tb in 300B documents in my 6 node Elasticsearch cluster, using it as a time-series database, with metrics going back to 2015.
Guess of TAM? No idea, I just pontificated on the business lines and strategy. I feel that search is relevant to nearly every business w/ an app or website w/ any kind of data (blogs, articles, comments), much less all the trove of specialized datasets out there.
While MDB has a lot of applicability to modern apps, where I like ESTC’s moves are:
- Elastic Stack is relevant to non-developers, for things like monitoring infrastructure or network traffic.
- Elastic’s moves into SaaS services to provide solutions for those non-technically inclined companies that don’t want to run their own database.
Lafleur:
When comparing MBD to Elastic you stated multiple nodes needed for Elastic (min 3) and 0 for MDB? Does that make things more expensive and more complicated for Elastic VS MDB?
Yes. Which is more a reason to use managed hosting. Plus you can size it to your current needs and easily scale as needed from there.
With the amount of data getting larger every year would you not expect Elastic to grow faster in the near future than MDB?
Well that is an interesting thought. I’d say any company using either platform can be expected to have ever growing data. But given that Elastic Stack has tools to auto-ingest logs/metrics via Beats, that I would side with it being a greater velocity for them.
What do you think of the graph at the bottom of the page of the below link comparing MDB and Elastic? Will continual lower ram prices compensate for MDB speed in the long run VS Elastic.
It’s an interesting chart. But their solution is vertically scaling by increasing RAM - there is only so far you can go. It’s pretty easy to see how MDB performs on full-text search if it can keep the dataset in memory (and when it can’t, it hits a wall where it starts getting super slow). They make no mention of setups (cluster size, etc) they are comparing so it’s all pretty ignorable.
Duma:
but I am not convinced that ESTC’s model of trying to innovate their way to competitive advantage without licensing protection is more sustainably competitive than what MDB and other open source have been doing by trying to license their IP AND ALSO innovate.
THEY DO HAVE LICENSING PROTECTION. The choice they are making is in protecting modules within their surrounding eco-system by changing the licensing on the periphery, instead of changing the licensing of the core. The end goal is the same - new features that differentiate them from AWS’s offerings are protected.
In fact, it will greatly surprise me if ESTC doesn’t follow the same playbook as MDB and Redis labs. IMO, we are more likely to see these open source model companies walk in step than to go separate business paths/models (witness the recent dual announcements of GOOG partnership for BOTH MDB and ESTC).
It’s very clear that is not happening, so expect to be surprised (though how one is surprised by an eventual lack of an action, I’m not sure… I guess I’ll just come back in a year and yell SURPRISE at you). Those who decided to take the periphery tack (Elastic and Confluent are the 2 I know of) have been very vocal from the start about their decision & the reasoning behind it, in blog posts from the CEO. They are trying to be very open and deferential to the open-source community about this necessary shift that the enterprise companies behind open-source software is need to take cloud providers if they hope to stay relevant in hosting it.
There is a lot of debate about this in the OSS world. Changing the core is rightfully seen as extremely drastic, as it is much more susceptible to unforeseen complications. Any easy one for forsee, is that many companies are extremely careful about reviewing licensing of their selected tools, and may have picked MongoDB because of its original permissive Apache 2.0 license. If they have doubts, or even legal reservations, about the new license, they are COMPLETELY FROZEN at the last version under Apache 2.0 (v3.6). Way to screw them over! At a minimum, it requires legal review at a lot of companies using MongoDB internally or embedded within their software product or SaaS service.
Redis and MongoDB’s choice of changing core license is getting wayyyy more push-back than the periphery choice of having proprietary modules & tools around the open-source core. Redis had to go back and clarify their license a 2nd time, it was getting so much heat. MDB is got some serious side eye from Red Hat, who removed their software from their repos, and MDB had to eventually pull their new SSPL license from consideration at OSI. See this mailing list post from MDB CTO whining about it (http://lists.opensource.org/pipermail/license-review_lists.o…). In looking at the note it was replying to, it’s clear what the push back is about – the wording about preventing SaaS services “substantially similar to that of the Program”. So it appears that SaaS companies that use MongoDB under the hood as a major component in their service have MAJOR CONCERNS about this new SSPL license. Changing the license on the core open-source database is having the rug pulled out from under you. It requires a legal review at a minimum, but these companies could be extremely upset about what is essentially a broken promise by MDB – expectations were set in stone that MDB decided to change for THEIR BENEFIT ONLY.
Maybe MongoDB feels that this shouldn’t scare SaaS companies, as they are a general-purpose document store, and SaaS companies likely are using it for a purpose that isn’t directly competing against MDB. If Elastic adopted this license on core Elasticsearch, they’d would be directly stifling companies like Swiftype, which built SaaS services over Elasticsearch that are “substantially similar to that of the Program” – which Elastic acquired! I’m guessing they may want more of those types of acquisitions. And, funny thing, SSPL license is full-on attack against services like mLab… which they happened to acquire right before that licensing change.
You mentioned the dual announcement from GOOG, but that has everything to do with GOOG wanting media attention around its choice to partner with these companies, and not end-run around them like AWS; it is NOT about MDB and ESTC being partners or being in lock-step.
These open source companies are threatened in very similar ways from AWS. Etc…they can learn from each other for the benefit of them all.
I agree they can learn from each other. One side is going to learn that the other made better strategic choices. I tried to be more neutral about it in my write up (like “who knows which is better”), but I think the signs are shouting pretty loudly about which choice is better.
MDB and Redis have tried to move closer to that modeling at least slightly using a new licensing model…I expect ESTC still needs to do the same and stick together with MDB, work together and act together.
Redis is really in the weakest position here - their tool is easiest to replicate, and there aren’t major enhancements being made to it from here. MDB had little choice in the matter, as they don’t have the platform of proprietary tools to make the periphery play (until they had Stitch, anyway - that’s a pretty big differentiator). Elastic and Confluent have an ecosystem of tools that were already proprietary, just with more permissive licenses. They are buttoning that up real quick, as those tools are differentiators against the core offering.
apwickman26:
One important note is that Elastic and MDB aren’t necessarily competitors.
I never stated they were. I thought I made clear the difference that Elastic is a search-oriented database, MDB is general-purpose document store for data collections. I am comparing them not as direct competitors, but as very similarly structured businesses with similar history – creating and maintaining an open-source NoSQL database and now having success at providing managed cloud hosting of that database. MDB and ESTC are both in the hypergrowth Saul universe, so I think it is important to view them in tandem - either to compare their execution and strategies to evaluate them, or to invest in both as a “sticky dev tooling w/ cloud hosting” basket.
MDB is more of a database disruptor along the lines of the traditional SQL databases (SQL Server, Oracle, MySQL, PostgreSQL). In my opinion, its biggest threats in the NoSQL space are via Microsoft Azure’s CosmosDB and Amazon’s AWS DynamoDB.
Yes. I didn’t rehash that as I already covered all that earlier in my “Cutting Through the FUD on MDB” post. https://boards.fool.com/cutting-through-the-fud-on-mdb-34145…
For companies with big search needs, loading the data to something like Elasticsearch or something similar (Solr, Azuresearch, AWS Cloudsearch) is ideal.
Thanks for bringing that up - I should have mentioned Azure Search and AWS Cloudsearch. They’ve been around a long while as cloud-based competitors to Elasticsearch, but don’t compare at all to Elastic Stack’s popularity. We don’t have numbers from cloud providers on usage, but those two vendor-specific databases are way down the list on DB Engine rankings (at 54 for Azure and a way pitiful 94 for AWS).
So to copy a bit from my MDB post linked above:
REGARDLESS of these competing products, Elasticsearch is the clear king of search databases.
REGARDLESS of these competing products that are more “native” to their respective clouds, Elastic has thrived, in part by building an entire eco-system of tools (Kibana, Beats) & modules (APM, ML) that those products are missing.
REGARDLESS of many cloud providers providing managed Elasticsearch themselves, Elastic has thrived as a cloud-neutral provider of managed hosting.
Elastic might have designs on being both search and main data store but they need to resolve a lot of issues first (security, reliability).
Elasticsearch is NOT angling to be your main data store. It’s not striving to be the “single source of truth”, as we call it in the biz (aka being the sole database for all of a company’s data). The common pattern using it is that you are pulling pieces from various “sources of truth” into Elasticsearch (say, your HR records but not payroll tx), with it acting as a storage engine over it.
I have to dismiss the issues you list. Elastic HAS solved security, it’s been a proprietary module in X-Pack for years, where you can control security down to the field level. It’s the first thing AWS had to address with Open Distro (they added a security module). As for reliability, stability has been a major focus since v1.5 (now on v7.0), and Elastic has been very diligent over the past several years about shoring up bugs and weak spots of their platform – writing distributed software over a cluster is extremely difficult. And with shard replication, it has been geared for high-availability from the start.
- muji
long ESTC