Pricing - summary

[Oren Eini (Ayende Rahien)]

Hi guys,

This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe1420dc6/5df1d12137ab4186?)

It is intended merely to summarize our current thinking, and not meant to be binding or final decisions.

RavenDB is being split into three editions.

RavenDB Basic - monthly subscription only (5$ - 512 MB db size limit, 5 databases limit. 10$ - 1GB db size limit, 10 databases limit). A single indexing thread, 2 GB memory limit. 

RavenDB Standard - what we have with RavenDB right now. 6 CPU + 12 GB limit.

999$ for a one time payment - 18 months upgrade protection.

399$ for a yearly subscription - as long as you have a current subscription, you can use the software and get free upgrades.

39$ for a monthly subscription

RavenDB Enterprise - per core licensing. No limits on CPU / Mem. Additional features, detailed in the previous email.

Per core pricing (# of cores == Environment.ProcessCount) is 699$ per core - 18 months upgrade protection.

299$ per core per year

79$ per core per quarter 

In addition to that we have two additional licensing modes.

OEM - embedded only - 1599$ per developer for the first year.

999$ per developer for renewal.

Scaleout - bundles of 10, 20 and 50 licenses for scaleout / sharding scenarios, which are sold at a reduced cost.

Development will continue to be free.

[Matt Johnson]

I'm developing a product that will be sold to others.  If I go with RavenDB, then it seems my choices are:
A) Go with the embedded product for the OEM license.
B) Require my customers to purchase their own server license.

There is no option to distribute the server edition?  Maybe through a reseller or ISV program?

Also -  Let's say I have two people developing the product today, so I buy two developer oem licenses and start selling my product. Next month I hire another developer to help out.  I have to go back and buy more licences?  What if he's only there for a short-term contract?

I do like the per-developer model in that larger software houses pay more for the product than smaller ones, but it needs to be qualified in some way.  What type of developers do I count?  Any working on my product that uses raven?  Or just those working on the raven-related pieces?  Does my build server need it's own license?

Some of these things will have to be flushed out before we can make a decision about using Raven or not.  It's not really a matter of what the price is (within reason) - it's more about the licensing model.

Keep up the great work!

Thanks,
Matt

[Oren Eini (Ayende Rahien)]

Matt,

Build server doesn't need a license.

For the rest of your questions, I don't know.

Can you suggest what you think would be reasonable answers from your point of view?

[njy]

Thanks for the update Oren, appreciated.




On a related note, may i give you guys a hint on the general issue of
"pricing/licensing"?








Looking at the vfx field (yep: cg explosions, cg humans, cg starships,
that sort of stuff) back some years ago there was this growing trend
for basically all of the 3d software to have divverent version (basic,
pro, banana... you get the point) just like microsoft office basic,
home, deluxe, super duper and whatnot.
On top of that, since to render projects bigger than a flea you would
need some render slaves to crunch frames over frames of your precious
animation, you would have been forced having to pay for some render
nodes, and each pc that you would like to use as a render node needed
it's own license. Then they changed to a license for each cpu, then
for each core. Oh, but there were issues about logical cores vs
physical cores and all of that stuff.
We are talking about licenses of, like, 10.000 $ for each main
license, plus additional licenses and dollars for each render slave.
Oh, and some of those software were available on multiple platforms,
linux, mac and win. And each of them should have a different license.




Right or not that it was, that was the scenario, and users were
stressed out by that situation.




Then, one day in 2004, some very talented and experienced guys left
Newtek (makers of the old and famous Lightwave 3d) and founded a new
company - called Luxology - and released this very very new and
radically different 3d software: it was called "modo".
Everything felt fresh and new, because there was this new software,
with new concepts, being incredibly cool, and was very well written,
enormously innovative and oh boy, it was *fast*.
Oh, and of top of that, they even made a big jump on the pricing/
licensing story: they had only 1 version of the software, with
everything in it. They have only 1 price: 899 $ (if i remember
correctly the price back then), and they give you this "modo" software
in 2 different versions (mac and pc), at the same time! Because, you
know, they say "you can use it on both the PC and Mac as we license
the software to you, not your computer". And the license would last
forever, it was not time-bombed. When a next major release woul came
out, there was a classic full-price/upgrade difference, but that was
all. Oh, and you could use an unlimited number of render nodes, all
for 899 $.
So it was new, fresh and easy... even on pricing/licensing!




Today, some years later, they got a big slice of market share, they
are still alive, they are loved by their customers and evangelize for
free by their users (Apple anyone?). The pricing/licensing strategy
worked out great, and everybody is happy now.








Now, jumping back to you guys: i'm not saying your strategy is wrong,
i'm not saying 4 versions with different usage restictions for cores/
cpus/ram/etc is plain wrong or something, i'm not saying the price is
too low or too high. Obviously there are differences, for example your
sw is OSS, their is not, and so on.




What i'm saying is i admire RavenDB and yo guys, and i would like you
to succeed, and the story up here strikes a lot of similarities to
your story and the story of ravendb: new concepts, a fresh approach,
users loving your work, using it happily and so on.
And since their way of licensing worked out great and gave a relief to
their users from the pain of "software version X pro, 2 virtual cores,
but not more than XYZ MB of ram but..." and it worked uot, i'm just
here asking you to take a look at their path to maybe find some
analogies or ideas, because btw in the economics of the software that
should be considered part of the marketing strategy. And for them, it
worked very well!




Anyway here is the current licensing page for modo, take a look:
http://www.luxology.com/store/modo/index.aspx (now they have 4
version: individual, floating, bulk and educational, plus a couple o
very minor variations).
And here for an intro to how cool is for their uses this licensing
model http://blog.irisproservices.com/2009/01/02/network-rendering-in-modo/
.




I hope this may give you some ideas, thanks for your time.




  njy



On Feb 29, 12:04 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:
> Hi guys,
> This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe...
> )

[Tobi]

My 2 cent on the new pricing / licensing proposal:

OEM: Good to see the renewal price beeing lower than the full price again.
Although I'm glad to already have an OEM license for the old price. The
new one still feels (!) a little bit high. For 1599/999 it would be the
most expensive thing in my toolbox. As a "long-time RavenDB user", I know
that it's worth the money but as a new user, 1599 makes the decision a
little bit harder.

To Matt's question about the per/developer licenses: There's no sane way
to technically ensure/verify this. Oren simply has to trust it's
customers. Personally, if I would e.g. hire someone for a month to help me
out on the GUI, I wouldn't care about buying another RavenDB license. For
a developer that joins the project for a longer term I would.

Maybe it would be a good idea to extend the OEM license to:
1599 for the first developer and 999 for each additional developer,
renewal for 999 per developer per year?

Basic/Standard/Enterprise: These mainly target the Web-App business. I
must say, that I don't have very much experience in this area. Whenever I
need to do a tiny Web-App, I usually build this with Rails and put it on a
Linux-box. Anyways: The licensing model is somehow "complicated", which
kinda makes this contrary to what RavenDB technically stands for. Limiting
the database to only use some cores/threads/memory/disk-space seems kinda
odd to me. Why not just limit the number of docs and the use of things
like sharding or replication?

Besides all this, one thing that maybe isn't really promoted enough:
Whatever license you buy - you get RavenDB with the full source code!
Even better: You have to pay NOTHING to get RavenDB without any
restriction and with the full source code, because it's Open Source!
You can play around with RavenDB, build a test spike, create a demo app
for your boss without spending a single dime!

Tobias

[Mauro Servienti]

+1
Kudos to you for the deep, accurate and interesting, really interesting analysis.

.m

  njy

http://www.Taglocity.com Tags: RavenDB

[Phil Jones]

My current work would fall under basic/standard so here are my
thoughts:

"RavenDB Basic - monthly subscription only (5$ - 512 MB db size limit,
5
databases limit. 10$ - 1GB db size limit, 10 databases limit). A
single
indexing thread, 2 GB memory limit."

This seems pretty fair actually. The client this interests me most
with is Escape Trips (the one you blogged about). Their database is
only ~300MB in size and I currently bought the $25 subscription. I
could save $20 a month. This works good for super small clients, as
the VPS for Escape Trips is: 2GB RAM, 1 virtual core. Although the one
indexing thread is a little bit disappointing.

"RavenDB Standard - what we have with RavenDB right now. 6 CPU + 12 GB
limit.
999$ for a one time payment - 18 months upgrade protection.
399$ for a yearly subscription - as long as you have a current
subscription, you can use the software and get free upgrades.
39$ for a monthly subscription"

This is fine to be honest. Clients at this scale with me are already
looking at moving from SQL Server Express to Standard so the costs are
good in comparison.

P.s. I did mention to Itamar that RavenHQ should have a $5 per month
package as bronze and the free 20mb should just be called free.

[Oren Eini (Ayende Rahien)]

Njy,

A simplified licensing story makes my life simple as well, trust me on that.

I would much rather be focused on optimizing the indexing code than thinking about pricing strategies.

That said, there is a reason why we do those licensing break downs. We are trying to offer the best balance between feature and price for people.

[Oren Eini (Ayende Rahien)]

One of the things that I have been discussing with customers lately is actually non embedded redist scenarios.

That is, the ability to have an application that uses RavenDB to also deploy a RavenDB instance(s).

This seems to be about as common as wanting a fully embeddable solution.

Thoughts about that? Maybe we can do two levels of OEM here.

One that is cheap around the embedded only mode.

One that is more expensive around the server option as well.

[Tobi]

On 29.02.2012 11:03, Oren Eini (Ayende Rahien) wrote:

> Thoughts about that? Maybe we can do two levels of OEM here.
> One that is cheap around the embedded only mode.
> One that is more expensive around the server option as well.

OEM/embedded + OEM/server - Sounds good to me. Maybe with an option to
extend/upgrade from embedded to server. Right now I'm happy with the
embedded RavenDB, but I can imagine scenarios where a central RavenDB
server + a bunch of rich client apps would make sense. Even an
OEM/embedded for a local database + a central database for stock tracking,
managing discount coupons and so on would be a possible scenario.

Another thing I mentioned previously: Even with OEM/embedded I would like
to be able to have remote access via Raven.Studio. This can be really
helpful for maintenance.

And another question: Right now my application is purely standalone. In
the future I need to somehow connect these applications. (e.g. starting a
sale on one cash register, closing it on another). One way to do this
might be master/master replication. Would this still be covered by the
OEM/embedded license?

Tobias

[Dody Gunawinata]

I am trying to match the usage of RavenDB with the licensing options

- Open Source Project of any type: Free
- Development Work: Free
- Hobby Close Source Project: RavenDB Basic, RavenDB Standard
- One off Small/Commercial Application/Website: RavenDB Basic
- Enterprise Market ISV (Server App): OEM/Server, OEM/Embedded
- Consumer ISV: OEM/Embedded
- SaaS ISV: RavenDB Enterprise, Scale Out Option
- IT Department: RavenDB Standard, RavenDB Enterprise, Scale Out Option

--
nomadlife.org

[Oren Eini (Ayende Rahien)]

inline

On Wed, Feb 29, 2012 at 12:30 PM, Tobi <lista...@e-tobi.net> wrote:

On 29.02.2012 11:03, Oren Eini (Ayende Rahien) wrote:

> Thoughts about that? Maybe we can do two levels of OEM here.
> One that is cheap around the embedded only mode.
> One that is more expensive around the server option as well.

OEM/embedded + OEM/server - Sounds good to me. Maybe with an option to
extend/upgrade from embedded to server. Right now I'm happy with the
embedded RavenDB, but I can imagine scenarios where a central RavenDB
server +  a bunch of rich client apps would make sense. Even an
OEM/embedded for a local database + a central database for stock tracking,
managing discount coupons and so on would be a possible scenario.

Yes, that is exactly the common scenario that I keep hearing about.

 

Another thing I mentioned previously: Even with OEM/embedded I would like
to be able to have remote access via Raven.Studio. This can be really
helpful for maintenance.

That is possible, even under the current license. 

 

And another question: Right now my application is purely standalone. In
the future I need to somehow connect these applications. (e.g. starting a
sale on one cash register, closing it on another). One way to do this
might be master/master replication. Would this still be covered by the
OEM/embedded license?

Yes, master/master replication is covered, but you have to be careful about conflicts.

 

Tobias

[Oren Eini (Ayende Rahien)]

Yes, this looks good.

[Chris Marisic]

On Tuesday, February 28, 2012 7:15:52 PM UTC-5, Matt Johnson wrote:

 What type of developers do I count?  Any working on my product that uses raven?  Or just those working on the raven-related pieces?  Does my build server need it's own license?

The one and only acceptable answer is the number of developers who will develop and touch RavenDB usage. Because honestly, any other answer doesn't matter. If I buy software with a per developer licensing I don't care if it says I need every developer licensed that works on the project I will only license the number of developers who are actually working with said software. My view is a license that requires that stipulation would not be able to actually enforce that provision because it's just not right.

It would be like a car maker selling a car that instead of you owning the car, you had to license each driver of the car, but not only the drivers but every single passenger that could ever get in the car which is just absurd. Licensing drivers of a vehicle = ok, licensing passengers of a vehicle = no way.

[Chris Marisic]

On Wednesday, February 29, 2012 4:53:25 AM UTC-5, Phil Jones wrote:

Although the one indexing thread is a little bit disappointing.

One indexing thread does seem to be a very arbitrary limitation, if you really  want the threading to be a higher tier feature, i would think you'd probably want to cover atleast 2 or 4 threads. RavenDB Basic shouldn't have performance outright crippled. Limiting the size the database and the consumption of resources is all very standard for database pricing methods but I've never seen anyone ever majorly reduce the performance intentionally before.

[Sean Kearon]

- Development Work: Free 

So, if I have an embedded licence I can use another developer without buying another licence for them as long as I'm shipping as OEM?

[Oren Eini (Ayende Rahien)]

No, that sort of kills the idea of paying per developer.

[Sean Kearon]

Thanks, that's what I had thought! :)

[Sean Kearon]

Thoughts about that? Maybe we can do two levels of OEM here.

One that is cheap around the embedded only mode.

One that is more expensive around the server option as well.

 

+1 - sounds perfect for my scenario, and I expect for many others too.

[njy]

Oren, yes i imagined that was the reason :)

Sorry if it seemed like i was saying you guys made up a pricing strategy without thinking about it, it was not my intent, and sincerely i don't have an answer as to how model that strategy or if one is wrong or not. But since the modo story and your strikes in me some similarities, and they have been able to come up with something clean and simple on that side too, i was suggesting you to take a look there, because it may be an inspiration for you. Oh, and btw Brad Peebler (The Man, inside Luxology) and he's a very nice and gentle man, so contacting him may give you an idea, even because ravendb's and modo's markets are not crossing in any way.

Sorry if i was misinterpreted, suggesting you guys didn't think about the issue, it was not my intent.

Cheers,

  njy

On Wednesday, February 29, 2012 10:58:39 AM UTC+1, Oren Eini wrote:

Njy,

A simplified licensing story makes my life simple as well, trust me on that.

I would much rather be focused on optimizing the indexing code than thinking about pricing strategies.

That said, there is a reason why we do those licensing break downs. We are trying to offer the best balance between feature and price for people.

On Wed, Feb 29, 2012 at 4:43 AM, njy

Thanks for the update Oren, appreciated.

[Beyers]

I would have to agree with the following:

On Feb 29, 3:51 pm, Chris Marisic <ch...@marisic.com> wrote:
> On Wednesday, February 29, 2012 4:53:25 AM UTC-5, Phil Jones wrote:
>
> > Although the one indexing thread is a little bit disappointing.
>

> One indexing thread does seem to be a very arbitrary limitation, if you *
> really*  want the threading to be a higher tier feature, i would think

> you'd probably want to cover atleast 2 or 4 threads. RavenDB Basic
> shouldn't have performance outright crippled. Limiting the size the
> database and the consumption of resources is all very standard for database
> pricing methods but I've never seen anyone ever majorly reduce the
> performance intentionally before.

Limiting the db size should be enough in my opinion. You might end up
with users thinking RavenDB performance is slow in general and have
them move to something else.

Beyers

[Matt Johnson]

As others have pointed out, I would expect that in a per-developer licensing that I would only pay for developers that actually need to touch the Raven related pieces.  If I have a team of 5, and 3 guys are doing front-end stuff and two are doing back-end, then I would expect to purchase two developer licenses.  I would still expect the entire solution to compile for all 5 of them.

 

I agree that these kinds of licenses can be difficult or impossible to enforce, but I think ultimately they work better than per-instance licensing.  Especially if you are a dependency in someone else’s project.

 

In our case, we are an ISV that is doing both traditional licensed deployments and SaaS hosted models for our product.  We have traditionally used SQL Server, which meant that for hosted we would buy our own servers, and for licensed we would require the customer to have a SQL Server.  I think you can do that for SQL, because many people already have SQL Server licensing agreements with Microsoft, and smaller customers always have the option of SQL Express.

 

If we were to do the same thing with Raven, our customers wouldn’t have the first clue about where to begin.  We would have to provide them their Raven license.  If we had to tell them to go purchase their own Raven license, it would make selling the product very difficult.  Now, if we have royalty free distribution for the embedded product, then it’s not an issue for smaller customers.  But it would be equally important to be able to distribute Raven with our software even with the server edition for larger customers.  Perhaps the license for that is more expensive on our part, or perhaps it’s not “royalty-free”, but we increase the cost of our software by some amount to include the cost of the Raven license.  Either would be acceptable.

 

The big question is how much performance can we expect from the embedded version vs. the server version?  Where do we draw the line from a licensing standpoint?  It would be much easier if this was just a technical question of whether or not you wanted the http layer or the direct connection.  The licensing issue makes it more complicated.

 

The absolute best situation from our perspective would be to have one larger annual fee for the ability to deliver either embedded or full server with our solution, royalty-free.  We would love to pay this fee per-retail-product, rather than per-developer.  Perhaps we could key the raven instance so that it only worked with our software.  That would prevent the end-user from getting a completely free license of Raven.  Perhaps this lines up with your business model, perhaps not.  We would be willing some level of compromise.

 

That would be for the licensed, deployed version of our software.  For our SaaS model, we’d pay separately per instance for our own instances that we use to host the SaaS version.

 

I’m not sure how I feel about the multi-tiered pricing based on number of processors, memory, or disk space.  This always bothered me about SQL Server.  I don’t think Raven should work that way.  If you have a fast machine, why not let Raven take full advantage of it?  Crippleware scares me.  At the same time, you don’t want someone to take one license and run it on 20 machines simultaneously.  For that, they should either have 20 licenses, or a single license that permits up to a number of machines to run it.

 

-Matt

 

[Oren Eini (Ayende Rahien)]

Matt,

Those are all good points. 

With regards to per developer licenses. The way it currently works in my head is that if you have a team of people working on a project using RavenDB, everyone working on the code that runs in the same process as the RavenDB code will need a license.

If you have two separate apps, front end and backend are good examples, the front end guys won't need it.

But if it is all one app, they would.

With regards to technical differences between embedded / server. The sever does some extra management, handles multiple databases and that is about it.

We will have an offering that provide royalty free distribution per project, yes.

As for the per project pricing. That sounds interesting. Can you put a number on that?

[Matt Johnson]

Say that there was an OEM license that we could buy that would give us:
- Choice of embedded or server, mix and match as needed.
- Royalty-free distribution to as few or many end-users as we want.
- No limits in terms of cpu, memory, storage.
- Limited to running with just our product.
- Separate fee paid for each distinct product line (not for subvariants or editions of the same product)

 

We’d probably be looking for a fee of somewhere around $3000 USD for year one, plus $2000 USD per year after as long as we expect major revision updates.

 

If you were looking to secure it, perhaps a product key that goes into both the client and the server with them having to match up so you can’t use a different client with our oem raven server instance.

-Matt

[Matt Johnson]

Sorry for the extra copies of the quoted reply text.  The new google groups web interface is buggy! I'm going back to the old one.

[Phillip Haydon]

OH I'm really glad the subscription pricing has being lowered, it's perfect for my needs to begin with and allows me to slowly move up without bleeding myself dry.

I was freaking out at the $40. I mean if I was working for a company that $40 is heaps cheap, but for personal project it's just way too much.

Happyyy 

Phill

[Roja]

Thought that I would stick my ore in as I am intending to use Raven as
part of a new project. I think that it would be very easy at this
point for Raven to move to a complex licence model but I think that it
would be a massive shame. Raven is aimed at switched on developers &
companies; improved productivity, logical interface, nice
functionality not really enterprise purchasing departments. It's also
meant to be "web scale" and my feeling is that the pricing should
reflect this intention. Develop for free, start cheap, payback on
success. Therefore couldn't we go with something nice, simple and well
defined? i.e. an algorithm?

Here is my proposal (based around and about the price-points you
already intended):

Price is based on "slices" where each slice costs $5 per month, for
which you get the following:

Storage = (#slices^2) GB
Memory = #slices GB
Cores = roundUpNextEven(#slices / 2)

Examples:

1: 2GB, 1GB, 2Cores, $5
2: 4GB, 2GB, 2Cores, $10
5: 32GB, 5GB, 4Cores, $25
10: 1024GB, 10GB, 6Cores, $50

This would remove the need to have "crippled" versions and provides a
nice smooth growth plan for users. I would also allow the allocations
to be split across multiple machines if desired which would promote
making use of sharding & replication.

Roja


On Feb 28, 11:04 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>

[Chris Marisic]

On Thursday, March 1, 2012 4:36:20 PM UTC-5, Oren Eini wrote:

With regards to per developer licenses. The way it currently works in my head is that if you have a team of people working on a project using RavenDB, everyone working on the code that runs in the same process as the RavenDB code will need a license.

That's such a silly an arbitrary delimitation.  What about UX developers that write pure html/css? They would need licensed under that definition. This restriction is also meaningless and arbitrary, all it requires to overcome this is to create the database sit behind a web service and make the client application call the web service. Microsoft even has explicit provisions in the sql server licensing about this, they refer to it as multicasting. You can't buy 1 CAL for sql server then put a web service on top of it and then use the webservice to let infinite users access it. With this being in regards to licensing model per developer, you don't have way to put a multicasting limiter (that wouldn't be absurdly prohibitive).

The only proper requirement is do you touch EVER touch one or more of the following: IDocumentSession, AbstractIndexCreation, Bundles/Triggers,  Management studio, possibly some other facets etc. If they're not touching those, they're not dealing with RavenDB.

[Oren Eini (Ayende Rahien)]

Roja,

Algorithms doesn't work in practice. Something like what you suggest actually end up being very complex to manage from both our end and from the point of view of the customers.

It is very hard to predict things.

[Oren Eini (Ayende Rahien)]

inline

On Fri, Mar 2, 2012 at 7:01 PM, Chris Marisic <ch...@marisic.com> wrote:

On Thursday, March 1, 2012 4:36:20 PM UTC-5, Oren Eini wrote:

With regards to per developer licenses. The way it currently works in my head is that if you have a team of people working on a project using RavenDB, everyone working on the code that runs in the same process as the RavenDB code will need a license.

That's such a silly an arbitrary delimitation.  What about UX developers that write pure html/css? They would need licensed under that definition. This restriction is also meaningless and arbitrary, all it requires to overcome this is to create the database sit behind a web service and make the client application call the web service. Microsoft even has explicit provisions in the sql server licensing about this, they refer to it as multicasting.

So do we

 

You can't buy 1 CAL for sql server then put a web service on top of it and then use the webservice to let infinite users access it. With this being in regards to licensing model per developer, you don't have way to put a multicasting limiter (that wouldn't be absurdly prohibitive).

 

The only proper requirement is do you touch EVER touch one or more of the following: IDocumentSession, AbstractIndexCreation, Bundles/Triggers,  Management studio, possibly some other facets etc. If they're not touching those, they're not dealing with RavenDB.

At which point, they plug an IRepository there and where are we then?

[Matt]

The OEM and development licenses seem to be contradictory.

You say that you must pay $1599 per developer but you also say that for development purposes you need no licence - at what point during development must you buy licences before continuing development?

Could you not remove the developer factor from OEM and instead scale the cost based on number of instances of the software sold?

On Tuesday, February 28, 2012 11:04:49 PM UTC, Oren Eini wrote:

Hi guys,

This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe1420dc6/5df1d12137ab4186?)

[Oren Eini (Ayende Rahien)]

People want royalty free license

[Paul Stovell]

I'm migrating my product (octopusdeploy.com) to RavenDB and I'm just about to buy a license. My application is split into two pieces - a Windows Service and an ASP.NET frontend. Both processes run on the same machine. The only reason they are separate is that I need some scheduled tasks to run in the background, and hosting ASP.NET in a Windows Service isn't fun. 

I don't want to force customers to have to buy a server license, so I'm using the OEM version. Since I have two processes touching the same database, the way I've implemented it is to use the embedded server in the Windows Service, and then to set UseEmbeddedHttpServer and have the ASP.NET frontend connect to the embedded instance over HTTP using the client API. 

I'm still only using the capabilities of the embedded server, so I assumed this was "fair" and within the terms of the OEM license. But reading about the possibility of an OEM/Server version has me second guessing that now. 

Is it within the terms of the OEM/Embedded license to use UseEmbeddedHttpServer and have a second process connect to the embedded instance? And will it still be OK under the new license model? 

I'm all for a re-distributable OEM/Server version so that I can get RavenDB out of my process, I'd just like some clarity. 

Thanks,

Paul

[Oren Eini (Ayende Rahien)]

Paul,

No, embedded means using only within a single process. Not when you have multiple processes. 

There is going to a RavenDB ISV Server version, which will give you the ability to just deploy standard ravendb at the customer site, royalty free.

[Paul Stovell]

What if I buy two Embedded licenses - can I then use two processes? :) Why does the Embedded version even have UseEmbeddedHttpServer if nothing can use it? 

For the sake of keeping my product install ultra simple I'd really like to stick to embedded at first. It looks like I am now faced with hosting ASP.NET within my Windows Service, or modifying my installer to auto-install RavenDB Server, just because of a licensing gap... 

Also, any idea what the ballpark price for RavenDB Server will be? $1,599, $15,999? 

I love RavenDB and I'd love to find a way to make this work without compromising my end user experience. 

Paul

[Chris Marisic]

On Monday, April 23, 2012 1:41:03 PM UTC-4, Paul Stovell wrote:

What if I buy two Embedded licenses - can I then use two processes? :) Why does the Embedded version even have UseEmbeddedHttpServer if nothing can use it? 

I'm pretty sure  UseEmbeddedHttpServer is only so you can connect studio to an Embeddedstore.

[Oren Eini (Ayende Rahien)]

On Mon, Apr 23, 2012 at 8:41 PM, Paul Stovell <goo...@paulstovell.com> wrote:

What if I buy two Embedded licenses - can I then use two processes? :) Why does the Embedded version even have UseEmbeddedHttpServer if nothing can use it? 

LOL, yeah, that can work.

And we have UseEmbeddedHttpServer for debugging, because it provide such good utility in those scenarios.

 

For the sake of keeping my product install ultra simple I'd really like to stick to embedded at first. It looks like I am now faced with hosting ASP.NET within my Windows Service, or modifying my installer to auto-install RavenDB Server, just because of a licensing gap... 

Also, any idea what the ballpark price for RavenDB Server will be? $1,599, $15,999? 

RavenDB ISV Server, probably 2500 - 3000 per dev.

 

But I am willing to sell it to you for $15,999 if you don't mind.

[Vlad K]

We are considering moving our greenfield project to RavenDB (from MS SQL) but in light of this new conversation I have a few questions -

Right now what we were proposing was 2 RavenDB instances running in Window Cluster. We have prototyped the cluster and Raven seems to be running just fine in clustered environment. We just want to make sure that if one server goes down our dbs still run. You mention that Windows Clustering will only be available in Enterprise now? So what we have currently is more than 'new' Standard?

As for enterprise pricing, if it's 699 per core would that mean that if we have 2 quad core cpus with hyper-threading we would have to pay 11184$ per server for raven license? That will smoke even MS SQL server (not even taking into consideration getting it for free with MS partnership agreement). Would we be able to buy 'locked down' enterprise? Like lock it for 1 cpu even on good hardware?

Before, licensing was clear to me, we pay 600$ per server, cluster them and pay it again when time comes to upgrade (or do the yearly thing), now the price just skyrocketed astronomically. Am I missing something?

I really love Raven but as a small company we will probably put a stop to migration if money vs ms sql is even a consideration. One of the reasons I was able to sell NoSQL to the business was it being free (in raven's case affordable) but if it gets to MS SQL territory then there's no chance.

Thanks

[Chris Marisic]

FWIW Microsoft has moved to the per core licensing model for current SQL Server products.

[Oren Eini (Ayende Rahien)]

For Windows Clustering, yes, you would need to get the Enterprise edition. Note that right now clustering on ravendb is not a supported configuration.

Cost for that for 2 quad cores would be 8 x 699 = 5,592$ or 11,184$ total for two servers.

SQL Server licensing for the same thing would be 28,688$ - and you don't get a lot of the stuff that we give (a lot of the SQL Enterprise HA features are actually in our standard package).

So I am not really sure where you got the numbers from.

Yes, you can run Enterprise on limited amount of system resources.

[Vlad K]

SQL Server Standard can still be bought per server for $898 + CALs ($209) and it supports clustering last I checked. Per core license is more expensive than Raven or you can just buy SQL 2008R2 for 'cheap' and use that.

I can see where you are going with pricing, you don't want your competition to be Mongo and Couch, you want it to be SQL Server/Oracle. That's great but as a smaller company with MS Partnership Agreement (free sql server) there just doesn't seem to be any reason to pay that much for Raven.  As much as I love Raven as a dev, it's just not SQL server when it comes to infrastructure (yet).

I am still hoping we can get Raven to be our data store (we've already invested a bunch of dev time into it based on 'old' pricing and running it in a test cluster). Worst case we run some sort of replication and add the 'failover' part to our application instead of windows. 

Thanks.

On Monday, April 23, 2012 11:56:09 PM UTC-4, Oren Eini wrote:

For Windows Clustering, yes, you would need to get the Enterprise edition. Note that right now clustering on ravendb is not a supported configuration.

Cost for that for 2 quad cores would be 8 x 699 = 5,592$ or 11,184$ total for two servers.

SQL Server licensing for the same thing would be 28,688$ - and you don't get a lot of the stuff that we give (a lot of the SQL Enterprise HA features are actually in our standard package).

So I am not really sure where you got the numbers from.

Yes, you can run Enterprise on limited amount of system resources.

[Oren Eini (Ayende Rahien)]

Vlad,

Our pricing structure is aimed at delivering quality at a fair price point. I am not really interested in competing on price.

I am interested in being an awesome database that make it possible for users to build great product without banging their heads against the wall.

[Vlad K]

Absolutely. Hope it works out well.

[Johan Nilsson]

I'm jumping very, very late into this discussion (can't believe I missed it out), but in our case we would probably prefer per-instance.

We are (well, I am) developing software with an embedded server that is very likely to only ever be used in-house by a very small (<10) number of people. We have no plans of selling the software as it is extremely specialized, and even if we would at some point sell it (or, perhaps, give it away) to other entities in our niche the situation would be more or less the same; only a very small number of users - probably still in the tens.

So, I would quite naturally prefer a "royalty-based" license; i.e. per seat, workstation or concurrent usage. I understand that it is hard to manage a large number of different licensing schemes but $1599 initially is money for us and $999 per year will be a significant part of our recurring software license costs. Fortunately I've already purchased the embedded license at $999, but given that the renewal cost will now match that ... well, we will see what happens.

[James Crowley]

Thanks for sharing this Ayende. My main feedback would be that seems to be quite a step up to the Enterprise edition, if you're mainly wanting to use it for the additional features rather than additional cores. If you're using a 6 core RavenDB standard instance - $399/year. The moment you need an enterprise feature (personally, I'm looking at the encryption you mentioned), that jumps to $1794/year? That would be a deal breaker for us at the moment.

J

On 28 February 2012 23:04, Oren Eini (Ayende Rahien) <aye...@ayende.com> wrote:

Hi guys,

This is intended as a summary of the previous thread (http://groups.google.com/group/ravendb/browse_thread/thread/f737cb1fe1420dc6/5df1d12137ab4186?)

It is intended merely to summarize our current thinking, and not meant to be binding or final decisions.

RavenDB is being split into three editions.

RavenDB Basic - monthly subscription only (5$ - 512 MB db size limit, 5 databases limit. 10$ - 1GB db size limit, 10 databases limit). A single indexing thread, 2 GB memory limit. 

RavenDB Standard - what we have with RavenDB right now. 6 CPU + 12 GB limit.

999$ for a one time payment - 18 months upgrade protection.

399$ for a yearly subscription - as long as you have a current subscription, you can use the software and get free upgrades.

39$ for a monthly subscription

RavenDB Enterprise - per core licensing. No limits on CPU / Mem. Additional features, detailed in the previous email.

Per core pricing (# of cores == Environment.ProcessCount) is 699$ per core - 18 months upgrade protection.

299$ per core per year

79$ per core per quarter 

In addition to that we have two additional licensing modes.

OEM - embedded only - 1599$ per developer for the first year.

999$ per developer for renewal.

Scaleout - bundles of 10, 20 and 50 licenses for scaleout / sharding scenarios, which are sold at a reduced cost.

Development will continue to be free.

--

---
James Crowley
CTO, FundApps - a new generation in financial services software - http://www.fundapps.co/ 
Founder, developerFusion - the global developer community - http://www.developerfusion.com/

linkedin: http://linkedin.com/in/jamescrowley
twitter: http://twitter.com/jamescrowley

[Sean Kearon]

I would certainly like to see encryption available in Embedded - even if at additional cost.

[Justin A]

James .. can't u use processor affinity for the raven.server.exe process .. and set it to 1 processor or core, instead of the max? (or how many cores/proc's u want to pay for.. ?)

I've never done it but just thinking out side the square...

[Oren Eini (Ayende Rahien)]

Johan,

You can buy a standard license and run it in an embedded capacity.

[Oren Eini (Ayende Rahien)]

James,

You can buy less CPU than the one you are running on, and we might offer individual enterprise bundles as well.

[Johan Nilsson]

Could you expand on that a bit?

On Wednesday, April 25, 2012 1:58:44 PM UTC+2, Oren Eini wrote:

Johan,

You can buy a standard license and run it in an embedded capacity.

[Oren Eini (Ayende Rahien)]

Standard license basically gives you the ability to run a single instance. That can be a server instance or an embedded instance.

[Hermano Cabral]

What if I want to use a standard licensed server in embedded mode but also accepting connections from other people/processes?

I always thought that the difference between standard and embedded (oem) licenses was that the oem gives you the right to distribute the database royalty free and restricts the usage to the same process.

[Oren Eini (Ayende Rahien)]

Inline

On Wed, Apr 25, 2012 at 5:11 PM, Hermano Cabral <herman...@creactive.com.br> wrote:

What if I want to use a standard licensed server in embedded mode but also accepting connections from other people/processes?

You can do that, as long as you have a license per instance.

Or you use the RavenDB ISV Server license, which allows royalty free distribution

 

I always thought that the difference between standard and embedded (oem) licenses was that the oem gives you the right to distribute the database royalty free and restricts the usage to the same process.

Yes.

[Tom Allard]

Sounds reasonable, however Environment.ProcessorCount includes Hyper Threaded Cores. So a HT quad core would return 8. Number of Cores should be the real amount of cores and not HT-ones since i would not even be able to fully utilize my quad-core server with a standard license. Or make it 8 cores instead of 6.

-Tom

[Oren Eini (Ayende Rahien)]

Sarmaad,

Yes, it will probably be a discounted version of the price, to make up for the difference.

On Fri, Jun 8, 2012 at 5:09 AM, Sarmaad <sar...@gmail.com> wrote:

Hi,

I am not sure if you covered the upgrade path between Embedded OEM to RavenDB Server ISV.

so, if today, I purchased the Embedded OEM version and when the new pricing model become available,

is there going to be an upgrade path from embedded (royalty free) to RavenDB Standard for ISV (royalty free)?

Thanks.