‹ back to Testimonials

General Mills

General Mills

My name is Kamran Ayub. I work at General Mills as a Senior Web Platform Specialist.

2. In what kind of project/environment did you deploy RavenDB?

I use RavenDB for a hobby non-commercial project called Keep Track of My Games (http://ktomg.com). It is a hosted solution on Microsoft Azure and I currently use RavenHQ to host my staging and production databases.

3. What made you select RavenDB as the NoSQL solution?

Originally I used Azure SQL and Entity Framework as the backend for my project. I found EF to be hard to use, especially for migrations and continuous development. Further, the price/performance scheme in Azure was not the best for a hobby project. I knew RavenDB was the best NoSQL option for a .NET application and I rewrote the backend to use Raven.

4. How long did it take to learn to use RavenDB?

It didn’t take me long to learn the basics, perhaps two months but it took me awhile to learn all the best practices and patterns over time from reading the Google group, blog posts, and talking to other Raven developers.

5. What are you doing with RavenDB?

I use it as a store to help manage people’s video game collections and track new game releases. I use Raven in conjunction with Azure Table Storage to keep a running history of release date changes for games so I can notify users when games they’re following come out or changes in release dates.

6. What do you consider to be RavenDB strengths?

Fantastic development workflow (no schema changes, side-by-side index deployments), essentially means I can rapidly release new features without worrying too much about schema changes. If there is a wide change, I can use Patch scripts to do manual migrations of data. The ability to batch multiple calls to reduce network roundtrips is a huge boon for cloud deployments that rely on thinner infrastructure and need to optimize heavily to keep performance on par.

1a. What were you trying to solve?

The core use case of my site is managing a user’s game collection. In a normal relational database, this would be many different joins to many different tables in order to retrieve all the relevant information to display and filter. A user’s collection could have thousands of games

2a. What problems were you having?

The queries EF generated were large and once deployed into a live environment were a large contributor to page load time due to the number of queries to load a single user’s collection.

3a. How did you address them using RavenDB?

Using Raven I was able to reduce the roundtrips over the network to the database to create faster loading user collections while also allowing a simpler object model vs. the many mapping objects EF would require. It also greatly simplified my data access layer and domain model, allowing me to remove large swaths of EF mapping/boilerplate code. In addition I can leverage data subscriptions to have users be notified when their collections change or when game details change.

Additional Notes:

Overall I’ve been pretty happy as a RavenDB user, in a personal sense (since I don’t use it at my company). I’ve usually recommended it to friends and colleagues for their projects but there are things that were less than ideal during my few years as a user (it has gotten better since I started using Raven):

● Documentation doesn’t cover some of the “patterns and practices” of using Raven in practical applications. I would love to see more “real world” sample applications that show different document modeling designs and architectures. This was the hardest part of learning Raven. Sometimes the documentation was incomplete but it’s since gotten much better.

● RavenDB is a product that is rapidly iterating. This was good and bad--in one respect, it was great to see new features relatively quickly (although there’s quite a delay on RavenHQ) but sometimes I would upgrade only to discover a regression that caused me headaches. I am SO GLAD that 3.5.x and 4.x will have stable fix releases, it makes it much easier to feel confident upgrading my instance if I know it is unlikely to introduce new bugs. It’s also much easier to recommend in an enterprise environment where there may be dozens of applications relying on Raven in production where the possibility of accidentally introducing bugs would be disastrous.

● I really appreciate how accessible the HR team is on the Google Group, able to answer questions quickly. Sometimes though, I feel this speed can come at a cost of being terse or unable to offer as much detail as a more refined response. Sometimes it would take multiple back and forth messages to reach an understanding or sometimes I had to repeat explanations I had made in the original post. It can be hard for a new community member to feel welcomed in that kind of environment--the team means well, I understand, but no one wants to feel belittled, it can mean the difference between someone becoming really involved or being pushed away.

● The pricing of RavenDB is confusing for an individual contributor. I never realized I could even ask for a non-commercial license until I Googled the topic more and read blog posts by Ayende. I wish the Pricing page just said “Non-Commercial Project License? Contact us” instead of only specifically “OSS Projects”--since my project isn’t open but it is still non-commercial. I could have saved so much money these past few years if I only known to ask! Further, it wasn’t until someone pointed out on the Google Group that there were cheaper options than paying $800 a year for Professional Edition--at checkout, the options are given to do Quarterly or One-Time. Had I known that when I began using Raven, I may have done that but I didn’t realize there were other options until later. Additionally, the Basic tiers are enticing except for the storage limit--my database is very small (<200,000 documents) and I’m already at 1.1GB. I would hit the 2GB limit easily if I had more users and then I would be forced to pay for a Standard license. I would suggest increasing/removing the storage limit on the Basic and Basic 2X tiers to allow larger projects.

Thanks for all your hard work--I want RavenDB to be successful. This feedback is just meant to make RavenDB more attractive to people like me and be welcoming to new users. Thank you again!