A response to http://ayende.com/blog/170849/why-ravendb-isnt-written-in-f-or-the-cost-of-the-esoteric-choice
As you know, I generally recommend using SqlServer for data storage.
But many people have suggested that using RavenDB rather than SqlServer would dramatically reduce the development effort.
My reply to that was that using RavenDB would also lead to a lot more complexity, reduced support by other teams, harder to find DBAs and increased costs all around.
And the data to back up this statement:
- SQLServer deployments: (some large number)
- RavenDB deployments: (some much smaller number)
and
- Devs and admins with SQLServer experience: (some large number)
- Devs and admins with RavenDB experience: (some much smaller number)
and
- Size of SQLServer ecosystem: (some large number)
- Size of RavenDB ecosystem: (some much smaller number)
You have that option to use cheaper databases. I think that the cheaper databases usually will actually increase your costs. But if that is your way, then I wish you good luck, and I accept that as an answer.
Now, let me try to explain my thinking. In particular, I would strongly disagree with the “cheaper databases” mentality. That is very far from what I’m trying to achieve. You usually get what you pay for, and trying to save on database costs when the most critical part of your business is data is pretty much the definition of penny wise and pound foolish.
But let us ignore such crass terms as money and look at availability. There are less than (some small number) of jobs for RavenDB devs and admins (with salary ranges implications that there isn’t a whole lot of RavenDB devs and admins queuing up for those jobs). There are tens of thousands of jobs for SqlServer devs and admins, and again, the salary range suggest that there isn’t a dearth of qualified candidates that would cause demand to raise the costs. From those numbers, and my own experience, I can say the following.
There are a lot more SqlServer devs and admins than there are RavenDB admins. I know that this is a stunning conclusion, likely to shatter the worldview of certain people. But I think that you would find it hard to refute that. Now, let us try to build on this conclusion.
First, there was the original point, that RavenDB reduced work for development effort. I’m not going to argue that, mostly because database storage isn’t an issue of who can type the most. The primary costs for database storage is admin, maintenance, long term support, performance tuning, production proofing, etc. The act of actually typing is pretty unimportant.
For fun, I checked out the line count numbers for similar projects accessing RavenDB & SqlServer. So just say that a program can use RavenDB effectively with 25% lines of code of a comparable program using SqlServer for storage.
Note that I’m not actually agreeing with this statement, I’m just using this as a basis for the rest of this post. And to (try to) forestall nitpickers. It is easy to show great differences in development time and line of code in specific cases where RavenDB is ideally suited to the task. But we are talking about general purpose usage here.
Now, for the sake of argument, we’ll even assume that the cost of using RavenDB in development is 50% of the cost of SqlServer development.
Where does this leave us? It leave us with a potential pool of people to hire that is vanishingly small. What are the implications of storing data in a database that few people are familiar with?
Well, it is harder to find people to hire. That is true not only for people that you hire “as is”. Let us assume that you’re going to give those people additional training after hiring them, so they would know RavenDB and can work on your product. An already steep learning curve has just became that much steeper. Not only that, but this additional training means that the people you hire are more expensive (there is an additional period in which they are only learning). In addition to all of that, it will be harder to hire people, not just because you can’t find people already experienced with RavenDB, but because people don’t want to work for you.
Most developers at least try to pay attention to the market, and they make a very simple calculation. If I spend the next 2 – 5 years working in RavenDB, what kind of hirability am I going to have in the end? Am I going to be one of those trying to get the very few RavenDB jobs, or am I going to be in the position to find a job among the tens of thousands of SqlServer jobs?
Now, let us consider another aspect of this. The community around a project. I actually have a pretty hard time finding any significant systems using RavenDB projects. But leaving that aside, looking at the number of third party tools, and the ability of users to get support from experts who understand the technology is a major advantage. That is possible only because there is a wide appeal. If the database is not well known, the number of people that are going to spend the time and do something with it is going to be dramatically lower.
Finally, there is the complexity angle. Consider any major effort required. Recently, we have been working on porting our client applications to the cloud. Now, RavenDB works on small servers, but it is not designed for the cloud and requires extra work, so anyone who needs to run their application on the cloud would have this additional requirement to work with, and would need to understand distributed version of RavenDB as well as cloud architecture in general. Any distributed data problem that we would run into would have to first be simplified to a non-RavenDB sample so it could be readily understood by people who aren’t familiar with it, etc.
To go back to the beginning, using RavenDB might reduce the time of development, but it wouldn’t reduce the time to actually build the software and it would limit the number of people that can work with the data later.
Whooosh!
I missed the whole point of why you should use RavenDB, didn't I?
Yes. Exactly.
Why do you write RavenDB but not SQL Server? Instead something not existing as SqlServer.