Plans for the future (pricing, editions, etc)

[Oren Eini (Ayende Rahien)]

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]

Are those prices all in USD?

[Phil Jones]

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]

This is a very straight forward and fair pricing scheme.

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

[Shaddix]

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

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)]

Yes 

[Oren Eini (Ayende Rahien)]

RavenHQ will likely offer at least some of those features, yes

Of the list, what do you want there?

[Oren Eini (Ayende Rahien)]

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]

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)]

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)]

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]

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)]

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)]

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)]

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-someone-a-heart-attack 

And more importantly, this:

http://ayende.com/blog/4308/nhprof-com-downtime-and-using-windows-as-a-server-system 

[Dave Nay]

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)]

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]

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)]

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]

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]

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)]

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.

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. 

[Chris Marisic]

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]

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]

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

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)]

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)]

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)]

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]

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]

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]

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)]

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]

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]

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]

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]

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)]

What part is there about making a profit?

[Oren Eini (Ayende Rahien)]

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)]

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)]

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]

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]

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)]

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.  

See http://ayende.com/blog/4535/set-based-operations-with-ravendb

[Oren Eini (Ayende Rahien)]

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)]

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]

"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]

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)]

Yes, OSS can still use everything for free

[Oren Eini (Ayende Rahien)]

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]

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)]

Tobi,

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

[Tobi]

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)]

Yes.

[Sean Kearon]

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

...that is, if this could make a lower price edition feasible for you.

[Oren Eini (Ayende Rahien)]

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]

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)]

Sean,

Absolutely no idea.

Make me an offer, we'll see.

[Sean Kearon]

How about this?

------------ --------------------------------
Storage First Year/Additional Year (USD)
------------ --------------------------------
0 - 100MB 100/100
100MB - 1GB 250/150
1GB - 10GB 550/300
unlimited 1600/550
------------ --------------------------------

Presume that the limits would be "hard" here - no space, no save!!

Also, just caught you mentioned a "development edition". Presume this
a paid-for licence that allows development on a commercial product?
That is attractive for my scenario too (lone developer but pays others
from time to time). If so, any pricing yet?

> Sean,
> Absolutely no idea.
> Make me an offer, we'll see.
>

[Itamar Syn-Hershko]

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

That is HTTPS, obviously, which we currently do not support when running in service mode

 

[Oren Eini (Ayende Rahien)]

That is really not that different in pricing, and it doesn't seems to make a lot of sense.

I can't think of a useful scenario where I would want to buy one of those editions, to be fair.

It is more effective to pay for the subscription than even the second level. And the first level is pretty useless.

[Sean Kearon]

Okay, let's take some levels out:

------------           --------------------------------
Storage            First Year/Additional Year (USD)
------------           --------------------------------

0 - 1GB     250/150

1GB - 10GB      550/300
unlimited          1600/550
------------           --------------------------------

Maybe most of your customers are web devs and hence multi-client
access to the db. I'm on the _desktop_ here and I want Raven because
of the lovely, sweet, fluid POCO-to-store-and-back-via-LINQ that
RavenDB provides (did I mention lovely and sweet there?!?!?! - I want
this for the benefits it provides me, the developer, my customers
don't care (as long as it works well, of course)). I really don't
want to mess around with an ORM. Raven will save me time, reduce my
current effort and future pain and make it easier to deliver. That is
why I want to use Raven.

However, for my desktop scenario the price is far too high. I can
serialise my aggregate to JSON then route it to a BLOB easily and
efficiently, adding some metadata against it along the way for a few
hours of extra effort in a desktop db like CE 4. I can go on a very
nice little holiday for the 1600USD I have just saved! There is a
load of extra value that Raven delivers for me over this scenario, but
1600USD is not a desktop DB price!

Maybe that's not your target audience though, which is fine.

Continuing, because I am embedded - desktop or server - let's take out
http API access other than at localhost. Why would anyone need this
in an embedded scenario? They won't! It's a significantly higher
value feature that simply does not apply. Ship it in your higher
value SKUs and charge more for it!

On Feb 25, 7:47 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> That is really not that different in pricing, and it doesn't seems to make
> a lot of sense.
> I can't think of a useful scenario where I would want to buy one of those
> editions, to be fair.
> It is more effective to pay for the subscription than even the second
> level. And the first level is pretty useless.
>

[Beyers]

Oren,

On Feb 24, 5:48 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> 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.

Surely you can admit that this is fairly extreme and not a common
scenario. My biggest concern about not offering an "Express" edition
is that it will severely hamper the uptake of new developers using/
trying out Raven. I think the spirit of an Express edition (Sql
Express or whatever product) is to get developers using the product,
getting them "hooked" as Phil Jones put it. This can only be a good
thing for your business, especially seeing Raven is still a fairly new
kid on the block. I believe this would lead to a much higher
conversion rate to the paid version. I strongly believe many
developers as dismissing RavenDB as an option at this stage due to the
lack of an Express edition.

A typical scenario, many developers I know (myself included) are
moonlighting with personal projects, toying with ideas, throwing them
on the web and see which ones stick. For the ones that stick I would
have absolutely no problem paying for the Standard or Enterprise
version, but just cant justify the costs for all the other projects
that will never make a profit.

Put a low limit on storage with an Express edition, 50MB or 100MB
should be enough to filter out project failures. I think this is where
RavenHQ is doing it right with their Bronze free version.

You've referred a couple of times to industry practices around the
paid editions, which is fair and I agree. But industry practice is
also to have an Express edition (SQL Express, Oracle Express, etc).

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

If you are still against an Express version, a RavenDB Basic version
that has the same features than the Standard edition but with storage
limits would be the logical choice.

Oren, apart from the fact that I believe you need an Express version,
I think the pricing on the Standard version and the feature sets you
proposed for the Enterprise and Scaleout editions are all reasonable.

Beyers

[Grant]

My hopelessly biased $0.02...

The Standard scenario didn't seem too far out of bounds. With an imputed spread of maybe 8-10X (roughly the spread between MSSQL Standard and Enterprise street pricing), the price-value relationship in the Enterprise scenario doesn't seem as reasonable. The reality is the percentage of MSSQL licences that get sold at street prices is pretty small, and EA pricing looks significantly different. This may not be relevant, since I'm not sure the typical customer for RavenDB Enterprise is a large corporation.

My bigger concern is that pricing and license needs to remain adoption-aware or adoption sensitive. I work with mostly F500 IT customers. As we progress and develop more comfort at our firm with using and recommending RavenDB to our customers, I can tell you it will be an uphill battle to get Raven adopted due to the newness of NoSQL and RavenDB not being as well known as the usual suspects. 

No disrespect in the least... corporate IT is generally slow to react. There will be people who see the light sooner, but you should also focus on pricing for _production_ licenses for the non-embedded versions. I would expect a number of customers where the technology needs to under go a technical proof before it can be ratified and purchased. If there's always an OSS version that can be used to accomplish this or a basic license, I think that can work. 

The plus side is I rarely if ever see real corporations shirk on paying their licenses. Your datapoint around sharding on SQL Express is amusing, but honestly, people willing to go to that level are going to be running bootleg copies otherwise. Focus on succeeded with the segment of the market that's legit -- it's excessively large.

I think you have a good product here--my immediate reaction was that dialing up pricing to look more like established enterprise stacks might be more profitable on a per-unit basis, but create incremental adoption friction.

On Friday, February 24, 2012 4:02:49 AM UTC-5, Ayende Rahien 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 Friday, February 24, 2012 4:02:49 AM UTC-5, Ayende Rahien 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.

[Nathan Reid]

Limiting to localhost for a "desktop" edition that makes sense, but
not for a development version. Personally, I think it makes sense for
it to be free for development - after all, you want people to check it
out, realize how awesome it is, and then convince their company to buy
it, right? For me and my coworkers, part of that requires being able
to test RavenDB's performance on our servers while doing development
from our PCs.
All the companies I've worked for have been very big about following
license agreements. They may grumble about prices, but they still do
it.


On Feb 25, 10:42 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> 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)]

Sean,

I am following your logic, and I agree that the pricing make no sense. But it isn't our pricing, it is yours.

Under our pricing, we are talking about 399$ for the unlimited plan, which is a forth of what you want me to charge you.

If you'll insist, I'll be happy to take your money, but I don't think that this is going to be the general policy.

Also, note that for desktop scenarios, we are licensing not by instance, but by developer. There isn't a per instance cost.

[Oren Eini (Ayende Rahien)]

Beyers,

I think that the Express need is served by being able to download and play with the bits at no charge.

As for Basic pricing. How about we do something like:

For basic, we offer subscription only mode, 5$ / month for 512 MB limit or 10$ / month for 1 GB limit?

[Oren Eini (Ayende Rahien)]

Grant,

One of the reasons for the price change is specifically targeting larger clients. I had to field questions about pricing being too low, actually. And about the product viability at that price range.

As you noted, the major problems in adoption relates to the product reputation and age, not to its price point. 

> you should also focus on pricing for _production_ licenses for the non-embedded versions

I don't understand this statement, I am afraid. Can you explain what you mean here? I thought I was focusing on that.

Note that there is always going to be an OSS version that you can use.

Regarding Enterprise pricing. You are actually the first one to bring it up, which I find interesting :-)

I explicitly didn't even tried to pencil in a figure for Ent pricing. Can you give a suggestions?

[Sean Kearon]

> Under our pricing, we are talking about 399$ for the unlimited plan, which
> is a forth of what you want me to charge you.

Hmm, I must be missing something then. I thought the pricing for
embedded was going to _rise_ from the current $999/550 to $1600/?.
$399 for embedded with unlimited storage is an absolute no-brainer as
far as I'm concerned - when can I sign up?

On Feb 26, 7:44 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> Sean,
> I am following your logic, and I agree that the pricing make no sense. But

> it isn't *our* pricing, it is yours.

> Under our pricing, we are talking about 399$ for the unlimited plan, which
> is a forth of what you want me to charge you.
> If you'll insist, I'll be happy to take your money, but I don't think that
> this is going to be the general policy.
>
> Also, note that for desktop scenarios, we are licensing not by instance,

> but by *developer*. There isn't a per instance cost.

[Oren Eini (Ayende Rahien)]

Oh, now I see where we got confused, I was talking about the non oem version

What you are saying is that you want a reduced price own version, with the size limit?

[Phil Jones]

RE: some people saying limit connections from localhost

Currently we have 1 instance (per month payment) deployed to a VPS.
Connections from localhost ONLY are allowed.

I don't know if its a strange setup but the reasoning why is sys ops
people I've spoke with in the past say that you shouldn't expose a
database server to external connections. only exception is through a
VPN they said.

I can see in an enterprise environment where you would want this, say
your database server and web server where two separate machines but
its not an issue when running in a VPS/single machine environment in
which I imagine Standard license would do fine.

On Feb 26, 10:03 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>

wrote:
> Oh, now I see where we got confused, I was talking about the non oem version
>
> What you are saying is that you want a reduced price own version, with the
> size limit?
>
>
>
>
>
>
>
> On Sunday, February 26, 2012, Sean Kearon wrote:
> > > Under our pricing, we are talking about 399$ for the unlimited plan,
> > which
> > > is a forth of what you want me to charge you.
>
> > Hmm, I must be missing something then.  I thought the pricing for
> > embedded was going to _rise_ from the current $999/550 to $1600/?.
> > $399 for embedded with unlimited storage is an absolute no-brainer as
> > far as I'm concerned - when can I sign up?
>

> > On Feb 26, 7:44 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com<javascript:;>

>
> > wrote:
> > > Sean,
> > > I am following your logic, and I agree that the pricing make no sense.
> > But
> > > it isn't *our* pricing, it is yours.
> > > Under our pricing, we are talking about 399$ for the unlimited plan,
> > which
> > > is a forth of what you want me to charge you.
> > > If you'll insist, I'll be happy to take your money, but I don't think
> > that
> > > this is going to be the general policy.
>
> > > Also, note that for desktop scenarios, we are licensing not by instance,
> > > but by *developer*. There isn't a per instance cost.
>
> > > On Sat, Feb 25, 2012 at 11:57 PM, Sean Kearon <

> > kearon.s...@googlemail.com <javascript:;>>wrote:

[Oren Eini (Ayende Rahien)]

This limitation isn't for the standard, it is meant for dev mode

[Phil Jones]

Interesting, I need to read back on what "dev mode" is, I presume
something like SQL Server Developer Edition, Enterprise features cheap
for developers to play with locally.

Perhaps I've been developing illegally then. I've spent the last few
months developing actual commercial code, which wasn't deployed
publicly or only deployed for clients to test and not properly use. I
only last week bought a license last week when it was opened to the
public and the client has started using it properly.

Yikes. Have I got confused between "private non commercial
development" and "private commercial development", if so, I apologise
and email me and we can sort out payment for the months I've been
developing commercial stuff without a proper license.

Something interesting with my deployment was the lack of prompting for
a license key, currently I could see some people running RavenDB in
production without ever bothering to buy a license.

My ideal tiers

Express:
Local ip only limit
1GB RAM limit
10GB database size limit
No sharding
No replication
Price = $0-$10

Standard:
12GB RAM limit
1TB database size limit

Enterprise:
Whatever really, I don't have much experience of this world


On Feb 26, 2:56 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> This limitation isn't for the standard, it is meant for dev mode
>
>
>
>
>
>
>
> On Sunday, February 26, 2012, Phil Jones wrote:
> > RE: some people saying limit connections from localhost
>
> > Currently we have 1 instance (per month payment) deployed to a VPS.
> > Connections from localhost ONLY are allowed.
>
> > I don't know if its a strange setup but the reasoning why is sys ops
> > people I've spoke with in the past say that you shouldn't expose a
> > database server to external connections. only exception is through a
> > VPN they said.
>
> > I can see in an enterprise environment where you would want this, say
> > your database server and web server where two separate machines but
> > its not an issue when running in a VPS/single machine environment in
> > which I imagine Standard license would do fine.
>

> > On Feb 26, 10:03 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com<javascript:;>

> > > > kearon.s...@googlemail.com <javascript:;> <javascript:;>>wrote:

[Oren Eini (Ayende Rahien)]

inline

On Sun, Feb 26, 2012 at 5:15 PM, Phil Jones <phil.j...@gmail.com> wrote:

Interesting, I need to read back on what "dev mode" is, I presume
something like SQL Server Developer Edition, Enterprise features cheap
for developers to play with locally.

The is the idea, except that the dev mode of RavenDB is free.

 

Perhaps I've been developing illegally then. I've spent the last few
months developing actual commercial code, which wasn't deployed
publicly or only deployed for clients to test and not properly use. I
only last week bought a license last week when it was opened to the
public and the client has started using it properly.

No, you are good.

 

Yikes. Have I got confused between "private non commercial
development" and "private commercial development", if so, I apologise
and email me and we can sort out payment for the months I've been
developing commercial stuff without a proper license.

No, it isn't the case.

 

Something interesting with my deployment was the lack of prompting for
a license key, currently I could see some people running RavenDB in
production without ever bothering to buy a license.

That is mostly the reason why I want to have some obvious limit for that. So they get the "oh, yeah, we need to buy" thought.

[Sean Kearon]

If the price is $399 to deploy embedded, no storage limits, no RAM or
processor restrictions, then I'm very happy with that. I thought the
embedded was increasing from $999 to $1600.

On Feb 26, 10:03 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>

wrote:
> Oh, now I see where we got confused, I was talking about the non oem version
>
> What you are saying is that you want a reduced price own version, with the
> size limit?
>
>
>
>
>
>
>
> On Sunday, February 26, 2012, Sean Kearon wrote:
> > > Under our pricing, we are talking about 399$ for the unlimited plan,
> > which
> > > is a forth of what you want me to charge you.
>
> > Hmm, I must be missing something then.  I thought the pricing for
> > embedded was going to _rise_ from the current $999/550 to $1600/?.
> > $399 for embedded with unlimited storage is an absolute no-brainer as
> > far as I'm concerned - when can I sign up?
>

> > On Feb 26, 7:44 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com<javascript:;>

>
> > wrote:
> > > Sean,
> > > I am following your logic, and I agree that the pricing make no sense.
> > But
> > > it isn't *our* pricing, it is yours.
> > > Under our pricing, we are talking about 399$ for the unlimited plan,
> > which
> > > is a forth of what you want me to charge you.
> > > If you'll insist, I'll be happy to take your money, but I don't think
> > that
> > > this is going to be the general policy.
>
> > > Also, note that for desktop scenarios, we are licensing not by instance,
> > > but by *developer*. There isn't a per instance cost.
>
> > > On Sat, Feb 25, 2012 at 11:57 PM, Sean Kearon <

> > kearon.s...@googlemail.com <javascript:;>>wrote:

[Tobi]

On 26.02.2012 17:05, Sean Kearon wrote:

> If the price is $399 to deploy embedded, no storage limits, no RAM or
> processor restrictions, then I'm very happy with that.

I think 399 ist the price for "RavenDB Standard", which is per instance
(usually as a ServerDB for e.g. a Web-App).

> I thought the
> embedded was increasing from $999 to $1600.

That's the OEM license you pay per developer/year and gives you the right
to deploy any number of instances (OEM-like, meaning embedded, usually for
desktop apps).

Tobias

[Sean Kearon]

My scenario is desktop, not embedded on a server. So, I guess I am
looking at OEM here, which is a shame.

So, we're back to $1600 then? What's the annual renewal? Do I still
need one of these per developer?

[Tobi]

On 26.02.2012 17:46, Sean Kearon wrote:

> My scenario is desktop, not embedded on a server. So, I guess I am
> looking at OEM here, which is a shame.

Yes, OEM would be what you need.

> So, we're back to $1600 then?

That's the new price. I think you can still get it for the old one.

> What's the annual renewal?

For the new pricing scheme it's $1600 as well.

> Do I still need one of these per developer?

I think so.

The new OEM license is indeed pretty high and if I wouldn't already have
an OEM licenses and wouldn't be familiar with RavenDB's benefits yet, I
would really think twice if I would spend $1600/year for this. But right
now I wouldn't want to miss RavenDB anymore :-)

All other 3'rd party products I use, have a lower renewal price, like e.g.
Reports.Net which is $1200 / $400 and which is true for the current
RavenDB pricing as well. I guess it's a good time and go for it now and
get RavenDB for the old price.

Tobias

[Grant]

Agree re: too low of a price point being a hindrance to adoption. I think as long as your +$500 for standard and in the $2-5K range for Enterprise you're priced high enough that people don't confuse you with a guy in a garage, but you're also unlikely to not price yourself out of too many projects (or get bogged down with IT governance or procurement). I don't mean to say you couldn't price higher, I'm just thinking of price points that mean few if any projects can't afford you.

My comment about production licensing relates to scenarios where Raven isn't being used for real (i.e., production), but it's also not part of an OSS or non-commercial project. What I read was: "You can use Raven for free, if your project is Open Source. If you want to use Raven in to build commercial software, you must buy a commercial license."

So I'm assuming you wouldn't be able to use the OSS version, for instance, to build proof of concept in a corporate context to help get Raven adopted therein. Architects and developers will be the ones evangelizing Raven and they don't usually have budgets -- some subset of the developers out there who would want to try and convince their stakeholders Raven's a good addition to their toolkit will get shut down if they have to get non-trivial funding upfront. 

It's all basically back to who will market Raven for you, who is your target audience -- I don't think it's going to be the people in corporate IT who have budget control (and they're heavily invested in relational stacks). They're not the ones who brought in hadoop, redis, couch, etc... but they couldn't stop the developers and teams from doing so because they didn't need their budget dollars. Once the teams can demonstrate the value of a new technology in context, then you can appeal to leadership and the budget gatekeepers have to follow along. 

MDSN is somewhat of a commercial example (in that many firms purchase along with their EAs and they're already on the books or sort of a sunk cost). I can basically build anything in the Microsoft stack (sans a few products) in a development context using MSDN. When I move from dev/test to production, I know I need instance specific licence coverage, but licensing doesn't prevent us from getting the pre-production versions built. To the extent you separate dev use vs. production use (excluding embedded naturally), I think that actually frees you up to price towards the higher end of any price ranges you're evaluating.

Ultimately, I think licensing approaches where you're charging the customer for ongoing value vs. access to your IP create the lowest amount of friction. If you focus on production use vs. development use, you align more closely to the value corporate IT is getting.

[Sean Kearon]

That's a real shame. $999 was too high for me, so $1600 blows it
totally out of the water, especially if that's the renewal price as
well. Even if I was happy with $999 then I'd be looking at £1600 next
year. Plus, if I use another developer then that doubles. That is
far too much for a desktop DB.

The main benefits for me are removing the friction with using an ORM,
which, I can get from JSON serialisation to a SQL CE blob. Sadly, I'm
going to have to walk away.

Thanks for the clarifications Tobias.

[Oren Eini (Ayende Rahien)]

inline

On Sun, Feb 26, 2012 at 6:24 PM, Tobi <lista...@e-tobi.net> wrote:

On 26.02.2012 17:05, Sean Kearon wrote:

> If the price is $399 to deploy embedded, no storage limits, no RAM or
> processor restrictions, then I'm very happy with that.

I think 399 ist the price for "RavenDB Standard", which is per instance
(usually as a ServerDB for e.g. a Web-App).

Yes, that is what I meant.

 

> I thought the
> embedded was increasing from $999 to $1600.

That's the OEM license you pay per developer/year and gives you the right
to deploy any number of instances (OEM-like, meaning embedded, usually for
desktop apps).

Yes. Unless you mean something else when you refer to Desktop applications, those usually goes with OEM licensing.

 

Tobias

[Oren Eini (Ayende Rahien)]

inline

On Sun, Feb 26, 2012 at 7:16 PM, Grant <gr...@scorcho.org> wrote:

Agree re: too low of a price point being a hindrance to adoption. I think as long as your +$500 for standard and in the $2-5K range for Enterprise you're priced high enough that people don't confuse you with a guy in a garage, but you're also unlikely to not price yourself out of too many projects (or get bogged down with IT governance or procurement). I don't mean to say you couldn't price higher, I'm just thinking of price points that mean few if any projects can't afford you.

Considering that the Enterprise licensing is per core. What would you suggest as the base rate? 

 

My comment about production licensing relates to scenarios where Raven isn't being used for real (i.e., production), but it's also not part of an OSS or non-commercial project. What I read was: "You can use Raven for free, if your project is Open Source. If you want to use Raven in to build commercial software, you must buy a commercial license."

Yes, that is pretty much it. 

 

So I'm assuming you wouldn't be able to use the OSS version, for instance, to build proof of concept in a corporate context to help get Raven adopted therein. Architects and developers will be the ones evangelizing Raven and they don't usually have budgets -- some subset of the developers out there who would want to try and convince their stakeholders Raven's a good addition to their toolkit will get shut down if they have to get non-trivial funding upfront. 

POC is something that you most certainly can build using the development exception (you don't need a license to develop).

If you want to go live with it, you would need a license.

 

It's all basically back to who will market Raven for you, who is your target audience -- I don't think it's going to be the people in corporate IT who have budget control (and they're heavily invested in relational stacks). They're not the ones who brought in hadoop, redis, couch, etc... but they couldn't stop the developers and teams from doing so because they didn't need their budget dollars. Once the teams can demonstrate the value of a new technology in context, then you can appeal to leadership and the budget gatekeepers have to follow along. 

Problem is, if you give it for free. How do you get to the point when you can actually make a sale.

 

MDSN is somewhat of a commercial example (in that many firms purchase along with their EAs and they're already on the books or sort of a sunk cost). I can basically build anything in the Microsoft stack (sans a few products) in a development context using MSDN. When I move from dev/test to production, I know I need instance specific licence coverage, but licensing doesn't prevent us from getting the pre-production versions built. To the extent you separate dev use vs. production use (excluding embedded naturally), I think that actually frees you up to price towards the higher end of any price ranges you're evaluating.

That is pretty much how it works with RavenDB as well. You don't need to purchase a license for development.

[Oren Eini (Ayende Rahien)]

inline

On Sun, Feb 26, 2012 at 9:04 PM, Sean Kearon <kearo...@googlemail.com> wrote:

That's a real shame.  $999 was too high for me, so $1600 blows it
totally out of the water, especially if that's the renewal price as
well.  Even if I was happy with $999 then I'd be looking at £1600 next
year.  Plus, if I use another developer then that doubles.  That is
far too much for a desktop DB.

Sean,

a) If you go with 999$ now, you will keep on paying the renewal rate of 549$ as long as you keep the subscription updated.

b) Let us say that you had a OEM edition with limit to 1GB. What is it worth to you?

[Sean Kearon]

> a) If you go with 999$ now, you will *keep on paying *the renewal rate of

> 549$ as long as you keep the subscription updated.

Okay, that's good to know, but $999 is still a barrier.

> b) Let us say that you had a OEM edition with limit to 1GB. What is it
> worth to you?

That is a tricky question at 1GB as we have customers who have that
amount of data, so I know I need more. Let's make it 5GB, in which
case I'd be happy paying something like $550/$300 for that. Just to
be crystal clear, that's a price with a licence per developer in
mind. Lone dev/small shop I can pay for the occasional additional dev
licence on that money.


On Feb 26, 8:25 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> inline

>
> On Sun, Feb 26, 2012 at 9:04 PM, Sean Kearon <kearon.s...@googlemail.com>wrote:
>
> > That's a real shame.  $999 was too high for me, so $1600 blows it
> > totally out of the water, especially if that's the renewal price as
> > well.  Even if I was happy with $999 then I'd be looking at £1600 next
> > year.  Plus, if I use another developer then that doubles.  That is
> > far too much for a desktop DB.
>
> Sean,

> a) If you go with 999$ now, you will *keep on paying *the renewal rate of

[Beyers]

Oren,

> As for Basic pricing. How about we do something like:
> For basic, we offer subscription only mode, 5$ / month for 512 MB limit or
> 10$ / month for 1 GB limit?
>

That would be perfect for many of my projects - moonlight projects and
smaller db driven customer sites. It would give me a nice entry level
subscription with the possibility of upgrading should the project or
customer requirements grow, perfect!
So here's me hoping you guys introduce something like this Basic
edition!

[Grant]

In terms of price per cores.. 4 cores is sort of low-end for new servers now, 10-12 coming this year but that's the fairly high-end stuff. 4 to 8 is probably the reasonable range of the kind of data center hardware and Enterprise on a single server wouldn't be too common, so maybe $400 to $700 per core. a typical first production use at a company could be $3200 to $5600 (figure two 4-core servers). 

This is still good value relative to MSSQL... but you're also not in the hobbyist pricing tier.

http://sqlserverperformance.wordpress.com/2011/11/10/sql-server-2012-licensing-and-hardware-considerations/ 

[fe...@corvalius.com]

Having read most of the thread I will add my two cents on pricing. Coming from a "third world country" I acknowledge the real disparity between a no brainer price to a barrier pricing is somewhat tied to where are u from. The same price in the US may be a no brainer while in other countries is plain outrageous.

For example, 6 years ago having to pay per developer 2 months payment (999) would have been a no-no, luckily here that relationship got better to not dismiss paying for a subscription (we are not using OEM even if it makes sense for our product because of that).

What I wanted to highlight is that there is no way a single/static pricing structure that would work everywhere.

Oren, I think that you are onto something with the startups offers. Have you consider going the extra mile and set a price and then given the target (who is actually using it) provide "discounts" up to a certain amount of licenses? .

So lets say your customer"s revenue is in the less than 10000 USD yearly, it makes no economic sense at all to pay 999 (even 300 is difficult to justify). If the revenue is less than 100000 USD it is debatable, but over 5000000 USD well it actually makes sense to pay the full price.

The high end sees a cost they are willing to pay, while the low end is not punished because of their size.

Regards,
Federico
Sent from my Blackberry

[Mauro Servienti]

guys,

I've lost the whole thread but I'm really interested in pricing policies, a small recap of the current state of the art would be really appreciated :-)

.m
_____________________
it's all about trust...

---

From: fe...@corvalius.com
Sent: 27/02/2012 00:33
To: rav...@googlegroups.com
Subject: Re: [RavenDB] Re: Plans for the future (pricing, editions, etc)

[Oren Eini (Ayende Rahien)]

Thanks, we will consider that very carefully.

[Oren Eini (Ayende Rahien)]

I understand your concern, but there isn't much that we can do about it. 

It is no really possible to do pricing differentiation based on region for software. 

Note that we already give discounts for startups, NFP and small organizations already.

[Chris Marisic]

On Sunday, February 26, 2012 5:31:40 PM UTC-5, Grant wrote:

This is still good value relative to MSSQL... but you're also not in the hobbyist pricing tier.

That caveat you added is silly. RavenDB is not meant to be a "hobbyist" tool, it's meant to be a production ready database. Hobbyists can use raven totally free either only on their local machines for development and learning, or by open sourcing their projects.

[Daniel Lang]

Reading this makes me feel sad, because I believe that this direction will kill raven in the long run. Instead, I want to see raven and hibernating rhinos be successful, because it is such a great product and I feel that you guys just deserve it.

As a business owner, I know that it is very important to be profitable and I can see why you probably want to adjust pricing. Nonetheless I think that such an increase in pricing will hurt you more than you will benefit from it. Considering that there are good alternatives like MongoDB, CouchDB and even MSSQL Express, I don't think raven provides enough value on top of them to justify the price.

Especially the OEM pricing feels way to high. If I had a team of 4 developers (which is actually the case) and I need a local database for an application that we're selling for 1.650 Euro per license, I need to pay 6.400 USD per year for the oem licenses. Sure, it will only be one developer working constantly on the product, but still I have to buy 4 licenses because the other 3 need to be able to do minor modifications as well. In five years, that is 32.000 USD only for OEM licenses. Man, that's a whole lot of money.

Let's hope that I am wrong and this upcoming increase won't kill raven... By the way, Jeff Atwood has a good post about pricing: http://www.codinghorror.com/blog/2009/08/software-pricing-are-we-doing-it-wrong.html

[Hermano Cabral]

I could not agree more.

[Justin A]

So Daniel and Hermano .. what structures would you suggest, instead?

[Daniel Lang]

Stick with the current pricing scheme or even lower it to get higher adoption

[Oren Eini (Ayende Rahien)]

Daniel,

You do realize that I priced this basically on the same line as most vendors components, right?

The OEM licensing is meant for people who are going to distribute this to their clients. 

As for Atwood's comments, sure, if I thought that I could sell one copy per developer in the world, sustainability, I would probably do that. But compared to the amount of efforts that we are putting into things vs. the number of potential customers, a 1$ price tag isn't going to work.

Note that this thread is explicitly asking about feedback, you said that you don't think that RavenDB worth the pricing. Can you suggest what you think would be worthwhile pricing?

[Oren Eini (Ayende Rahien)]

That is not sustainable, however.

[Daniel Lang]

Oren,

You were asking for feedback and because this is something I do care about, I tried to be honest. Anyway, I didn't want to be mean by saying it's not worth the pricing, so let's go on to a more constructive discussion.

Selling a product is something completely different from selling consultancy, so no matter how many effort and how many nights you've spent building the product, in the end, this is not what customers will pay for. They will compare with other databases and at certain points, they won't even compare because it will be too expensive for them no matter how awesome the product is. In addition to that, I believe you're underestimating the number of potential customers.

Addressing your point about pricing on the same line as most vendor components - there's nothing comparable with Telerik or ReSharper available that is also free. You may argue, that other databases aren't also comparable with raven. That's true and I'm the least to say raven isn't totally awesome, however, in the end it's still a database. You put things in at one time and retrieve it at a later time. Even though it takes much more effort in other document databases and there are a lot of things you can't do with sql-server, most applications don't necessarily need the additional features.

Since you asked for a suggestion for a worthwhile pricing - http://ravendb.net/licensing

Don't take me wrong. I will be happy to pay the licenses, because we're probably power users of raven. However, not everyone is doing the same and I find it dangerous to raise the prices.