Who are you? (Name, company, position)
Paul Stovell, founder of Octopus Deploy Ltd.
In what kind of project / environment did you deploy RavenDB?
I use RavenDB as the embedded database behind my automated deployment product. Clients download the software and install it locally, much like they would TeamCity or Team Foundation Server. Customers range from startups and small businesses through to universities and banks.
What made you select a NoSQL solution for your project?
I originally used SQL Server Express, but the complexity that a SQL Server dependency added to my installation made the getting started experience less than optimal. By embedding Raven, I just have to ask customers where data should be stored during installation, and the application can take care of the rest. Also, I found that using a relational database for what is a fairly simple object model constrained my design, since I was always worried about too many joins. That’s not a problem with document databases.
What made you select RavenDB as the NoSQL solution?
Raven had the best .NET support, so that was a huge influence – being able to write a LINQ query without worrying about map/reduce from the start was great. Also, it was the easiest to embed, and the team seem to be innovating a lot.
How did you discover RavenDB?
Long-time follower of Ayende’s blog.
How long did it take to learn to use RavenDB?
Learning the Raven client API was easy. For me, the hard part was learning how to design my documents, which is a bit of a paradigm shift. I probably still use .Include() in my queries more often than I should for example, because I didn’t want to de-normalize too much.
What are you doing with RavenDB?
Raven is used to store the configuration about your deployment environment – your machines, your projects, your packages, deployment logs, and so on. There are about a dozen different document types, and a handful of map/reduce queries.
What do you consider to be RavenDB strengths?
I love the way Raven takes the benefits of a document database, but also carries over a few cool features from the world of RDBMS – for example, I like being able to use Map/Reduce indexes sometimes, but most of the time a LINQ query is enough, and that works in Raven. Also, it’s great to know that it supports features like transactions. Finally, I love that it was designed for .NET from day one. It feels like .NET support is just something that is ‘tacked on’ to other database products – document databases and RDBMS solutions. It feels like Raven is really innovating as far as .NET-oriented databases go. Meanwhile, I’m still working towards my PhD in order to understand how to fetch a page of data from SQL Server J
What do you consider to be RavenDB weaknesses?
For my kind of application, there are some features of a document store that I don’t necessarily need. For example, I’d be happy for indexes to be updated synchronously when I store a document, and to block until they are updated, without having to remember to tell my queries to wait for non-stale indexes. I understand why the product is designed that way though, so I don’t mind it too much.
Now that you are in production, do you think that choosing RavenDB was the right choice?
Absolutely, I couldn’t be happier with the choice.
What would you tell other developers who are evaluating RavenDB?
Stop evaluating and just buy it. It rocks!