This company may be dogshit, but seat count is the standard licensing structure for most employee facing business software, including on-prem.
Most business software licensing/CRM tools requires that information to generate a quote, as price will be dependent upon several factors, including volume licensing tiers i.e. volume discounts.
Sometimes, licensing structures are simple enough that an employee or rep might be able to give you a quick ballpark without that information, but that would be the exception, not the rule.
And all of that is assuming that pricing is only based on seats, when there could be a whole lot of other variables that would be required even for their system just to generate single quote e.g. core count, support terms, etc.
To be clear, none of that means anyone should trust, or switch back to, elasticsearch. It’s just a minor peak into the mundane horrors of business software licensing.
Usually in the observability space it is primarily based on the volume of data and sometimes seat count. Especially if it’s freemium like elastic where users can get an idea of volume by running a POC of the free version. Companies do this because of small teams who deploy large infra that would make contracts unprofitable
Generally the elastic or usage/volumetric type billing structures are used on SaaS/cloud products, not on-prem.
Although it’s entirely possible that elasticsearch, and other vendors in the space use that pricing model for their on-prem customers.
Regardless, that’s even more of a reason why it would be very difficult to give a quote without being first having a presales meeting with a solution architect or knowledgeable rep.
Elasticsearch provides a different feature set than Redis or Postgres. I’ve seen apps that use all 3… but anyway.
It is a little weird to charge per-seat for a search database that is usually integrated into a product, and not used directly by employees. Usually that kind of pricing model is reserved for developer tools like Splunk (notoriously overpriced), or game engines like Unity/Unreal Engine.
This company may be dogshit, but seat count is the standard licensing structure for most employee facing business software, including on-prem.
Most business software licensing/CRM tools requires that information to generate a quote, as price will be dependent upon several factors, including volume licensing tiers i.e. volume discounts.
Sometimes, licensing structures are simple enough that an employee or rep might be able to give you a quick ballpark without that information, but that would be the exception, not the rule.
And all of that is assuming that pricing is only based on seats, when there could be a whole lot of other variables that would be required even for their system just to generate single quote e.g. core count, support terms, etc.
To be clear, none of that means anyone should trust, or switch back to, elasticsearch. It’s just a minor peak into the mundane horrors of business software licensing.
Usually in the observability space it is primarily based on the volume of data and sometimes seat count. Especially if it’s freemium like elastic where users can get an idea of volume by running a POC of the free version. Companies do this because of small teams who deploy large infra that would make contracts unprofitable
Generally the elastic or usage/volumetric type billing structures are used on SaaS/cloud products, not on-prem.
Although it’s entirely possible that elasticsearch, and other vendors in the space use that pricing model for their on-prem customers.
Regardless, that’s even more of a reason why it would be very difficult to give a quote without being first having a presales meeting with a solution architect or knowledgeable rep.
How about instead of elastic customers moved to Redis or Postgres ?
Does the pricing/licensing suddenly change ? Hmm ?
Elasticsearch provides a different feature set than Redis or Postgres. I’ve seen apps that use all 3… but anyway.
It is a little weird to charge per-seat for a search database that is usually integrated into a product, and not used directly by employees. Usually that kind of pricing model is reserved for developer tools like Splunk (notoriously overpriced), or game engines like Unity/Unreal Engine.