Let us start with the biggest news. We are offering RavenDB 4.0 FREE for production usage for single node deployments.

In addition to that, the license for the RavenDB Client APIs is going to change from AGPL to MIT. We currently have clients for .NET, JVM, Python and Node.JS, with Go and Ruby clients coming (hopefully by the time we hit RC). All of which will be available under the MIT license. The server license will remain AGPL / Commercial, with a Community deployment option that will come free of charge. The Community Edition is fully functional on a single node.

You can use this edition to deploy production systems without needing to purchase a license, completely FREE and unencumbered.

We have also decided to do somewhat of a shakeup in the way we split features among editions, primarily by moving features down the slide, so features that used to be Enterprise only are now more widely available. The commercial edition will be available in either Professional and Enterprise editions. For our current subscribers, we are very happy that you’ve been with us for all this time, and we want to assure you that as long as your subscription will be valid, the pricing for it will stay as is.

Both Professional and Enterprise Editions are going to offer clustering, offsite backups, replication and ETL processes to SQL and RavenDB databases. The Enterprise edition also offers full database encryption, automatic division of work between the nodes in the cluster (including failover & automatic recovery), snapshot backups and SNMP integration among other things. Commercial support (including 24x7 production) will be available for Professional and Enterprise Editions.

Since I’m pretty sure that the thing that you are most interested in is pricing information and feature matrix, so here is the information in an easy to digest form.

* To save you the math, a 6 cores server with Professional edition will be about 4,494$ and Enterprise edition will be about 7,914$.

1. Snapshots capture the database state and allow to reduce restore time on large databases, at the expense of disk space. Snapshots can work together with incremental backup to get point in time recovery.
2. Tasks (such as backups, ETL processes, subscriptions, updating new nodes, etc) are assigned to specific node dynamically, to spread load fairly in the cluster.
3. When a node responsible for a task goes down, the cluster will automatically re-assign that task without interruption in service.

Task distribution and failover is best explained via a concrete example. We have a database with 3 nodes, and we define an ETL process to send some of the data to a reporting database. That work will be dynamically assigned to a node in the cluster, and balanced with all other work that the cluster need to do. For Enterprise Edition, if the node that was assigned that task failed, the cluster will automatically transfer all such tasks to a new node until the node will recover.

The new model comes with significant performance boost, all the features that I mentioned earlier and multi-platform support. But we are not forgetting about newcomers, small enterprises and individual clients. For those we have introduced a Community version, a completely FREE license that should suit their needs.

Again, for all existing subscribers, we assure you that while your subscription is valid, its pricing will stay as is. In fact, given that we will grandfather all existing subscriptions at the current price point, and you can purchase a subscription now, before the official release of 4.0, you have a nice arbitrage option available now.

The beta release represent over two years of work by the RavenDB Core Team to bring you top of the line database that is fast, safe and easy to use. It is chockfull of features, to the point where I don’t know where to start blogging about some of the cool stuff that we do (don’t worry, those posts are coming).

I’m really proud to announce that we have released the RavenDB 4.0 beta.  It has been a bit over six months of so since the alpha release (I can’t believe it has been that long), and we have been working hard on completing the feature set that we want to have for the final release. We are now ready to unveil RavenDB 4.0 and show you what we can do with it.

Since the alpha release, we completed the refactoring to the clustering infrastructure, so a RavenDB node is always in a cluster (even if just a single one), added attachments, full database encryption and subscriptions, improved indexing performance and performance in general and had done a lot of work to make the database more accessible and easier to use. Cluster scenarios are easier and more robust, you can now take a database and span it on multiple nodes at will and you get the usual RavenDB safety, reliability and fault tolerance.

Users coming from the RavenDB 3.x version will notice (immediately after the studio theme) that everything is much faster. Our internal testing shows anything between 10x to 100x improvement in speed over the previous version.

RavenDB is now capable of handling over 100K req/second for writes (that is over hundred thousands requests per second), and much more for reads, with the  caveat that we always hit the network capacity before we hit RavenDB’s capacity. That is per node, so you can scale the number of nodes in the cluster, so can you scale the amount of reads and writes you can handle.

RavenDB 4.0 also comes with much smarter query optimizer, allowing it to generate optimal queries for aggregation in addition to simple queries. And map/reduce in general has been worked heavily to make it much faster and more responsive.

You can download the RavenDB 4.0 beta from our download page, and NuGet package is available by running:

Install-Package RavenDB.Client -Version 4.0.0-beta-40014 -Source https://www.myget.org/F/ravendb/api/v3/index.json

You can run the beta on Windows, Linux, Raspberry PI and Docker, and you can access the live test instance to check it out.

Known issues include:

• Identities aren’t exported / imported
• Cluster operations sometimes stall and timeout.
• The studio currently assumes that the user is administrator.
• Highlighting & spatial searches aren’t supported.
• Deployment in hardened environment is awkward.
• Upgrading from previous versions is only possible via smuggler.
• Custom analyzers are not currently supported.

If you are upgrading from 3.x or the 4.0 Alpha, you’ll need to export the data and import it again. Automatic upgrades will be part of the RC.

Please remember, this is a beta. I included some of the known issues in this post to make sure that you remember that. We expect users to start developing with RavenDB 4.0 from the beta, and API and behavior are pretty fixed now. But you shouldn’t be deploying to production with this, and you should be aware that upgrading from the beta to RC is going to be done using smuggler as well.

We’ll likely have a few beta releases on the road to RC, fixing all the issues that will pop up along the way. Your feedback is crucial at this stage, since subjecting RavenDB to real world conditions is the only way to battle test it.

In the studio, you can use the feedback icon to send us your immediate feedback, and there is also the issue tracker.

Take RavenDB for a spin, setup a node, setup a cluster, see how it all works together. If we did our job right, you should be able to figure out everything on your own, which is good, because the docs are still TBD. Feedback on bugs and issues is important, but I’m also very interested in feedback on the flow. How easy it is to do things, deploy, setup, connect from the client, etc.

I talked about the new clustering mode in RavenDB 4.0 a few days ago. I realized shortly afterward that I didn’t explain a crucial factor. RavenDB has several layers of distributed work.

At the node level, all nodes are (always) part of a cluster. In some cases, it may be a cluster that is a single node, but in all cases, a node is part of a cluster. Cluster form a consensus between all the nodes (using Raft) and all cluster wide operations go through Raft.

Cluster wide operations are things like creating a new database, or assigning a new node to the database and other things that are obviously cluster wide related. But a lot of other operations are also handled in this manner. Creating an index goes through Raft, for example. And so does high availability subscriptions and backup information. The idea is that the cluster holds the state of its databases, and all such state flow through Raft.

A database can reside in multiple nodes, and we typically call that a database group (to distinguish from the cluster as a whole). Data written to the database does not go out over Raft. Instead, we use multi master distributed mesh to replication all data (documents, attachments, revisions, etc) between the different nodes in the database. Why is that?

The logic that guides us is simple. Cluster wide operations happen a lot less often and require a lot more resiliency to operate properly. In particular, not doing consensus resulted in having to deal with potential conflicting changes, which was a PITA. On the other hand, common operations such as document writes tend to have a lot more stringent latency requirements, and what is more, we want to be able to accept writes even in the presence of failure. Consider a network split in a 3 nodes cluster, even though we cannot make modifications to the cluster state on the side with the single node, we are still able to accept and process write and read requests. When the split heals, we can merge all the changes between the nodes, potentially generating (and resolving) conflicts as needed.

The basic idea is that for data that is stored in the database, we will always accept the write, because it it too important to let it just go poof. But for data about the database, we will ensure that we have a consensus for it, since almost all such operations are admin based and repeatable.

Those two modes end up creating an interesting environment. At the admin level, they can work with the cluster and be sure that their changes are properly applied cluster wide. At the database level, each node will always accept writes to the database and distribute them across the cluster in a multi master fashion. A client can choose to accept a write to a single node or a to a particular number of nodes before considering a write successful, but even with network splits, we can still remain up and functioning.

A database group has multiple nodes, and all of them are setup to replicate to one another in master/master setup as well as distribute whatever work is required of the database group (backups, ETL, etc). What about master/slave setups?

We have the notion of adding an outgoing only connection to a database group, one of the nodes in the cluster will take ownership on that connection and replicate all data to it. That allow you to get master/slave, but we’ll not failover to the other node, only to a node inside our own database group. Typical reasons for such a scenario is if you want to have a remote offsite node, or if you have the need to run complex / expensive operations on the system and you want to split that work away from the database group entirely.

Artificial documents are a really interesting feature. They allow you to define an index, and specify that the result of the index will be… documents as well.

Let us consider the following index, running on the Norhtwind dataset.

We can ask RavenDB to output the result of this index to a collection, in addition to the normal indexing. This is done in the following manner:

And you can see the result here:

The question here is, what is the point? Don’t we already have the exact same data indexed and available as the result of the map/reduce index? Why store it twice?

The answer is quite simple, with the output of the index going into documents, we can now define additional indexes on top of them, which give us the option to very easily create recursive map/reduce operations. So you can do daily/monthly/yearly summaries very cheaply. We can also apply all the usual operations on documents (subscriptions and ETL processes come to mind immediately). That give you a lot of power, and without incurring a high complexity overhead.