Plans for the future (pricing, editions, etc)

762 views
Skip to first unread message

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 4:02:49 AM2/24/12
to ravendb
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.

Dave Nay

unread,
Feb 24, 2012, 8:57:42 AM2/24/12
to rav...@googlegroups.com
Are those prices all in USD?

Phil Jones

unread,
Feb 24, 2012, 9:06:15 AM2/24/12
to ravendb
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*:
> *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*.

Chris Marisic

unread,
Feb 24, 2012, 9:11:08 AM2/24/12
to rav...@googlegroups.com
This is a very straight forward and fair pricing scheme.

Will RavenDB enterprise be available from RavenHQ? That feature list is outright impressive.

Shaddix

unread,
Feb 24, 2012, 9:33:25 AM2/24/12
to rav...@googlegroups.com
> 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?

Wyatt Barnett

unread,
Feb 24, 2012, 9:43:34 AM2/24/12
to ravendb
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*:
> *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*.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:01:45 AM2/24/12
to rav...@googlegroups.com
Yes 

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:03:14 AM2/24/12
to rav...@googlegroups.com
RavenHQ will likely offer at least some of those features, yes
Of the list, what do you want there?

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:05:11 AM2/24/12
to rav...@googlegroups.com
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

BAM

unread,
Feb 24, 2012, 10:43:34 AM2/24/12
to ravendb
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 y’all 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*:
> *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*.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:48:01 AM2/24/12
to rav...@googlegroups.com
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.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:50:53 AM2/24/12
to rav...@googlegroups.com
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.

Dave Nay

unread,
Feb 24, 2012, 10:53:09 AM2/24/12
to rav...@googlegroups.com
Perhaps you could implement a "limp home" mode where there could only be one index processing, or disable query paging, or.......etc.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:54:03 AM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 4:43 PM, Wyatt Barnett <wyatt....@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.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:55:45 AM2/24/12
to rav...@googlegroups.com
inline

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 y’all 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.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 10:57:57 AM2/24/12
to rav...@googlegroups.com
Dave,
*lol*

I just feel incredibly uncomfortable with anything that cripple a running system.

Take a look at this:

And more importantly, this:

Dave Nay

unread,
Feb 24, 2012, 11:04:51 AM2/24/12
to rav...@googlegroups.com
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.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:16:39 AM2/24/12
to rav...@googlegroups.com
In the later system, I actually had a server down because of that. As in, not able to take orders.
That is a BAD place to be in.

Phil Jones

unread,
Feb 24, 2012, 11:17:40 AM2/24/12
to ravendb
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) <
>
>
>
>
>
>
>
> aye...@ayende.com> wrote:
> > Dave,
> > *lol*
>
> > I just feel incredibly uncomfortable with anything that cripple a running
> > system.
>
> > Take a look at this:
>
> >http://ayende.com/blog/3736/windows-activation-sucks-how-to-give-some...
>
> > And more importantly, this:
>
> >http://ayende.com/blog/4308/nhprof-com-downtime-and-using-windows-as-...
>
> > 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.
>

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:19:17 AM2/24/12
to rav...@googlegroups.com
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?

Chris Marisic

unread,
Feb 24, 2012, 11:22:32 AM2/24/12
to rav...@googlegroups.com


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.

Chris Marisic

unread,
Feb 24, 2012, 11:25:01 AM2/24/12
to rav...@googlegroups.com
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

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:28:04 AM2/24/12
to rav...@googlegroups.com
inline

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.
 
Indexing scheduler 
 - this is how you define things like priorities and how often new indexes gets run, etc. 

Chris Marisic

unread,
Feb 24, 2012, 11:29:46 AM2/24/12
to rav...@googlegroups.com
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?

Phil Jones

unread,
Feb 24, 2012, 11:32:34 AM2/24/12
to ravendb
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)

Wyatt Barnett

unread,
Feb 24, 2012, 11:35:29 AM2/24/12
to ravendb
> 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.

Your comments to phil make total sense but didn't quite answer my
question. To restate -- if I install RavenDb 1.2 Standard on a machine
with 12 cores and 64gb of RAM what will it do? Refuse to install or
start? Or just make use of 6 cores and 12gb of RAM?

> 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.

Well, I can't think of another DB server that has a limit on the
number of databases I can create either :)
As for our use case, we live in a world that can best be described as
"death by 1000 cuts". I haven't come too close to 25 dbs yet, but I
could easily see it happening over time here. What makes me
uncomfortable is asking "are we at the DB limit" is not in our typical
calculus for deployment of an app. But thinking through size
limitations for certain SKUs is.

Hermano Cabral

unread,
Feb 24, 2012, 11:37:00 AM2/24/12
to rav...@googlegroups.com
What's wrong with the old model of paying for additional services, not the db?

As for the license detection thing, either completely stop working or disable some feature (eg. revert to the mot basic version). Failure due to invalid license should be something predictable and easy to fix.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:41:20 AM2/24/12
to rav...@googlegroups.com
Chris,
Unless that 402 query that you just got caused you to lose a 1 million dollars transaction.
How DO you decide what to refuse?

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:42:37 AM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 6:35 PM, Wyatt Barnett <wyatt....@gmail.com> wrote:
> 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.

Your comments to phil make total sense but didn't quite answer my
question. To restate -- if I install RavenDb 1.2 Standard on a machine
with 12 cores and 64gb of RAM what will it do? Refuse to install or
start? Or just make use of 6 cores and 12gb of RAM?


It will use 6 cores and up to 12 GB, yes.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 11:43:28 AM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 6:37 PM, Hermano Cabral <herman...@creactive.com.br> wrote:
What's wrong with the old model of paying for additional services, not the db?


what additional services do you mean?
 
As for the license detection thing, either completely stop working or disable some feature (eg. revert to the mot basic version). Failure due to invalid license should be something predictable and easy to fix.


That might be it, we could do indexing on a single thread on that scenario, I guess.

Chris Marisic

unread,
Feb 24, 2012, 11:58:31 AM2/24/12
to rav...@googlegroups.com


On Friday, February 24, 2012 11:43:28 AM UTC-5, Ayende Rahien wrote:

That might be it, we could do indexing on a single thread on that scenario, I guess.


I don't think that would be VERY apparent to an administrator unless they routinely do things on their website. All the websites I work on, I pretty much never touch them after I deploy except to verify that things work for real in production and then go back to dev work. So something that affects performance like that wouldn't be noticed by me unless clients specifically bring up things being "slow".

Hermano Cabral

unread,
Feb 24, 2012, 12:07:48 PM2/24/12
to rav...@googlegroups.com
Don't you have tools monitoring the event log for errors and stuff? Besides reverting back to the most basic version, RavenDB would also notify the system somehow, event log being the easiest way since lots of tools already work with it. Anyway, it's just how I see it: either do something that can be predictable and easily fixed or you're doing it wrong.

Hermano Cabral

unread,
Feb 24, 2012, 12:12:47 PM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 1:43 PM, Oren Eini (Ayende Rahien) <aye...@ayende.com> wrote:
inline

On Fri, Feb 24, 2012 at 6:37 PM, Hermano Cabral <herman...@creactive.com.br> wrote:
What's wrong with the old model of paying for additional services, not the db?


what additional services do you mean?
Support, training, etc. I honestly don't see the point in having a next generation database using a previous generation pricing scheme.
 
 
As for the license detection thing, either completely stop working or disable some feature (eg. revert to the mot basic version). Failure due to invalid license should be something predictable and easy to fix.


That might be it, we could do indexing on a single thread on that scenario, I guess.
Or maybe limit the RAM usage to 4GB or something like that. Not failing in any manner but having the db working in the most basic way possible.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 12:34:24 PM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 7:12 PM, Hermano Cabral <herman...@creactive.com.br> wrote:
what additional services do you mean?
Support, training, etc. I honestly don't see the point in having a next generation database using a previous generation pricing scheme.


All of those methods rely on two problems.
a) They are heavily people intensive. I would much rather have a small company of expert developers than have to manage a much larger company of trainers, support engineers, etc. 
b) They create an incentive for us to create a tool that isn't the best there is. After all, if we can get RavenDB to auto tune itself, we can't sell you a class on how to tune RavenDB. 

Chris Marisic

unread,
Feb 24, 2012, 1:03:18 PM2/24/12
to rav...@googlegroups.com
How would lessened performance make its way into logs unless it's so degraded it suffers timeouts? That's exactly why I said this nonobvious.

Federico Lois

unread,
Feb 24, 2012, 1:05:16 PM2/24/12
to ravendb
About features for enterprise:

- Azure hosting support.
- Replica sets (single write server/multiple read servers)
- Replication master-slave failover.

Raven 1.2:

- Better handling for queries on Raven Studio (LINQ based with C#
scripting instead of current internal representation).
- Bulk data operations on Raven Studio (delete, query, selection,
etc).
- Automatic backups support.

Regards,
Federico
> > >> outright impressive.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

Hermano Cabral

unread,
Feb 24, 2012, 1:09:23 PM2/24/12
to rav...@googlegroups.com
As I said in the previous message, RavenDB would also notify the system somehow, event log being the easiest way since lots of tools already work with it.

Hermano Cabral

unread,
Feb 24, 2012, 3:03:58 PM2/24/12
to rav...@googlegroups.com
Both fair points, but this pricing scheme looks like something Microsoft would do when launching their NoSQL Server 2013 codename Biarritz. It's not wrong, I just wasn't expecting this in a nosql solution.

IMHO, nosql solutions should be all about making your life simpler.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 3:24:51 PM2/24/12
to rav...@googlegroups.com
What part is there about making a profit?

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 3:44:56 PM2/24/12
to rav...@googlegroups.com
That is the problem. My fear is some unattended site and the only way to get actual attention is via shutting down, which I don't want to do.

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 3:46:44 PM2/24/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 8:05 PM, Federico Lois <federi...@gmail.com> wrote:
About features for enterprise:

- Azure hosting support.

Good point.
 
- Replica sets (single write server/multiple read servers)

Shouldn't be hard to do.
 
- Replication master-slave failover.


Already there, actually.
 
Raven 1.2:

- Better handling for queries on Raven Studio (LINQ based with C#
scripting instead of current internal representation).

We actually had an implementation for that, but the problem is that the only way to support this is to force a database scan, which can be REALLY expensive.
 
- Bulk data operations on Raven Studio (delete, query, selection,
etc).

We already do
 
- Automatic backups support.


Can you explain?

Oren Eini (Ayende Rahien)

unread,
Feb 24, 2012, 3:47:26 PM2/24/12
to rav...@googlegroups.com
Hermano,
We will probably end up there, yes. With the provision that while technically you can still run, you are now in violation of the license.

Federico Lois

unread,
Feb 24, 2012, 4:01:31 PM2/24/12
to rav...@googlegroups.com
Inline

On Fri, Feb 24, 2012 at 5:46 PM, Oren Eini (Ayende Rahien) <aye...@ayende.com> wrote:
inline

On Fri, Feb 24, 2012 at 8:05 PM, Federico Lois <federi...@gmail.com> wrote:
About features for enterprise:

- Azure hosting support.

Good point.
 
- Replica sets (single write server/multiple read servers)

Shouldn't be hard to do.
 
- Replication master-slave failover.


Already there, actually.
 
So there is a voting mechanism for the slave to become master when master goes online already and switch roles?
 
 
Raven 1.2:

- Better handling for queries on Raven Studio (LINQ based with C#
scripting instead of current internal representation).

We actually had an implementation for that, but the problem is that the only way to support this is to force a database scan, which can be REALLY expensive.
 
- Bulk data operations on Raven Studio (delete, query, selection,
etc).

We already do
 
I dont know maybe then I couldnt discover it, finding specific documents and then operate on them in bulk.  
 
 
- Automatic backups support.

 
Explicit extension points to automate backups with the strategy to do it (maybe a bundle?)  So we can specify that daily we do a copy to where-ever.

Brian Vallelunga

unread,
Feb 24, 2012, 9:02:09 PM2/24/12
to rav...@googlegroups.com
I'd like to add two things. First, as long as the standard version will run on a server with higher capacity than 6 cores, 12GB, but only utilize that amount, that's fine. Even low-end servers run 16GB of RAM these days.

Second, the S3 backup, or some other backup mechanism would be nice on the standard version. It's not as if Standard SQL Server doesn't have backup capability.

I'm curious to know what the Enterprise cost is going to look like as well. For our uses, we'd be on the fence as to which version.

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 2:13:46 AM2/25/12
to rav...@googlegroups.com
inline

On Fri, Feb 24, 2012 at 11:01 PM, Federico Lois <fe...@corvalius.com> wrote:

Already there, actually.
 
So there is a voting mechanism for the slave to become master when master goes online already and switch roles?
 

Not, it is straightforward failover to the next guy in line.
 
 
- Bulk data operations on Raven Studio (delete, query, selection,
etc).

We already do
 
I dont know maybe then I couldnt discover it, finding specific documents and then operate on them in bulk.  

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 2:15:53 AM2/25/12
to rav...@googlegroups.com
Brian,
The Standard edition already have both full and incremental backup support.
The Enterprise edition will merely add support for backing up to S3 as well.

I haven't decided yet on pricing, but I would like to solicit suggestions.

And yes,the Std will run on servers with higher capacity, but will only utilize so much of their resources.

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 3:39:31 AM2/25/12
to rav...@googlegroups.com
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

Sean Kearon

unread,
Feb 25, 2012, 4:52:46 AM2/25/12
to ravendb
"We will still offer the OEM model for embedded instances, which would
be 1,599$ per developer per year."

So, that's a 600$ increase to the current pricing? I have been
wanting to use RavenDB for a while now in an embedded desktop
scenario, but have struggled to justify the cost. I was hoping to
find RavenDB more affordable for this scenario when reading this
thread.

Later, you say: "I have little problem with offering RavenDB Basic, at
a reduce cost with reduced features, but I am not sure what those
would be. "

For a "desktop edition", could restricting to localhost for the HTTP
API be a sensible option? For me, cost is my only barrier to adopting
RavenDB.

Justin A

unread,
Feb 25, 2012, 5:19:43 AM2/25/12
to rav...@googlegroups.com
Ayende, 

OSS is still free? If i have a website using RavenDb and the sourcecode is up on github or somewhere .. no license required?

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 5:30:22 AM2/25/12
to rav...@googlegroups.com
Yes, OSS can still use everything for free

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 5:31:40 AM2/25/12
to rav...@googlegroups.com
Inline


On Saturday, February 25, 2012, Sean Kearon wrote:
"We will still offer the OEM model for embedded instances, which would
be 1,599$ per developer per year."

So, that's a 600$ increase to the current pricing?  I have been
wanting to use RavenDB for a while now in an embedded desktop
scenario, but have struggled to justify the cost.  I was hoping to
find RavenDB more affordable for this scenario when reading this
thread.

You have the option of purchasing now, and keeping the current pricing 

Later, you say: "I have little problem with offering RavenDB Basic, at
a reduce cost with reduced features, but I am not sure what those
would be. "

For a "desktop edition", could restricting to localhost for the HTTP
API be a sensible option?  For me, cost is my only barrier to adopting
RavenDB.

That is actually quite a good idea, thanks for that 

Tobi

unread,
Feb 25, 2012, 6:32:24 AM2/25/12
to rav...@googlegroups.com
On 25.02.2012 11:31, Oren Eini (Ayende Rahien) wrote:

> For a "desktop edition", could restricting to localhost for the HTTP
> API be a sensible option? For me, cost is my only barrier to adopting
> RavenDB.
>
>
> That is actually quite a good idea, thanks for that

I rarely need this, but I really like to be able to have remote access via
Raven.Studio for maintenance purposes.

Tobias

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 8:53:33 AM2/25/12
to rav...@googlegroups.com
Tobi,
I am actually thinking that this would be a great limitation for development mode, to distinguish it from running without any limits. 

Tobi

unread,
Feb 25, 2012, 9:37:54 AM2/25/12
to rav...@googlegroups.com
On 25.02.2012 14:53, Oren Eini (Ayende Rahien) wrote:

> I am actually thinking that this would be a great limitation for
> development mode, to distinguish it from running without any limits.

So you mean development mode = localhost / no limits and production mode =
any host / limited by license?

Tobias

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 9:39:09 AM2/25/12
to rav...@googlegroups.com
Yes.

Sean Kearon

unread,
Feb 25, 2012, 10:37:01 AM2/25/12
to ravendb
>     For a "desktop edition", could restricting to localhost for the HTTP
>     API be a sensible option?  For me, cost is my only barrier to adopting
>     RavenDB.
> That is actually quite a good idea, thanks for that

I'd be very interested to hear how your thinking goes with this, Oren.

Sean Kearon

unread,
Feb 25, 2012, 10:37:59 AM2/25/12
to ravendb
...that is, if this could make a lower price edition feasible for you.

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 10:42:41 AM2/25/12
to rav...@googlegroups.com
Sean,
I am actually liking the local mode only for the development edition. So if you don't have a license, it is limited to the local requests only.

For RavenDB Basic? 
That would probably come with a limit to the size of the database.

Sean Kearon

unread,
Feb 25, 2012, 11:00:56 AM2/25/12
to ravendb
Thanks Oren, I'd be very happy with a size limit for my scenario too.
Do you have any idea of pricing and size limits for RavenDB Basic yet?

> Sean,
> I am actually liking the local mode only for the development edition. So if
> you don't have a license, it is limited to the local requests only.
>
> For RavenDB Basic?
> That would probably come with a limit to the size of the database.
>

Oren Eini (Ayende Rahien)

unread,
Feb 25, 2012, 11:01:30 AM2/25/12