Calling a hosted database "serverless" is the most brazen branding I have seen in a long time. For extra hilarity, their pricing page says "pricing is inclusive of cloud hardware".
Good feedback. We thought about the different ways to frame the value prop and "serverless" is what resonated the most with us because:
1/ you can load data, process queries and build apps/dashboards without ever thinking about servers -- so, no provisioning or capacity planning required.
2/ you only pay for amount of data actually loaded and indexed -- so, no idle servers costing you $$$s.
If you have better suggestions that feels more accurate, please share and we will definitely consider it.
Touche on the "cloud hardware" bit. We will fix that soon.
Now that you explain your reasoning a bit, and upon re-reading https://en.wikipedia.org/wiki/Serverless_computing, I think using "serverless" in this context makes sense. I see "serverless" used so much more often to describe compute runtimes like AWS Lambda than databases that, I confess, I thought you might be trying to ride that wave's popularity; and/or that you might be using "serverless" _just_ because the servers were managed by you not the users, whereas you allocate capacity on a more granular level than the server.
I do still recommend you take out the "cloud hardware" bit ;D
Thanks for the explanation, and best of luck! Cool model.
Based on my initial read of your website it looks like you are in the same space as ElasticSearch and LucidWorks, although you don't seem to have non-SQL text search capabilities. It would be interesting to see a performance comparison between the three using SQL. I could see some customers wanting an SQL focused solution if there are performance gains to be had.
imveeve|6 years ago
Good feedback. We thought about the different ways to frame the value prop and "serverless" is what resonated the most with us because: 1/ you can load data, process queries and build apps/dashboards without ever thinking about servers -- so, no provisioning or capacity planning required. 2/ you only pay for amount of data actually loaded and indexed -- so, no idle servers costing you $$$s.
If you have better suggestions that feels more accurate, please share and we will definitely consider it.
Touche on the "cloud hardware" bit. We will fix that soon.
wearhere|6 years ago
Now that you explain your reasoning a bit, and upon re-reading https://en.wikipedia.org/wiki/Serverless_computing, I think using "serverless" in this context makes sense. I see "serverless" used so much more often to describe compute runtimes like AWS Lambda than databases that, I confess, I thought you might be trying to ride that wave's popularity; and/or that you might be using "serverless" _just_ because the servers were managed by you not the users, whereas you allocate capacity on a more granular level than the server.
I do still recommend you take out the "cloud hardware" bit ;D
Thanks for the explanation, and best of luck! Cool model.
itronitron|6 years ago