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.