In previous versions of RavenDB, we offered a way to run RavenDB inside your process. Basically, you would reference a NuGet package and will be able to create a RavenDB instance that run in your own process. That can simplify deployment concerns immensely and we have a bunch of customers who rely on this feature to just take their database engine with their application.

In 4.0, we don’t provide this ability OOTB. It didn’t make the cut for the release, even though we consider this a very important utility feature. We are now adding this in for the next release, but in a somewhat different mode.

Like before, you’ll be able to do a NuGet reference and get a document store reference and just start working. In other words, there is no installation required and you can create a database and start using it immediately with zero hassle.

The difference is that you’ll not be running this inside your own process, instead, we’ll create a separate process to run RavenDB. This separate process is actually slaved to the parent process, so if the parent process exits, so will the RavenDB process (no hanging around and locking files).

But why create a separate process? Well, the answer to that is quite simple, we don’t want to force any dependency on the client. This is actually a bit more complex, though. It isn’t that we don’t want to force a dependency as much as we want the ability to change our own dependencies.

For example, as I’m writing this, the machine is currently testing whatever .NET Core 2.1 pops up any issues with RavenDB and we are pretty good with keeping up with .NET Core releases as they go. However, in order to do that, we need a wall between the client and the server code, which we want to freely modify and play with (including changing what frameworks we are running on and using). For the client code, we’ve a well defined process and the versions we support, but for the server, we explicitly do not define this as an implementation detail. One of the nice things about .NET Core is the it allows the deployment of self contained applications, meaning that we can carry the framework with us, and not have to depend on whatever is installed on the machine. This makes services and deployment a lot easier.

There is also the issue of other clients. We have clients for .NET, JVM, Go, Ruby, Node.JS and Python and we want to give users in all languages the same experiences of just bundling RavenDB and running it with zero hassles. All of that leads us to spawning a separate process and creating a small protocol for the host application control the slaved RavenDB instance. This will be part of the 4.1 release, which should be out in about three months.