Hi guys, We are finishing up a big performance cycle, and hopefully we will have a new stable next week with all of those goodies for you. If all goes well, this will be the last (or one before last) stable release in the current version of RavenDB.
As you probably know, we have been thinking about our licensing strategy, and I thought that I'll share with you some of our early thoughts ,to get your feedback. Probably in March or April, we want to release a new version of RavenDB. Probably called 1.2.
*Important note*: We are trying to run as much as possible in the open, and solicit your feedback whenever we can. Both on coding and business issues. Your feedback is important, and I am not saying this just because it sounds good. That said, the last time we had a pricing discussion things got somewhat ugly. I ask you all to have a polite conversation about this. Thanks in advance, Oren.
Implications for anyone who bought a subscription: None, except that they might want to update to the new version.
Implications for people who made a one time payment: If they bought in the last 6 months, they get 1.2 automatically. If they bought earlier than that, they need to pay an upgrade fee (249$) per instance. There are some cases where people expected to be able to get the new versions indefinately. If you are one of those, and you bought a one time payment more than six months ago, contact us, we will make an arrangement that will make both of us happy.
Along with the new version, we intend to change our pricing structure. This has several reasons behind that. If you remember the pricing discussion in May 2010, one of the repeated issues that was brought up was that RavenDB is a NoSQL database, and as such its pricing needs to be match the scaling needs. Another issue, from our side, is that introducing a new product is always a touch period of time, especially one that require the level of trust expected from a database. The pricing reflected both those issues.
Now, with over a year and a half in production using multiple customers, we have much better data both about common usage patterns and about RavenDB itself. The level of trust expected from a database is much higher than when we introduced RavenDB and I can tell you that so far, no one is running a 25 nodes cluster of RavenDB (maybe I shouldn't have worked so hard on perf, people would need more servers :-) ).
All of this leads me to the following changes:
we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB Scaleout.
*RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. However, it also would be limited in the following ways:
Max of 12 GB RAM Max of 6 Cores Max of 25 databases
*Note: *If you are have an existing license, either subscription or one time payment that got grandfathered in, you don't have to worry about those limitations.
Pricing would still be based on per instance model, which is effectively per server.
Cost per instance would be: 999$ - which include 18 months of support (4 incidents) and auto upgrades. After the time is up, you _can continue to use your RavenDB instance with no issues_. But, you *won't *be eligible for any additional updates or support.
Exception for that is security / critical bugs that would still get fixed in a period of 36 months from the date you purchase the software.
Subscriptions would be: 399$ per year 39$ per month
In either case, you get 2 support incidents per year. And auto upgrades for as long as you have a current subscription. If the subscription lapses, you can continue to use RavenDB, but you are not eligible for support or updates.
We will still offer the OEM model for embedded instances, which would be 1,599$ per developer per year.
Now we get to the *RavenDB Enterprise*. First, let us talk about the goodies.
* No limits on RAM / cores / databases * Indexing scheduler ** Index priorities ** Offline index builds (new index won't stop existing indexes updates) * Windows Clustering support * Builtin compression * Builtin encryption * Management interface for the server (not just on a single database) * Integration for managing all of the builtin bundle * Replication monitoring * HTTP Support when running in service mode * S3 backup support
And probably a bunch of other stuff as well, but we want to have a _few_ surprises.
RavenDB Enterprise will be licensed per core. Number of cores is defined as whatever Environment.ProcessCount returns, for simplicity sake. I don't have final pricing for that yet, so I would like to get your opinions on the matter. I am looking at having a similar range betwen RavenDB Enterprise and SQL Enterprise as between RavenDB Standard and SQL Standard, but I haven't made up my mind.
Finaly, we have *RavneDB Scaleout*. This is meant to answer the need of people who need large number of RavenDB servers (the 20 nodes RavenDB cluster). Pricing for that is based on a 25 instances bundle, at a cost of 750$ per instance. So a 25 bundle would cost 18,500$. If you need more than 25 - 50 nodes, you probably need to call us and we can talk about prices anyway.
aye...@ayende.com> wrote: > Hi guys, > We are finishing up a big performance cycle, and hopefully we will have a > new stable next week with all of those goodies for you. > If all goes well, this will be the last (or one before last) stable > release in the current version of RavenDB.
> As you probably know, we have been thinking about our licensing strategy, > and I thought that I'll share with you some of our early thoughts ,to get > your feedback. > Probably in March or April, we want to release a new version of RavenDB. > Probably called 1.2.
> *Important note*: > We are trying to run as much as possible in the open, and solicit your > feedback whenever we can. Both on coding and business issues. > Your feedback is important, and I am not saying this just because it > sounds good. > That said, the last time we had a pricing discussion things got > somewhat ugly. I ask you all to have a polite conversation about this. > Thanks in advance, Oren.
> Implications for anyone who bought a subscription: None, except that they > might want to update to the new version.
> Implications for people who made a one time payment: > If they bought in the last 6 months, they get 1.2 automatically. If they > bought earlier than that, they need to pay an upgrade fee (249$) per > instance. > There are some cases where people expected to be able to get the new > versions indefinately. If you are one of those, and you bought a one time > payment more than > six months ago, contact us, we will make an arrangement that will make > both of us happy.
> Along with the new version, we intend to change our pricing structure. > This has several reasons behind that. If you remember the pricing > discussion in May 2010, one > of the repeated issues that was brought up was that RavenDB is a NoSQL > database, and as such its pricing needs to be match the scaling needs. > Another issue, from our side, is that introducing a new product is always > a touch period of time, especially one that require the level of trust > expected from a database. > The pricing reflected both those issues.
> Now, with over a year and a half in production using multiple customers, > we have much better data both about common usage patterns and about RavenDB > itself. The level of > trust expected from a database is much higher than when we introduced > RavenDB and I can tell you that so far, no one is running a 25 nodes > cluster of RavenDB (maybe I > shouldn't have worked so hard on perf, people would need more servers :-) > ).
> All of this leads me to the following changes:
> we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB > Scaleout.
> *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. > However, it also would be limited in the following ways:
> Max of 12 GB RAM > Max of 6 Cores > Max of 25 databases
> *Note: *If you are have an existing license, either subscription or one > time payment that got grandfathered in, you don't have to worry about those > limitations.
> Pricing would still be based on per instance model, which is effectively > per server.
> Cost per instance would be: 999$ - which include 18 months of support (4 > incidents) and auto upgrades. > After the time is up, you _can continue to use your RavenDB instance > with no issues_. > But, you *won't *be eligible for any additional updates or support.
> Exception for that is security / critical bugs that would still get > fixed in a period of 36 months from the date you purchase the software.
> Subscriptions would be: > 399$ per year > 39$ per month
> In either case, you get 2 support incidents per year. And auto upgrades > for as long as you have a current subscription. > If the subscription lapses, you can continue to use RavenDB, but you are > not eligible for support or updates.
> We will still offer the OEM model for embedded instances, which would be > 1,599$ per developer per year.
> Now we get to the *RavenDB Enterprise*. First, let us talk about the > goodies.
> * No limits on RAM / cores / databases > * Indexing scheduler > ** Index priorities > ** Offline index builds (new index won't stop existing indexes updates) > * Windows Clustering support > * Builtin compression > * Builtin encryption > * Management interface for the server (not just on a single database) > * Integration for managing all of the builtin bundle > * Replication monitoring > * HTTP Support when running in service mode > * S3 backup support
> And probably a bunch of other stuff as well, but we want to have a _few_ > surprises.
> RavenDB Enterprise will be licensed per core. Number of cores is defined > as whatever Environment.ProcessCount returns, for simplicity sake. > I don't have final pricing for that yet, so I would like to get your > opinions on the matter. > I am looking at having a similar range betwen RavenDB Enterprise and SQL > Enterprise as between RavenDB Standard and SQL Standard, but I haven't made > up my mind.
> Finaly, we have *RavneDB Scaleout*. > This is meant to answer the need of people who need large number of > RavenDB servers (the 20 nodes RavenDB cluster). > Pricing for that is based on a 25 instances bundle, at a cost of 750$ per > instance. So a 25 bundle would cost 18,500$. > If you need more than 25 - 50 nodes, you probably need to call us and we > can talk about prices anyway.
I think overall this is acceptable but a few things to consider might
be:
Introduce a cheap tier for the cheapskates who moan about the cost of
RavenDB versus SQL Server Express. I would do low limits like max 1GB
ram, 5 databases etc.
The standard tier's RAM limit is disappointing with RAM being so
cheap. My next development machine will have 32GB and only cost me
£200 for that 32GB. I would like to see it set a little bit higher,
the max I'm aware a consumer machine could have is 64GB but 32GB would
make me happy :)
Standard going up to $39pm is fine with the current exchange. Although
I bought a license last night (at $25) that converted to £16.85 but
came to £20.22 as I forgot the VAT. Perhaps add a little message along
the lines of "exclude sales tax for your country/region/state".
On Skype or email me if you want to talk about scenarios around
"RavenDB Express", I did a grok (10 minute) talk on Wednesday on
RavenDB and had several questions as I always do about pricing and
comments regarding SQL Express being free :(
On Feb 24, 9:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Hi guys,
> We are finishing up a big performance cycle, and hopefully we will have a
> new stable next week with all of those goodies for you.
> If all goes well, this will be the last (or one before last) stable release
> in the current version of RavenDB.
> As you probably know, we have been thinking about our licensing strategy,
> and I thought that I'll share with you some of our early thoughts ,to get
> your feedback.
> Probably in March or April, we want to release a new version of RavenDB.
> Probably called 1.2.
> *Important note*:
> We are trying to run as much as possible in the open, and solicit your
> feedback whenever we can. Both on coding and business issues.
> Your feedback is important, and I am not saying this just because it
> sounds good.
> That said, the last time we had a pricing discussion things got somewhat
> ugly. I ask you all to have a polite conversation about this.
> Thanks in advance, Oren.
> Implications for anyone who bought a subscription: None, except that they
> might want to update to the new version.
> Implications for people who made a one time payment:
> If they bought in the last 6 months, they get 1.2 automatically. If they
> bought earlier than that, they need to pay an upgrade fee (249$) per
> instance.
> There are some cases where people expected to be able to get the new
> versions indefinately. If you are one of those, and you bought a one time
> payment more than
> six months ago, contact us, we will make an arrangement that will make both
> of us happy.
> Along with the new version, we intend to change our pricing structure. This
> has several reasons behind that. If you remember the pricing discussion in
> May 2010, one
> of the repeated issues that was brought up was that RavenDB is a NoSQL
> database, and as such its pricing needs to be match the scaling needs.
> Another issue, from our side, is that introducing a new product is always a
> touch period of time, especially one that require the level of trust
> expected from a database.
> The pricing reflected both those issues.
> Now, with over a year and a half in production using multiple customers, we
> have much better data both about common usage patterns and about RavenDB
> itself. The level of
> trust expected from a database is much higher than when we introduced
> RavenDB and I can tell you that so far, no one is running a 25 nodes
> cluster of RavenDB (maybe I
> shouldn't have worked so hard on perf, people would need more servers :-) ).
> All of this leads me to the following changes:
> we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB
> Scaleout.
> *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love.
> However, it also would be limited in the following ways:
> Max of 12 GB RAM
> Max of 6 Cores
> Max of 25 databases
> *Note: *If you are have an existing license, either subscription or one
> time payment that got grandfathered in, you don't have to worry about those
> limitations.
> Pricing would still be based on per instance model, which is effectively
> per server.
> Cost per instance would be: 999$ - which include 18 months of support (4
> incidents) and auto upgrades.
> After the time is up, you _can continue to use your RavenDB instance
> with no issues_.
> But, you *won't *be eligible for any additional updates or support.
> Exception for that is security / critical bugs that would still get fixed
> in a period of 36 months from the date you purchase the software.
> Subscriptions would be:
> 399$ per year
> 39$ per month
> In either case, you get 2 support incidents per year. And auto upgrades
> for as long as you have a current subscription.
> If the subscription lapses, you can continue to use RavenDB, but you are
> not eligible for support or updates.
> We will still offer the OEM model for embedded instances, which would be
> 1,599$ per developer per year.
> Now we get to the *RavenDB Enterprise*. First, let us talk about the
> goodies.
> * No limits on RAM / cores / databases
> * Indexing scheduler
> ** Index priorities
> ** Offline index builds (new index won't stop existing indexes updates)
> * Windows Clustering support
> * Builtin compression
> * Builtin encryption
> * Management interface for the server (not just on a single database)
> * Integration for managing all of the builtin bundle
> * Replication monitoring
> * HTTP Support when running in service mode
> * S3 backup support
> And probably a bunch of other stuff as well, but we want to have a _few_
> surprises.
> RavenDB Enterprise will be licensed per core. Number of cores is defined as
> whatever Environment.ProcessCount returns, for simplicity sake.
> I don't have final pricing for that yet, so I would like to get your
> opinions on the matter.
> I am looking at having a similar range betwen RavenDB Enterprise and SQL
> Enterprise as between RavenDB Standard and SQL Standard, but I haven't made
> up my mind.
> Finaly, we have *RavneDB Scaleout*.
> This is meant to answer the need of people who need large number of RavenDB
> servers (the 20 nodes RavenDB cluster).
> Pricing for that is based on a 25 instances bundle, at a cost of 750$ per
> instance. So a 25 bundle would cost 18,500$.
> If you need more than 25 - 50 nodes, you probably need to call us and we
> can talk about prices anyway.
First, congratulations on getting the product to the point you can
have this discussion. It is quite exciting.
On the standard edition -- how is the limit enforced? It is pretty
tricky to get a server with six cores and less than 12gb of RAM these
days if you are still running on iron. I'm not a huge fan of the 25 DB
limit, I'd argue that a database size limit is a better option if
possible. The main reason is it matches what most other database
servers use as the limit to the lower-priced version.
What do the development options look like? I think it would be awesome
if there was a raven db enterprise developer edition, much like sql
developer.
On Feb 24, 4:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Hi guys,
> We are finishing up a big performance cycle, and hopefully we will have a
> new stable next week with all of those goodies for you.
> If all goes well, this will be the last (or one before last) stable release
> in the current version of RavenDB.
> As you probably know, we have been thinking about our licensing strategy,
> and I thought that I'll share with you some of our early thoughts ,to get
> your feedback.
> Probably in March or April, we want to release a new version of RavenDB.
> Probably called 1.2.
> *Important note*:
> We are trying to run as much as possible in the open, and solicit your
> feedback whenever we can. Both on coding and business issues.
> Your feedback is important, and I am not saying this just because it
> sounds good.
> That said, the last time we had a pricing discussion things got somewhat
> ugly. I ask you all to have a polite conversation about this.
> Thanks in advance, Oren.
> Implications for anyone who bought a subscription: None, except that they
> might want to update to the new version.
> Implications for people who made a one time payment:
> If they bought in the last 6 months, they get 1.2 automatically. If they
> bought earlier than that, they need to pay an upgrade fee (249$) per
> instance.
> There are some cases where people expected to be able to get the new
> versions indefinately. If you are one of those, and you bought a one time
> payment more than
> six months ago, contact us, we will make an arrangement that will make both
> of us happy.
> Along with the new version, we intend to change our pricing structure. This
> has several reasons behind that. If you remember the pricing discussion in
> May 2010, one
> of the repeated issues that was brought up was that RavenDB is a NoSQL
> database, and as such its pricing needs to be match the scaling needs.
> Another issue, from our side, is that introducing a new product is always a
> touch period of time, especially one that require the level of trust
> expected from a database.
> The pricing reflected both those issues.
> Now, with over a year and a half in production using multiple customers, we
> have much better data both about common usage patterns and about RavenDB
> itself. The level of
> trust expected from a database is much higher than when we introduced
> RavenDB and I can tell you that so far, no one is running a 25 nodes
> cluster of RavenDB (maybe I
> shouldn't have worked so hard on perf, people would need more servers :-) ).
> All of this leads me to the following changes:
> we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB
> Scaleout.
> *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love.
> However, it also would be limited in the following ways:
> Max of 12 GB RAM
> Max of 6 Cores
> Max of 25 databases
> *Note: *If you are have an existing license, either subscription or one
> time payment that got grandfathered in, you don't have to worry about those
> limitations.
> Pricing would still be based on per instance model, which is effectively
> per server.
> Cost per instance would be: 999$ - which include 18 months of support (4
> incidents) and auto upgrades.
> After the time is up, you _can continue to use your RavenDB instance
> with no issues_.
> But, you *won't *be eligible for any additional updates or support.
> Exception for that is security / critical bugs that would still get fixed
> in a period of 36 months from the date you purchase the software.
> Subscriptions would be:
> 399$ per year
> 39$ per month
> In either case, you get 2 support incidents per year. And auto upgrades
> for as long as you have a current subscription.
> If the subscription lapses, you can continue to use RavenDB, but you are
> not eligible for support or updates.
> We will still offer the OEM model for embedded instances, which would be
> 1,599$ per developer per year.
> Now we get to the *RavenDB Enterprise*. First, let us talk about the
> goodies.
> * No limits on RAM / cores / databases
> * Indexing scheduler
> ** Index priorities
> ** Offline index builds (new index won't stop existing indexes updates)
> * Windows Clustering support
> * Builtin compression
> * Builtin encryption
> * Management interface for the server (not just on a single database)
> * Integration for managing all of the builtin bundle
> * Replication monitoring
> * HTTP Support when running in service mode
> * S3 backup support
> And probably a bunch of other stuff as well, but we want to have a _few_
> surprises.
> RavenDB Enterprise will be licensed per core. Number of cores is defined as
> whatever Environment.ProcessCount returns, for simplicity sake.
> I don't have final pricing for that yet, so I would like to get your
> opinions on the matter.
> I am looking at having a similar range betwen RavenDB Enterprise and SQL
> Enterprise as between RavenDB Standard and SQL Standard, but I haven't made
> up my mind.
> Finaly, we have *RavneDB Scaleout*.
> This is meant to answer the need of people who need large number of RavenDB
> servers (the 20 nodes RavenDB cluster).
> Pricing for that is based on a 25 instances bundle, at a cost of 750$ per
> instance. So a 25 bundle would cost 18,500$.
> If you need more than 25 - 50 nodes, you probably need to call us and we
> can talk about prices anyway.
> On Fri, Feb 24, 2012 at 3:02 AM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
> Hi guys, > We are finishing up a big performance cycle, and hopefully we will have a > new stable next week with all of those goodies for you. > If all goes well, this will be the last (or one before last) stable > release in the current version of RavenDB.
> As you probably know, we have been thinking about our licensing strategy, > and I thought that I'll share with you some of our early thoughts ,to get > your feedback. > Probably in March or April, we want to release a new version of RavenDB. > Probably called 1.2.
> *Important note*: > We are trying to run as much as possible in the open, and solicit your > feedback whenever we can. Both on coding and business issues. > Your feedback is important, and I am not saying this just because it > sounds good. > That said, the last time we had a pricing discussion things got > somewhat ugly. I ask you all to have a polite conversation about this. > Thanks in advance, Oren.
> Implications for anyone who bought a subscription: None, except that they > might want to update to the new version.
> Implications for people who made a one time payment: > If they bought in the last 6 months, they get 1.2 automatically. If they > bought earlier than that, they need to pay an upgrade fee (249$) per > instance. > There are some cases where people expected to be able to get the new > versions indefinately. If you are one of those, and you bought a one time > payment more than > six months ago, contact us, we will make an arrangement that will make > both of us happy.
> Along with the new version, we intend to change our pricing structure. > This has several reasons behind that. If you remember the pricing > discussion in May 2010, one > of the repeated issues that was brought up was that RavenDB is a NoSQL > database, and as such its pricing needs to be match the scaling needs. > Another issue, from our side, is that introducing a new product is always > a touch period of time, especially one that require the level of trust > expected from a database. > The pricing reflected both those issues.
> Now, with over a year and a half in production using multiple customers, > we have much better data both about common usage patterns and about RavenDB > itself. The level of > trust expected from a database is much higher than when we introduced > RavenDB and I can tell you that so far, no one is running a 25 nodes > cluster of RavenDB (maybe I > shouldn't have worked so hard on perf, people would need more servers :-) > ).
> All of this leads me to the following changes:
> we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB > Scaleout.
> *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. > However, it also would be limited in the following ways:
> Max of 12 GB RAM > Max of 6 Cores > Max of 25 databases
> *Note: *If you are have an existing license, either subscription or one > time payment that got grandfathered in, you don't have to worry about those > limitations.
> Pricing would still be based on per instance model, which is effectively > per server.
> Cost per instance would be: 999$ - which include 18 months of support (4 > incidents) and auto upgrades. > After the time is up, you _can continue to use your RavenDB instance > with no issues_. > But, you *won't *be eligible for any additional updates or support.
> Exception for that is security / critical bugs that would still get > fixed in a period of 36 months from the date you purchase the software.
> Subscriptions would be: > 399$ per year > 39$ per month
> In either case, you get 2 support incidents per year. And auto upgrades > for as long as you have a current subscription. > If the subscription lapses, you can continue to use RavenDB, but you are > not eligible for support or updates.
> We will still offer the OEM model for embedded instances, which would be > 1,599$ per developer per year.
> Now we get to the *RavenDB Enterprise*. First, let us talk about the > goodies.
> * No limits on RAM / cores / databases > * Indexing scheduler > ** Inde
Technically, yes I am aware of this "flaw", and I'm not sure how/if to address it I don't want to get to a point where you might have a dead app because of a subscription notification being mislaid
On Friday, February 24, 2012, Shaddix wrote: > > Subscriptions would be: > > 39$ per month > > If the subscription lapses, you can continue to use RavenDB, but you are > not eligible for support or updates.
> Is it really so, that one can buy a subscription for a month and legally > use that version of Raven forever?
Thanks for the information and the transparency. This is very helpful
as we have an application which uses RavenDB and is scheduled to be
live sometime near May of this year. I had it on my list to discuss
licensing and prices with yall soon but it seems a good thing I
waited.
We would, I think, only need the Standard. I have some clarifying
questions, however.
Under the standard license would a developer running an instance
locally for development purposes count against the RAM/Cores/Database
limits?
You indicated that electing to pay the subscription fee includes, in
addition to continued upgrades, 2 additional support incidents. Do
unused support incidents rollover from period to period? (For example,
if during the initial 18 months we make 2 calls to support. Then we
pay the annual subscription. Do we now have 4 incidents covered (the
unused 2 plus the new 2) or just 2?)
Do you, or will you, have a discount for non-profit organizations?
I think that covers it for now.
Thanks again,
B.
On Feb 24, 4:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Hi guys,
> We are finishing up a big performance cycle, and hopefully we will have a
> new stable next week with all of those goodies for you.
> If all goes well, this will be the last (or one before last) stable release
> in the current version of RavenDB.
> As you probably know, we have been thinking about our licensing strategy,
> and I thought that I'll share with you some of our early thoughts ,to get
> your feedback.
> Probably in March or April, we want to release a new version of RavenDB.
> Probably called 1.2.
> *Important note*:
> We are trying to run as much as possible in the open, and solicit your
> feedback whenever we can. Both on coding and business issues.
> Your feedback is important, and I am not saying this just because it
> sounds good.
> That said, the last time we had a pricing discussion things got somewhat
> ugly. I ask you all to have a polite conversation about this.
> Thanks in advance, Oren.
> Implications for anyone who bought a subscription: None, except that they
> might want to update to the new version.
> Implications for people who made a one time payment:
> If they bought in the last 6 months, they get 1.2 automatically. If they
> bought earlier than that, they need to pay an upgrade fee (249$) per
> instance.
> There are some cases where people expected to be able to get the new
> versions indefinately. If you are one of those, and you bought a one time
> payment more than
> six months ago, contact us, we will make an arrangement that will make both
> of us happy.
> Along with the new version, we intend to change our pricing structure. This
> has several reasons behind that. If you remember the pricing discussion in
> May 2010, one
> of the repeated issues that was brought up was that RavenDB is a NoSQL
> database, and as such its pricing needs to be match the scaling needs.
> Another issue, from our side, is that introducing a new product is always a
> touch period of time, especially one that require the level of trust
> expected from a database.
> The pricing reflected both those issues.
> Now, with over a year and a half in production using multiple customers, we
> have much better data both about common usage patterns and about RavenDB
> itself. The level of
> trust expected from a database is much higher than when we introduced
> RavenDB and I can tell you that so far, no one is running a 25 nodes
> cluster of RavenDB (maybe I
> shouldn't have worked so hard on perf, people would need more servers :-) ).
> All of this leads me to the following changes:
> we are going to introduce RavenDB Standard, RavenDB Enterprise and RavenDB
> Scaleout.
> *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love.
> However, it also would be limited in the following ways:
> Max of 12 GB RAM
> Max of 6 Cores
> Max of 25 databases
> *Note: *If you are have an existing license, either subscription or one
> time payment that got grandfathered in, you don't have to worry about those
> limitations.
> Pricing would still be based on per instance model, which is effectively
> per server.
> Cost per instance would be: 999$ - which include 18 months of support (4
> incidents) and auto upgrades.
> After the time is up, you _can continue to use your RavenDB instance
> with no issues_.
> But, you *won't *be eligible for any additional updates or support.
> Exception for that is security / critical bugs that would still get fixed
> in a period of 36 months from the date you purchase the software.
> Subscriptions would be:
> 399$ per year
> 39$ per month
> In either case, you get 2 support incidents per year. And auto upgrades
> for as long as you have a current subscription.
> If the subscription lapses, you can continue to use RavenDB, but you are
> not eligible for support or updates.
> We will still offer the OEM model for embedded instances, which would be
> 1,599$ per developer per year.
> Now we get to the *RavenDB Enterprise*. First, let us talk about the
> goodies.
> * No limits on RAM / cores / databases
> * Indexing scheduler
> ** Index priorities
> ** Offline index builds (new index won't stop existing indexes updates)
> * Windows Clustering support
> * Builtin compression
> * Builtin encryption
> * Management interface for the server (not just on a single database)
> * Integration for managing all of the builtin bundle
> * Replication monitoring
> * HTTP Support when running in service mode
> * S3 backup support
> And probably a bunch of other stuff as well, but we want to have a _few_
> surprises.
> RavenDB Enterprise will be licensed per core. Number of cores is defined as
> whatever Environment.ProcessCount returns, for simplicity sake.
> I don't have final pricing for that yet, so I would like to get your
> opinions on the matter.
> I am looking at having a similar range betwen RavenDB Enterprise and SQL
> Enterprise as between RavenDB Standard and SQL Standard, but I haven't made
> up my mind.
> Finaly, we have *RavneDB Scaleout*.
> This is meant to answer the need of people who need large number of RavenDB
> servers (the 20 nodes RavenDB cluster).
> Pricing for that is based on a 25 instances bundle, at a cost of 750$ per
> instance. So a 25 bundle would cost 18,500$.
> If you need more than 25 - 50 nodes, you probably need to call us and we
> can talk about prices anyway.
Phil, I am reluctant to provide a completely free edition. I was hired at one point to implement sharding support for a project because they were explicitly attempting to avoid the 4GB limit of SQL Express.
I have little problem with offering RavenDB Basic, at a reduce cost with reduced features, but I am not sure what those would be.
While I agree that RAM today is cheap, today you usually get VMs with 4 - 8 GB for most servers. This is true both on the cloud and on most companies that I have worked with recently. The actual server might have 32 or 64 GB, but not to OS running the actual DB server.
The choice of 6 cores and 12 GB was explicitly chosen so when you get to high end servers (and believe be, RavenDB can handle quite a lot of load on that hardware), you would move to the enterprise edition.
Regarding VAT, that is something that I have no control over, and during the order process, you should have seen the VAT in the subtotal. Adding "excluding" VAT is pretty confusing when you have people that don't have VAT, then they start worrying whatever they have to pay Israeli's VAT, or someone else's VAT, etc.
On Fri, Feb 24, 2012 at 4:06 PM, Phil Jones <phil.jone...@gmail.com> wrote: > My initial feedback:
> I think overall this is acceptable but a few things to consider might > be:
> Introduce a cheap tier for the cheapskates who moan about the cost of > RavenDB versus SQL Server Express. I would do low limits like max 1GB > ram, 5 databases etc.
> The standard tier's RAM limit is disappointing with RAM being so > cheap. My next development machine will have 32GB and only cost me > £200 for that 32GB. I would like to see it set a little bit higher, > the max I'm aware a consumer machine could have is 64GB but 32GB would > make me happy :)
> Standard going up to $39pm is fine with the current exchange. Although > I bought a license last night (at $25) that converted to £16.85 but > came to £20.22 as I forgot the VAT. Perhaps add a little message along > the lines of "exclude sales tax for your country/region/state".
> On Skype or email me if you want to talk about scenarios around > "RavenDB Express", I did a grok (10 minute) talk on Wednesday on > RavenDB and had several questions as I always do about pricing and > comments regarding SQL Express being free :(
> On Feb 24, 9:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com> > wrote: > > Hi guys, > > We are finishing up a big performance cycle, and hopefully we will have a > > new stable next week with all of those goodies for you. > > If all goes well, this will be the last (or one before last) stable > release > > in the current version of RavenDB.
> > As you probably know, we have been thinking about our licensing strategy, > > and I thought that I'll share with you some of our early thoughts ,to get > > your feedback. > > Probably in March or April, we want to release a new version of RavenDB. > > Probably called 1.2.
> > *Important note*: > > We are trying to run as much as possible in the open, and solicit your > > feedback whenever we can. Both on coding and business issues. > > Your feedback is important, and I am not saying this just because it > > sounds good. > > That said, the last time we had a pricing discussion things got > somewhat > > ugly. I ask you all to have a polite conversation about this. > > Thanks in advance, Oren.
> > Implications for anyone who bought a subscription: None, except that they > > might want to update to the new version.
> > Implications for people who made a one time payment: > > If they bought in the last 6 months, they get 1.2 automatically. If they > > bought earlier than that, they need to pay an upgrade fee (249$) per > > instance. > > There are some cases where people expected to be able to get the new > > versions indefinately. If you are one of those, and you bought a one time > > payment more than > > six months ago, contact us, we will make an arrangement that will make > both > > of us happy.
> > Along with the new version, we intend to change our pricing structure. > This > > has several reasons behind that. If you remember the pricing discussion > in > > May 2010, one > > of the repeated issues that was brought up was that RavenDB is a NoSQL > > database, and as such its pricing needs to be match the scaling needs. > > Another issue, from our side, is that introducing a new product is > always a > > touch period of time, especially one that require the level of trust > > expected from a database. > > The pricing reflected both those issues.
> > Now, with over a year and a half in production using multiple customers, > we > > have much better data both about common usage patterns and about RavenDB > > itself. The level of > > trust expected from a database is much higher than when we introduced > > RavenDB and I can tell you that so far, no one is running a 25 nodes > > cluster of RavenDB (maybe I > > shouldn't have worked so hard on perf, people would need more servers > :-) ).
> > All of this leads me to the following changes:
> > we are going to introduce RavenDB Standard, RavenDB Enterprise and > RavenDB > > Scaleout.
> > *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. > > However, it also would be limited in the following ways:
> > Max of 12 GB RAM > > Max of 6 Cores > > Max of 25 databases
> > *Note: *If you are have an existing license, either subscription or one > > time payment that got grandfathered in, you don't have to worry about > those > > limitations.
> > Pricing would still be based on per instance model, which is effectively > > per server.
> > Cost per instance would be: 999$ - which include 18 months of support (4 > > incidents) and auto upgrades. > > After the time is up, you _can continue to use your RavenDB instance > > with no issues_. > > But, you *won't *be eligible for any additional updates or support.
> > Exception for that is security / critical bugs that would still get > fixed > > in a period of 36 months from the date you purchase the software.
> > Subscriptions would be: > > 399$ per year > > 39$ per month
> > In either case, you get 2 support incidents per year. And auto upgrades > > for as long as you have a current subscription. > > If the subscription lapses, you can continue to use RavenDB, but you > are > > not eligible for support or updates.
> > We will still offer the OEM model for embedded instances, which would be > > 1,599$ per developer per year.
> > Now we get to the *RavenDB Enterprise*. First, let us talk about the > > goodies.
> > * No limits on RAM / cores / databases > > * Indexing scheduler > > ** Index priorities > > ** Offline index builds (new index won't stop existing indexes updates) > > * Windows Clustering support > > * Builtin compression > > * Builtin encryption > > * Management interface for the server (not just on a single database) > > * Integration for managing all of the builtin bundle > > * Replication monitoring > > * HTTP Support when running in service mode > > * S3 backup support
> > And probably a bunch of other stuff as well, but we want to have a _few_ > > surprises.
> > RavenDB Enterprise will be licensed per core. Number of cores is defined > as > > whatever Environment.ProcessCount returns, for simplicity sake. > > I don't have final pricing for that yet, so I would like to get your > > opinions on the matter. > > I am looking at having a similar range betwen RavenDB Enterprise and SQL > > Enterprise as between RavenDB Standard and SQL Standard, but I haven't > made > > up my mind.
> > Finaly, we have *RavneDB Scaleout*. > > This is meant to answer the need of people who need large number of > RavenDB > > servers (the 20 nodes RavenDB cluster). > > Pricing for that is based on a 25 instances bundle, at a cost of 750$ per > > instance. So a 25 bundle would cost 18,500$. > > If you need more than 25 - 50 nodes, you probably need to call us and we > > can talk about prices anyway.
That is something that I am aware off. I am not sure if this is a feature or a bug. But I am concerned with people ending up with a dead app because they forgot to send the subscription check, or because someone left their job and the notification went to /dev/null
aye...@ayende.com> wrote: > That is something that I am aware off. > I am not sure if this is a feature or a bug. > But I am concerned with people ending up with a dead app because they > forgot to send the subscription check, or because someone left their job > and the notification went to /dev/null
> I would love to hear feedback on that.
> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com>wrote:
>> > Subscriptions would be: >> > 39$ per month
>> > If the subscription lapses, you can continue to use RavenDB, but you >> are not eligible for support or updates.
>> Is it really so, that one can buy a subscription for a month and legally >> use that version of Raven forever?
On Fri, Feb 24, 2012 at 4:43 PM, Wyatt Barnett <wyatt.barn...@gmail.com>wrote:
> First, congratulations on getting the product to the point you can > have this discussion. It is quite exciting.
> On the standard edition -- how is the limit enforced? It is pretty > tricky to get a server with six cores and less than 12gb of RAM these > days if you are still running on iron
See my comment to Phil with regards to the selection of those limits .Most of the users run on either cloud machine or self hosted VMs.
> . I'm not a huge fan of the 25 DB > limit, I'd argue that a database size limit is a better option if > possible. The main reason is it matches what most other database > servers use as the limit to the lower-priced version.
Part of the reason that I want to get feedback. Are you actually using that many databases? In what scenarios? I would like to avoid having a DB size limit because most other DBs do not on paid versions.
> What do the development options look like? I think it would be awesome > if there was a raven db enterprise developer edition, much like sql > developer.
Yes, there will be a development story around that, too.
> On Feb 24, 4:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com> > wrote: > > Hi guys, > > We are finishing up a big performance cycle, and hopefully we will have a > > new stable next week with all of those goodies for you. > > If all goes well, this will be the last (or one before last) stable > release > > in the current version of RavenDB.
> > As you probably know, we have been thinking about our licensing strategy, > > and I thought that I'll share with you some of our early thoughts ,to get > > your feedback. > > Probably in March or April, we want to release a new version of RavenDB. > > Probably called 1.2.
> > *Important note*: > > We are trying to run as much as possible in the open, and solicit your > > feedback whenever we can. Both on coding and business issues. > > Your feedback is important, and I am not saying this just because it > > sounds good. > > That said, the last time we had a pricing discussion things got > somewhat > > ugly. I ask you all to have a polite conversation about this. > > Thanks in advance, Oren.
> > Implications for anyone who bought a subscription: None, except that they > > might want to update to the new version.
> > Implications for people who made a one time payment: > > If they bought in the last 6 months, they get 1.2 automatically. If they > > bought earlier than that, they need to pay an upgrade fee (249$) per > > instance. > > There are some cases where people expected to be able to get the new > > versions indefinately. If you are one of those, and you bought a one time > > payment more than > > six months ago, contact us, we will make an arrangement that will make > both > > of us happy.
> > Along with the new version, we intend to change our pricing structure. > This > > has several reasons behind that. If you remember the pricing discussion > in > > May 2010, one > > of the repeated issues that was brought up was that RavenDB is a NoSQL > > database, and as such its pricing needs to be match the scaling needs. > > Another issue, from our side, is that introducing a new product is > always a > > touch period of time, especially one that require the level of trust > > expected from a database. > > The pricing reflected both those issues.
> > Now, with over a year and a half in production using multiple customers, > we > > have much better data both about common usage patterns and about RavenDB > > itself. The level of > > trust expected from a database is much higher than when we introduced > > RavenDB and I can tell you that so far, no one is running a 25 nodes > > cluster of RavenDB (maybe I > > shouldn't have worked so hard on perf, people would need more servers > :-) ).
> > All of this leads me to the following changes:
> > we are going to introduce RavenDB Standard, RavenDB Enterprise and > RavenDB > > Scaleout.
> > *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. > > However, it also would be limited in the following ways:
> > Max of 12 GB RAM > > Max of 6 Cores > > Max of 25 databases
> > *Note: *If you are have an existing license, either subscription or one > > time payment that got grandfathered in, you don't have to worry about > those > > limitations.
> > Pricing would still be based on per instance model, which is effectively > > per server.
> > Cost per instance would be: 999$ - which include 18 months of support (4 > > incidents) and auto upgrades. > > After the time is up, you _can continue to use your RavenDB instance > > with no issues_. > > But, you *won't *be eligible for any additional updates or support.
> > Exception for that is security / critical bugs that would still get > fixed > > in a period of 36 months from the date you purchase the software.
> > Subscriptions would be: > > 399$ per year > > 39$ per month
> > In either case, you get 2 support incidents per year. And auto upgrades > > for as long as you have a current subscription. > > If the subscription lapses, you can continue to use RavenDB, but you > are > > not eligible for support or updates.
> > We will still offer the OEM model for embedded instances, which would be > > 1,599$ per developer per year.
> > Now we get to the *RavenDB Enterprise*. First, let us talk about the > > goodies.
> > * No limits on RAM / cores / databases > > * Indexing scheduler > > ** Index priorities > > ** Offline index builds (new index won't stop existing indexes updates) > > * Windows Clustering support > > * Builtin compression > > * Builtin encryption > > * Management interface for the server (not just on a single database) > > * Integration for managing all of the builtin bundle > > * Replication monitoring > > * HTTP Support when running in service mode > > * S3 backup support
> > And probably a bunch of other stuff as well, but we want to have a _few_ > > surprises.
> > RavenDB Enterprise will be licensed per core. Number of cores is defined > as > > whatever Environment.ProcessCount returns, for simplicity sake. > > I don't have final pricing for that yet, so I would like to get your > > opinions on the matter. > > I am looking at having a similar range betwen RavenDB Enterprise and SQL > > Enterprise as between RavenDB Standard and SQL Standard, but I haven't > made > > up my mind.
> > Finaly, we have *RavneDB Scaleout*. > > This is meant to answer the need of people who need large number of > RavenDB > > servers (the 20 nodes RavenDB cluster). > > Pricing for that is based on a 25 instances bundle, at a cost of 750$ per > > instance. So a 25 bundle would cost 18,500$. > > If you need more than 25 - 50 nodes, you probably need to call us and we > > can talk about prices anyway.
On Fri, Feb 24, 2012 at 5:43 PM, BAM <b...@bryanvt.net> wrote: > Oren,
> Thanks for the information and the transparency. This is very helpful > as we have an application which uses RavenDB and is scheduled to be > live sometime near May of this year. I had it on my list to discuss > licensing and prices with yall soon but it seems a good thing I > waited.
> We would, I think, only need the Standard. I have some clarifying > questions, however.
> Under the standard license would a developer running an instance > locally for development purposes count against the RAM/Cores/Database > limits?
No, this would be a development instance. Separate from the production instance. We will keep development instances free.
> You indicated that electing to pay the subscription fee includes, in > addition to continued upgrades, 2 additional support incidents. Do > unused support incidents rollover from period to period? (For example, > if during the initial 18 months we make 2 calls to support. Then we > pay the annual subscription. Do we now have 4 incidents covered (the > unused 2 plus the new 2) or just 2?)
No, it does not roll over.
> Do you, or will you, have a discount for non-profit organizations?
Contact me with the actual details, but we routinely provide discounts to NFP and charities.
> On Feb 24, 4:02 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com> > wrote: > > Hi guys, > > We are finishing up a big performance cycle, and hopefully we will have a > > new stable next week with all of those goodies for you. > > If all goes well, this will be the last (or one before last) stable > release > > in the current version of RavenDB.
> > As you probably know, we have been thinking about our licensing strategy, > > and I thought that I'll share with you some of our early thoughts ,to get > > your feedback. > > Probably in March or April, we want to release a new version of RavenDB. > > Probably called 1.2.
> > *Important note*: > > We are trying to run as much as possible in the open, and solicit your > > feedback whenever we can. Both on coding and business issues. > > Your feedback is important, and I am not saying this just because it > > sounds good. > > That said, the last time we had a pricing discussion things got > somewhat > > ugly. I ask you all to have a polite conversation about this. > > Thanks in advance, Oren.
> > Implications for anyone who bought a subscription: None, except that they > > might want to update to the new version.
> > Implications for people who made a one time payment: > > If they bought in the last 6 months, they get 1.2 automatically. If they > > bought earlier than that, they need to pay an upgrade fee (249$) per > > instance. > > There are some cases where people expected to be able to get the new > > versions indefinately. If you are one of those, and you bought a one time > > payment more than > > six months ago, contact us, we will make an arrangement that will make > both > > of us happy.
> > Along with the new version, we intend to change our pricing structure. > This > > has several reasons behind that. If you remember the pricing discussion > in > > May 2010, one > > of the repeated issues that was brought up was that RavenDB is a NoSQL > > database, and as such its pricing needs to be match the scaling needs. > > Another issue, from our side, is that introducing a new product is > always a > > touch period of time, especially one that require the level of trust > > expected from a database. > > The pricing reflected both those issues.
> > Now, with over a year and a half in production using multiple customers, > we > > have much better data both about common usage patterns and about RavenDB > > itself. The level of > > trust expected from a database is much higher than when we introduced > > RavenDB and I can tell you that so far, no one is running a 25 nodes > > cluster of RavenDB (maybe I > > shouldn't have worked so hard on perf, people would need more servers > :-) ).
> > All of this leads me to the following changes:
> > we are going to introduce RavenDB Standard, RavenDB Enterprise and > RavenDB > > Scaleout.
> > *RavenDB Standard* is the RavenDB that you all know and (hoepfully) love. > > However, it also would be limited in the following ways:
> > Max of 12 GB RAM > > Max of 6 Cores > > Max of 25 databases
> > *Note: *If you are have an existing license, either subscription or one > > time payment that got grandfathered in, you don't have to worry about > those > > limitations.
> > Pricing would still be based on per instance model, which is effectively > > per server.
> > Cost per instance would be: 999$ - which include 18 months of support (4 > > incidents) and auto upgrades. > > After the time is up, you _can continue to use your RavenDB instance > > with no issues_. > > But, you *won't *be eligible for any additional updates or support.
> > Exception for that is security / critical bugs that would still get > fixed > > in a period of 36 months from the date you purchase the software.
> > Subscriptions would be: > > 399$ per year > > 39$ per month
> > In either case, you get 2 support incidents per year. And auto upgrades > > for as long as you have a current subscription. > > If the subscription lapses, you can continue to use RavenDB, but you > are > > not eligible for support or updates.
> > We will still offer the OEM model for embedded instances, which would be > > 1,599$ per developer per year.
> > Now we get to the *RavenDB Enterprise*. First, let us talk about the > > goodies.
> > * No limits on RAM / cores / databases > > * Indexing scheduler > > ** Index priorities > > ** Offline index builds (new index won't stop existing indexes updates) > > * Windows Clustering support > > * Builtin compression > > * Builtin encryption > > * Management interface for the server (not just on a single database) > > * Integration for managing all of the builtin bundle > > * Replication monitoring > > * HTTP Support when running in service mode > > * S3 backup support
> > And probably a bunch of other stuff as well, but we want to have a _few_ > > surprises.
> > RavenDB Enterprise will be licensed per core. Number of cores is defined > as > > whatever Environment.ProcessCount returns, for simplicity sake. > > I don't have final pricing for that yet, so I would like to get your > > opinions on the matter. > > I am looking at having a similar range betwen RavenDB Enterprise and SQL > > Enterprise as between RavenDB Standard and SQL Standard, but I haven't > made > > up my mind.
> > Finaly, we have *RavneDB Scaleout*. > > This is meant to answer the need of people who need large number of > RavenDB > > servers (the 20 nodes RavenDB cluster). > > Pricing for that is based on a 25 instances bundle, at a cost of 750$ per > > instance. So a 25 bundle would cost 18,500$. > > If you need more than 25 - 50 nodes, you probably need to call us and we > > can talk about prices anyway.
On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> wrote: > Perhaps you could implement a "limp home" mode where there could only be > one index processing, or disable query paging, or.......etc.
> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
>> That is something that I am aware off. >> I am not sure if this is a feature or a bug. >> But I am concerned with people ending up with a dead app because they >> forgot to send the subscription check, or because someone left their job >> and the notification went to /dev/null
>> I would love to hear feedback on that.
>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com>wrote:
>>> > Subscriptions would be: >>> > 39$ per month
>>> > If the subscription lapses, you can continue to use RavenDB, but you >>> are not eligible for support or updates.
>>> Is it really so, that one can buy a subscription for a month and legally >>> use that version of Raven forever?
Yes, but in both of those examples, the system wasn't crippled it was Microsoft's polite way of shooting it in the back of the head and trying to make you feel good about it.
On Fri, Feb 24, 2012 at 9:57 AM, Oren Eini (Ayende Rahien) <
> On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> wrote:
>> Perhaps you could implement a "limp home" mode where there could only be >> one index processing, or disable query paging, or.......etc.
>> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) < >> aye...@ayende.com> wrote:
>>> That is something that I am aware off. >>> I am not sure if this is a feature or a bug. >>> But I am concerned with people ending up with a dead app because they >>> forgot to send the subscription check, or because someone left their job >>> and the notification went to /dev/null
>>> I would love to hear feedback on that.
>>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com>wrote:
>>>> > Subscriptions would be: >>>> > 39$ per month
>>>> > If the subscription lapses, you can continue to use RavenDB, but you >>>> are not eligible for support or updates.
>>>> Is it really so, that one can buy a subscription for a month and >>>> legally use that version of Raven forever?
On Fri, Feb 24, 2012 at 6:04 PM, Dave Nay <david....@gmail.com> wrote: > Yes, but in both of those examples, the system wasn't crippled it was > Microsoft's polite way of shooting it in the back of the head and trying to > make you feel good about it.
> On Fri, Feb 24, 2012 at 9:57 AM, Oren Eini (Ayende Rahien) < > aye...@ayende.com> wrote:
>> Dave, >> *lol*
>> I just feel incredibly uncomfortable with anything that cripple a running >> system.
>> On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> wrote:
>>> Perhaps you could implement a "limp home" mode where there could only be >>> one index processing, or disable query paging, or.......etc.
>>> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) < >>> aye...@ayende.com> wrote:
>>>> That is something that I am aware off. >>>> I am not sure if this is a feature or a bug. >>>> But I am concerned with people ending up with a dead app because they >>>> forgot to send the subscription check, or because someone left their job >>>> and the notification went to /dev/null
>>>> I would love to hear feedback on that.
>>>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com>wrote:
>>>>> > Subscriptions would be: >>>>> > 39$ per month
>>>>> > If the subscription lapses, you can continue to use RavenDB, but you >>>>> are not eligible for support or updates.
>>>>> Is it really so, that one can buy a subscription for a month and >>>>> legally use that version of Raven forever?
I wasn't suggesting a completely *free* version of RavenDB, but more
like $5-10pm etc. Cheap enough that people don't dismiss RavenDB but
don't take for granted its a commercial tool. The aim being they get
hooked.
I guess the max I've ever run RavenDB with clients is 3-4GB worth of
RAM used, I just don't want the ceiling to be too low that I hit it
before needing the enterprise features.
I didn't realise you could run a site without a renewed subscription.
My preferred approach would be nagging prompts over crippling the
system as often I just leave systems for a month or two without doing
updates until clients have money or need changes. Awakening at 4am to
RavenDB screaming about licensing would be a pain ;-)
Phil
On Feb 24, 4:04 pm, Dave Nay <david....@gmail.com> wrote:
> Yes, but in both of those examples, the system wasn't crippled it was
> Microsoft's polite way of shooting it in the back of the head and trying to
> make you feel good about it.
> On Fri, Feb 24, 2012 at 9:57 AM, Oren Eini (Ayende Rahien) <
> > On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> wrote:
> >> Perhaps you could implement a "limp home" mode where there could only be
> >> one index processing, or disable query paging, or.......etc.
> >> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) <
> >> aye...@ayende.com> wrote:
> >>> That is something that I am aware off.
> >>> I am not sure if this is a feature or a bug.
> >>> But I am concerned with people ending up with a dead app because they
> >>> forgot to send the subscription check, or because someone left their job
> >>> and the notification went to /dev/null
> >>> I would love to hear feedback on that.
> >>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com>wrote:
> >>>> > Subscriptions would be:
> >>>> > 39$ per month
> >>>> > If the subscription lapses, you can continue to use RavenDB, but you
> >>>> are not eligible for support or updates.
> >>>> Is it really so, that one can buy a subscription for a month and
> >>>> legally use that version of Raven forever?
Phil, Exactly my feeling. Currently, running without a license would prompt you whenever you log into the UI. I guess that is something that we would could enhance somehow?
On Fri, Feb 24, 2012 at 6:17 PM, Phil Jones <phil.jone...@gmail.com> wrote: > Oren,
> I wasn't suggesting a completely *free* version of RavenDB, but more > like $5-10pm etc. Cheap enough that people don't dismiss RavenDB but > don't take for granted its a commercial tool. The aim being they get > hooked.
> I guess the max I've ever run RavenDB with clients is 3-4GB worth of > RAM used, I just don't want the ceiling to be too low that I hit it > before needing the enterprise features.
> I didn't realise you could run a site without a renewed subscription. > My preferred approach would be nagging prompts over crippling the > system as often I just leave systems for a month or two without doing > updates until clients have money or need changes. Awakening at 4am to > RavenDB screaming about licensing would be a pain ;-)
> Phil
> On Feb 24, 4:04 pm, Dave Nay <david....@gmail.com> wrote: > > Yes, but in both of those examples, the system wasn't crippled it was > > Microsoft's polite way of shooting it in the back of the head and trying > to > > make you feel good about it.
> > On Fri, Feb 24, 2012 at 9:57 AM, Oren Eini (Ayende Rahien) <
> > > On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> wrote:
> > >> Perhaps you could implement a "limp home" mode where there could only > be > > >> one index processing, or disable query paging, or.......etc.
> > >> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) < > > >> aye...@ayende.com> wrote:
> > >>> That is something that I am aware off. > > >>> I am not sure if this is a feature or a bug. > > >>> But I am concerned with people ending up with a dead app because they > > >>> forgot to send the subscription check, or because someone left their > job > > >>> and the notification went to /dev/null
> > >>> I would love to hear feedback on that.
> > >>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix <artur.drobins...@gmail.com > >wrote:
> > >>>> > Subscriptions would be: > > >>>> > 39$ per month
> > >>>> > If the subscription lapses, you can continue to use RavenDB, but > you > > >>>> are not eligible for support or updates.
> > >>>> Is it really so, that one can buy a subscription for a month and > > >>>> legally use that version of Raven forever?
On Friday, February 24, 2012 9:43:34 AM UTC-5, Wyatt Barnett wrote:
> I'd argue that a database size limit is a better option if > possible.
That is completely unacceptable. This is not an express verison this is RavenDB standard. Very similar to the conventions Microsoft applies to Sql Server standard. With server software it's completely normal to limit scale on standard versions. The limits Oren is talking about is very similar to Sql Server standard so it is directly in line with industry standards.
Moving to a size limitation would completely cripple the standard edition.
In order of most important to me, to not as important but wanted:
Builtin encryption Index priorities Offline index builds (new index won't stop existing indexes updates) Management interface for the server (not just on a single database) S3 backup support Replication monitoring
On Fri, Feb 24, 2012 at 6:25 PM, Chris Marisic <ch...@marisic.com> wrote: > In order of most important to me, to not as important but wanted:
> Builtin encryption
- On RavenHQ? That is something that you care baout?
> Index priorities > Offline index builds (new index won't stop existing indexes updates) > Management interface for the server (not just on a single database) > S3 backup support > Replication monitoring
> Not sure what exactly these features mean:
> Windows Clustering support
Windows has something called clustering, where you can have two nodes running and fail over to one another. This is very common with database servers ,and it will be supported for RavenDB Enterprise. http://en.wikipedia.org/wiki/Microsoft_Cluster_Server
> Indexing scheduler
- this is how you define things like priorities and how often new indexes gets run, etc.
The only harsh measure that would be acceptable IMO with RavenDB would be that when it detects its licensing is not valid, that it will reject SOME queries with 402 Payment required.
This will cause site errors, and errors to appear in ELMAH or other logs, things that should get attention and intervention. If Raven always respects LOAD & PUT having queries fault ever so many queries etc is a rather large impediment but not outright crippled, it also makes sure the underlying data is still always valid as it's not rejecting writes ever, or even direct loads.
On Friday, February 24, 2012 11:19:17 AM UTC-5, Ayende Rahien wrote:
> Phil, > Exactly my feeling. > Currently, running without a license would prompt you whenever you log > into the UI. > I guess that is something that we would could enhance somehow?
> On Fri, Feb 24, 2012 at 6:17 PM, Phil Jones <...> wrote:
>> Oren,
>> I wasn't suggesting a completely *free* version of RavenDB, but more >> like $5-10pm etc. Cheap enough that people don't dismiss RavenDB but >> don't take for granted its a commercial tool. The aim being they get >> hooked.
>> I guess the max I've ever run RavenDB with clients is 3-4GB worth of >> RAM used, I just don't want the ceiling to be too low that I hit it >> before needing the enterprise features.
>> I didn't realise you could run a site without a renewed subscription. >> My preferred approach would be nagging prompts over crippling the >> system as often I just leave systems for a month or two without doing >> updates until clients have money or need changes. Awakening at 4am to >> RavenDB screaming about licensing would be a pain ;-)
>> Phil
>> On Feb 24, 4:04 pm, Dave Nay <david....@gmail.com> wrote: >> > Yes, but in both of those examples, the system wasn't crippled it was >> > Microsoft's polite way of shooting it in the back of the head and >> trying to >> > make you feel good about it.
>> > On Fri, Feb 24, 2012 at 9:57 AM, Oren Eini (Ayende Rahien) <
>> > > On Fri, Feb 24, 2012 at 5:53 PM, Dave Nay <david....@gmail.com> >> wrote:
>> > >> Perhaps you could implement a "limp home" mode where there could >> only be >> > >> one index processing, or disable query paging, or.......etc.
>> > >> On Fri, Feb 24, 2012 at 9:50 AM, Oren Eini (Ayende Rahien) < >> > >> aye...@ayende.com> wrote:
>> > >>> That is something that I am aware off. >> > >>> I am not sure if this is a feature or a bug. >> > >>> But I am concerned with people ending up with a dead app because >> they >> > >>> forgot to send the subscription check, or because someone left >> their job >> > >>> and the notification went to /dev/null
>> > >>> I would love to hear feedback on that.
>> > >>> On Fri, Feb 24, 2012 at 4:33 PM, Shaddix < >> artur.drobins...@gmail.com>wrote:
>> > >>>> > Subscriptions would be: >> > >>>> > 39$ per month
>> > >>>> > If the subscription lapses, you can continue to use RavenDB, but >> you >> > >>>> are not eligible for support or updates.
>> > >>>> Is it really so, that one can buy a subscription for a month and >> > >>>> legally use that version of Raven forever?
S3 Backup support is a feature I would want in standard to be honest.
I would like RavenDB to every day send an incremental backup to S3,
every week a full backup.
My dream! No more windows task scheduler and using S3 means I store
them offsite without worrying.
You could offer an enhanced feature of this for Enterprise:
Perhaps only incremental for Enterprise
Support other methods (I don't know say FTP/Network shares etc)
Scheduling triggers (More than X documents added to Raven)
Finer scheduling support (say choose minute/second)
On Feb 24, 4:25 pm, Chris Marisic <ch...@marisic.com> wrote:
> In order of most important to me, to not as important but wanted:
> Builtin encryption
> Index priorities
> Offline index builds (new index won't stop existing indexes updates)
> Management interface for the server (not just on a single database)
> S3 backup support
> Replication monitoring
> Not sure what exactly these features mean:
> Windows Clustering support
> Indexing scheduler
> On Friday, February 24, 2012 10:03:14 AM UTC-5, Ayende Rahien wrote:
> > RavenHQ will likely offer at least some of those features, yes
> > Of the list, what do you want there?
> > On Friday, February 24, 2012, Chris Marisic wrote:
> >> This is a very straight forward and fair pricing scheme.
> >> Will RavenDB enterprise be available from RavenHQ? That feature list is
> >> outright impressive.
