New Licensing Restrictions on RavenDB's Community Edition 👎

[oiBio]

Dear RavenDB Community and Devs,

I must express my deep-seated frustration and disappointment over the recent licensing changes that have been imposed upon RavenDB's Community Edition. As long-time users and ardent supporters, it feels like a slap in the face. Changes that severely limit the usability of the product are not what we expected from you.

For everyone that did not notice the changes yet, you can see them here: https://ravendb.net/buy

5 For Community licenses, the limit is 12 static & 24 auto indexes per database; 60 static & 120 auto indexes per cluster.
8 For Community licenses, the limit is 3 subscriptions per database & 15 subscriptions per cluster. Subscriptions Revisions are not available.
9 For Community licenses, max number of revisions to keep is 2, and max age is 45 days. No default policy can be set up.
10 For Community licenses, frequency cannot be set higher than 36 hours.
11 For Community licenses, the limit is 3 subscriptions & 1 external replication per database; 15 subscriptions & 5 external replications per cluster.
12 For Community licenses, the limit is 1 custom sorter per database & 5 custom sorters per cluster.
13 For Community licenses, the limit is 1 custom analyzer per database & 5 custom analyzers per cluster.

One of the major gripes is the drastic limitation on the number of indexes. For most applications, a dynamic and flexible indexing structure is not a luxury – it's a necessity. This isn't a feature that's just 'nice-to-have'. It's fundamental to the functioning. This indirectly also limits the number of collections per database. What is the use of a collection that I cannot query?

Additionally, the constraints imposed on Revisions and Subscriptions are equally alarming. Many of us, myself included, heavily rely on these features to maintain our systems. By crippling these functionalities, the new Community Edition essentially renders RavenDB useless for a significant fraction of its previous enthusiasts.

Do existing databases stop working once we have to refresh the licence?

I'd also like to emphasize that until now, I've been setting up every new project on RavenDB without hesitation. I've been an enthusiastic advocate, recommending RavenDB to every fellow developer I know. However, with the new limitations in the Community Edition, I not only have to reconsider for new projects but also contemplate how we can migrate our existing projects away from RavenDB. These drastic changes have shaken my foundation of trust and prompted me to question my long-standing support.

I understand that a company has to make profit and there are costs associated with development. However, the route RavenDB is taking feels more like a bait-and-switch tactic. I feel some Unity wipes here... You have crippled the Community Edition into a database that is no longer capable of anything more than proof-of-concept applications.

It is my sincere hope that the RavenDB team reevaluates these restrictions and considers how crucial the Community Edition has been for developers like me. These limitations could not only alienate the developer community but also tarnish RavenDB's previously sterling reputation.

[georgiosd]

@oiBio you seem to be taking the stance that the community license is too restrictive when in fact it seems to have been overly permissive, IMO. What kind of pet project needs more than 12 indexes?

I asked this in a similar complaint and the answer I got was "light usage for a complex app". Isn't that where you need to be then considering hosting RavenDB for your clients and sharing a Pro license, or get a cheap RDB cloud instance? I don't quite get it.

[oiBio]

A cloud instance is not suitable for us/our customers due to GDPR concerns.

We've developed custom applications for clients that run on their servers. These were one-time projects for us and don't require much support or maintenance. We utilized numerous collections, indexes, and subscriptions to address specific challenges. It's not feasible to purchase a Pro license costing several thousand dollars annually when the entire application development cost less.

However, that's just one example...

While I believe we might have navigated the limitations and achieved a similar outcome, that's not the reason we appreciate RavenDB. We value it because "it just works". With the new licensing, defaulting to RavenDB isn't an option anymore. We're compelled to explore other databases, and that genuinely saddens me. :-(

You could also limit the number of documents to perhaps 5 million. What kind of "pet project" requires more than that?

What did Bill Gates once allegedly say? "640K ought to be enough for anybody."
Predicting the needs of future applications or underestimating users can backfire. The flexibility and capacity of a tool should cater to a range of projects, from small-scale hobbies to ambitious endeavors.

[krivulcik]

I want to express my opinion here, too. I wholeheartedly agree with @oiBio.

My thinking is the following: Let's say I want to start a new personal project, possibly with some commercial potential. How many indexes will I need? I don't know. Will it generate enough revenue to cover and justify the license costs once I need to add the 13th index? Maybe yes, but most likely not.

So, RavenDB is out of the question now for small personal projects and maybe basically for anything other than large-ish projects with somewhat guaranteed commercial success. I'm afraid this will severely limit the uptake of RavenDB by developers/companies not familiar with it yet.

When considering this for my project, I'd have to think hard before committing to using RavenDB. It would also severely lower my score in "How likely I am to recommend RavenDB to a friend or colleague."

[ayende]

To answer your most important question, about what happens to your existing applications: Absolutely nothing.

All those licensing restriction apply only for version 6.0 and up, they do not apply retroactively, nor would there be any licensing behavior changes to RavenDB 5.4. You can still use your RavenDB 5.4 and as an LTS release, there is a minimum of 1 year of support guaranteed after the next LTS release. Note that 6.0 is not an LTS, so you can expect at least another two years of fully supported 5.4 without any limitations.

Now to the rest of your concerns. I really wish that I could provide all that we have for everyone, but economic realities means that we have to make decisions about what we can do.

You mentioned that you love RavenDB because "It Just Works", and I'm really happy about that. It has always been my intent to get to that level and it is one of the primary drivers behind the creation of RavenDB.
Part of that also means that we provide a level of support that you won't see anywhere else. I pride myself on the quality of RavenDB's software and even more on our ability to solve problems when they arise. Compounded over time, it leads to the "It Just Works" model.

That level of commitment to quality and support has its costs. And they are not insignificant ones.
To give some insight into that, let's talk about one such incident (#16624) - a problem with replication. Time from report to resolution is under a week. Development time on our end is about two dev days.
Note that this is for a community license where we aren't making any money out of it.

The reason for the licensing changes in 6.0 is pretty simple. That model is not really sustainable over the long term. And that leaves us with a few options to explore. One option would be to state, explicitly, that we won't provide any support whatsoever to community licenses. That means that if you run into a problem, you'll need to either fix it yourself or purchase both a commercial license as well as a support contract.
That, by the way, would have been a support policy that we would have to implement for existing licenses as well.

I don't like that option, because I believe that it wouldn't be fair to our users and it wouldn't align with the way I would like us to go.

We offer the community edition to our users to play with, experiment as well as deploy simple to moderate applications to production at no cost.
The metrics we use for deciding the limits we put on 6.0 are about the complexity of the application, more than anything else. That reflects both the value gained from using RavenDB as well as the likelihood of support.

We considered putting limits on database size or count of documents, but we rejected them. Size of the data in an application is rarely a good metric to show how valuable a project is, and that tends to give the wrong incentive. I would rather not have RavenDB responsible for bringing an application down because it created the 5M+1 document, for example.
The indexing limits, subscription limits, etc - are all very explicitly chosen to be things that if you run into, you'll run into them during development and have time to figure things out, not be under the gun of an inoperable system.

We also chose those limits to accommodate reasonably sized small to medium projects. To give some context, my blog is running on RavenDB, and it has 6 static indexes (
https://github.com/ayende/RaccoonBlog/tree/master/RaccoonBlog.Web/Infrastructure/Indexes ).
Auto indexes are already automatically merged for you, so you'll need a large number of collections or operations to come near those limits.

In other words, our expectation is that if you are hitting those limits, you are dealing with serious projects and we'll like you to go toward the commercial license.

We'll be happy to accommodate you as needed if there are specific scenarios that you need addressed. You mentioned one-off projects that you turn over to your clients that may not be suitable for a subscription model. We can certainly discuss that in detail and offer solutions. One thing that would be addressed in such a conversation, for example, would be the exact expectations for support in this scenario.

Note that beyond the free community license, we also provide a free developer license, without any restrictions (which you cannot deploy to production). The assumption is that you can start developing using the developer license, free of any limits, and by the end of the project, you can see whatever you need a commercial license or can utilize a community license for those scenarios.

I fully appreciate that those changes are surprising, that is why we applied them only for version 6.0 and why you can continue utilizing RavenDB 5.4 as you previously did. Again, that applies to new projects as well that you are starting now, and RavenDB 5.4 is going to be supported for at least 2 years from now.
I'm also open to working with you to ensure that you are happy with the licensing choice you have.

Regards,

Oren Eini

[lahma]

I was also quite surprised about the new pricing, especially as all the details are hidden and there's no clear messaging for prices - only contact us and let's see what price you will have option (probably enterprisey, Oracleish way to handle it I guess).

Previously we were able to have a production license based on features we need (Professional/Enterprise) and then run community license for QA/Staging where there are some hundreds or even some thousands of documents (data is usually wiped between runs) and the required 30 indexes for the application to function (like in production). Now as there is an index limit it makes this scenario impossible with V6. The Developer License page explicitly states "QA purposes (cannot take place on production/staging/UAT)" which I've read as that it's CI tool usage (integration tests) and not for software project's QA person who runs smoke testing for a release in staging environment before production.

What kind of a license is required for lower environments than production for a projects that have more than 12 static indexes and some very low performance requirements / data sizes?

[ayende]

In general, the dev license is meant for this purpose, and we explicitly allow its use for QA.
The definition we follow is that if this is used by the same team that builds the software, that is development. If this is an instance that is used by the end users for actual operations, that is not allowed.

Please note that given the current situation, I'm likely to be pre-occupied with other issues at this point. If you need more replies, ping sales@ravendb.net in the meantime.

[aqume]

Certainly, it's your product, and you have the liberty to make decisions according to your preferences.

However, we need to exercise caution when selecting such items, especially when embarking on something new. We can never predict when certain restrictions may arise.

While I appreciate an excellent database, it would be preferable to have other kinds of restrictions, rather than limitations on indexes and subscriptions which abruptly halt upgrades to newer versions. Being locked into version 5.x indefinitely is quite restrictive. We cannot test new versions on real production data which might counter impact RavenDB QA.

[DejanMilicic]

We just removed the limitation on the number of static and auto indexes #18564

[adambajguz]

Wow, awesome!!!!!

I didn't expect such a news today. Change the subscriptions and expiration/refresh frequency a bit and I'll be totally shocked!

Thanks RavenDB team! ❤️

[krivulcik]

That's fantastic news. I hope this will lead to more developers choosing RavenDB for their hobby projects, as this was likely the limitation that would discourage people from using this excellent database.