Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elastic files for an IPO

sec.gov

Post reply on HN
Print view View original

131–140 of 143 posts

Re: Elastic files for an IPO

#131

Post by angelirizarry »

achompas wrote: post #36
hendzen wrote: post #13

Earlier quoted context omitted.

There are key differences between MongoDB and Elastic. MongoDB (the company), has been very strategic about defending themselves from Amazon. Likely due to the AGPL licensing on MongoDB (the database), Amazon doesn't offer a hosted MongoDB - you have to buy MongoDB Atlas which runs on multiple cloud providers, including AWS, GCP and Azure. Coincidentally, Atlas subscriptions are the fastest growing part of MongoDB In…

Another thing to note, along with sibling comments: AWS Elasticsearch is limited in its capabilities. For example, you are blocked from relying on custom ranking models to rank your documents.

Can you say more about these limitations? Right now I'm using a pretty big custom ranking function to rank my documents in Elasticsearch (using a function_score query), but maybe I'm misunderstanding.

Re: Elastic files for an IPO

#132

Post by nikonyrh »

barbecue_sauce wrote: post #102
AznHisoka wrote: post #78

Earlier quoted context omitted.

Elasticsearch is much more than a search engine. Lots of people use it for analytics (checkout their aggregation/time series queries) as well as analyzing huge logs. Some people are starting to use it for machine learning use cases too.

I have seen it used almost exclusively for logging as part of the Elastic (formerly ELK) stack.

Even the "plain" ELK uses aggregations to produce those graphs.

Re: Elastic files for an IPO

#133

Post by achompas »

angelirizarry wrote: post #131
achompas wrote: post #36

Earlier quoted context omitted.

Another thing to note, along with sibling comments: AWS Elasticsearch is limited in its capabilities. For example, you are blocked from relying on custom ranking models to rank your documents.

Can you say more about these limitations? Right now I'm using a pretty big custom ranking function to rank my documents in Elasticsearch (using a function_score query), but maybe I'm misunderstanding.

Sorry, I was a bit vague. Queries are fine, but you cannot, say, use a scikit-learn model trained on user activity.

Re: Elastic files for an IPO

#134

Post by ousta »

AtlasBarfed wrote: post #130
ousta wrote: post #127

Earlier quoted context omitted.

yeah a "subset of SQL" and on the page you gave me 0 example of a JOIN. so no JOIN no SQL sorry

"We support SQL on our distributed data platform" has to be the new big lie of distributed systems salespeople. I'm not saying that computing joins, aggegates, sorts, etc can't be done in a distributed fashion, it just takes time, a lot of network reliability/reattempts, and understanding of the approximate nature of results if there are ongoing "eventually consistent" updates rolling through the cluster(s).

well you cannot have a search engine query time + a SQL layer at least not at DB speeds

Re: Elastic files for an IPO

#135

Post by ryneandal »

barbecue_sauce wrote: post #102
AznHisoka wrote: post #78

Earlier quoted context omitted.

Elasticsearch is much more than a search engine. Lots of people use it for analytics (checkout their aggregation/time series queries) as well as analyzing huge logs. Some people are starting to use it for machine learning use cases too.

I have seen it used almost exclusively for logging as part of the Elastic (formerly ELK) stack.

At my previous job we used it for a fair amount of analytics for our SaaS clients.

Re: Elastic files for an IPO

#136

Post by toomuchtodo »

busterarm wrote: post #115
toomuchtodo wrote: post #100

Earlier quoted context omitted.

It’s a business decision of course. Forge your own path or be beholden to your revenue model dictated by AWS. Big Enterprise will not require billing through AWS (disclaimer: employed at a large enterprise, buying ~$900k software license currently). They’ll have an accounts payable department, a procurement process, and someone to cut a check or ACH to Elastic monthly/annually.

It wasn't the way they did billing, it was just an option. One they've removed. I get it, I'm just saying it cost them some money.

I totally get that. I don't dispute that. But if you must choose between "please sir, can I have some more?" and controlling your own revenue destiny, it is clear why some would choose the later.

Would you want to be beholden to AWS' whims? You might as well be a Walmart supplier at that point, constantly dragged out to Bentonville having to make your case for every penny of your costs. Amazon has proven its model (all about scale), how it operates (your margin = our opportunity), and you partner with them at your own peril.

I'm suggesting the thought process to shift from, "Ahhh, those Elastic guys and their bad decisions!" to "Hmm, well, tough decision to make [forgoing revenue through AWS] but I understand why they made it".

Re: Elastic files for an IPO

#137

Post by bogomipz »

mathattack wrote: post #122
bogomipz wrote: post #64

Earlier quoted context omitted.

>"The formula for SaaS companies is generally growth + net margin should equal 40%." Can you say exactly what formula this is and what is a formula for? Also what is the significance of the number 40 as a target?

Beambot has the source. The general idea is its ok to lose Money if your net (growth minus losses) is higher than your cost of capital. (VC money expects a 30-50% rate of return) In general SaaS companies have high fixed costs so it’s a race to get big enough to cover them. The rule of 40 flags companies that are too unprofitable or not growing fast enough. Like all financial metrics (PE ratio, etc) it’s still just a…

Thanks this link and explanation were really helpful.

Re: Elastic files for an IPO

#138

Post by dpim »

sonnyblarney wrote: post #117
calcsam wrote: post #37

This is an extremely solid financial statement. $150M in revenue, growing ~100% per year; I'd project a valuation between $3B and $4B. Twilio, Mulesoft, and MongoDB are probably the best comparables here -- open-source and dev-tools based SaaS IPOs. All of these were very successful at IPO and afterwards, and even compared to these, Elastic looks great. * They're growing at almost 100% per year which is incredible. T…

Hemorhaging money is not justified by the fact that 'others did it'. WeWork and Uber can justify it by pointing out unit costs in stable markets, and say 'look we are profitable there, so all of our losses are due to growth'. Elastic cannot say the same. In fact Twilio and Mongo have also been hemorhaging money since the start, and it's going to take a hell of a lot of growth, then massive profitability for them to b…

Twilio hit profitability last quarter FWIW

Re: Elastic files for an IPO

#140

Post by PaulRobinson »

burnmaster wrote: post #66
calcsam wrote: post #37

This is an extremely solid financial statement. $150M in revenue, growing ~100% per year; I'd project a valuation between $3B and $4B. Twilio, Mulesoft, and MongoDB are probably the best comparables here -- open-source and dev-tools based SaaS IPOs. All of these were very successful at IPO and afterwards, and even compared to these, Elastic looks great. * They're growing at almost 100% per year which is incredible. T…

I see several responses that mention MongoDB for purposes of comparison and seem to conclude Elasticsearch fares favorably. It should be noted: [1] Unlike MongoDB (which is a ground-up build), Elasticsearch is basically an API layer on top of Apache Lucene. This is relevant because they haven't built and don't maintain, control, or own the source of their primary IP. [2] Unlike MongoDB (General Purpose) Elasticsearch…

As a long time Elastic user:

[1] You don't understand their IP if you think it's Lucene. It really, really isn't.

[2] It's not single purpose anything. I've used it for search engines, event buses and as document stores. It's multi-purpose and more dependable at scale and under duress than Mongo thanks to sitting on top of the JVM.

[3] Stackoverflow stats don't mean anything. What are you trying to imply?

Post reply on HN