Skip to content

Instantly share code, notes, and snippets.

@swlaschin
Last active November 10, 2023 02:03
  • Star 14 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save swlaschin/73691bea8d6397ba97f4 to your computer and use it in GitHub Desktop.

A response to http://ayende.com/blog/170849/why-ravendb-isnt-written-in-f-or-the-cost-of-the-esoteric-choice

Why my F# projects don't use RavenDB, 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.

@jackfoxy
Copy link

Touche.

@Micha-kun
Copy link

Bravo!

Copy link

ghost commented May 18, 2015

Funny, but still so true.

@rushfrisby
Copy link

slow clap

@popcatalin81
Copy link

Except that RavenDB solves some real world problems that are inherent to relational databases, F# does not solve any problems that are inherent to C#, F# vs C# it's a matter of flavor and style, for the most part, for the smaller part, C# is a language targeted at componentized applications, while F# is targeted at small computational domains.

I've used more esoteric languages than F# (see Boo) and using F# "is" a matter of style and preference, while using a Document database vs a Relational database is not. It's a real world problem solving choice, and it's not the same type of choice.

@marhoily
Copy link

You insincere. On many levels.

  1. SqlServer vs RavenDb != F# vs C#. You have to compare to MongoDb or something similar
  2. It is much less of an effort to learn RavenDb than F#.
    Saying all that you actually have a good case. I've no doubt that people carefully consider your argument when they start new projects, as well as ayende's. Many of them prefer the Mongo over the Raven. I'm afraid some of them even choose SQL over NoSQL exactly for that reason. Because it's a very good reason.

@danielrbradley
Copy link

Welp, can't argue with some large number, better accept all other statements without further consideration

@Mark-Broadhurst
Copy link

Of course the argument is the most popular # is the easiest\cheapest to find people who use it. So with that in mind we all should use Oracle, MySQL and MSSQL (http://db-engines.com/en/ranking) with C, Java and PHP (http://langpop.com/) but that would be quite a dull world to live in.

Having said that I think its a bit cheeky to suggest that someone re-writes their existing production app in any different language since a re-write is almost never worth the money.

@abatishchev
Copy link

Why do you write RavenDB but not SQL Server? Instead something not existing as SqlServer.

@jasonyandell
Copy link

Scott, I shook your hand at NDC '14, and I've always been glad I did. This is just more confirmation. +1 internets to you, sir

@jasonyandell
Copy link

@popcatalin81 know how I know you haven't explored F#?

@thomassvensen
Copy link

I think Dan McKinley focuses on the key factor when picking a tool in his blog Choose boring technology. Quoting:

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.

Currently, the state of affairs is that C# and SQL Server provides the best value for money for most businesses, as did once COBOL and DB2. But over time, I believe and hope that tools like F# and RavenDB will take it's place.

@misterspeedy
Copy link

I guess it would be too harsh to leave this here. Ooops.

https://octopus.com/blog/3.0-switching-to-sql

@ralbu
Copy link

ralbu commented Oct 19, 2016

Nice :) For the people who got angry with the post, it was written in response to http://ayende.com/blog/170849/why-ravendb-isnt-written-in-f-or-the-cost-of-the-esoteric-choice

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment