MongoDB 3.0 has landed.

The development cycle for 3.0 has been the most eventful of my entire career. As originally planned, it would have been great, but still incremental in nature. Instead, we wound up acquiring our first company, integrating their next-gen storage engine, and by capitalizing on that unlooked-for opportunity, delivering a release so beyond its original conception that we revved its version number.

Renaming a release in-flight is out of the ordinary, so I wrote about our reasoning when we announced the change. We had originally planned to deliver document-level locking built into MMAPv1, and a storage engine API as an investment in the future, not part of a fully developed integration. That would have been our incremental improvement, in line with our storage engine efforts throughout the 2.x release series. We had already added database-level locking, iterated over many improvements to yielding and scheduling behavior, and refactored a ton of code to decouple components.

In my first post on this topic, I said I’d post an update in a week or so. Ok, so that was about 7 weeks ago.

I abandoned the trial of both of these techniques because 2.8.0 is, frankly, more important than my experiments in productivity. I’m going to get back to it, but this is actually an opportunity to say something important about getting derailed from productivity projects by urgent items.

Today our team made public our first release candidate of MongoDB 2.8, rc0.

Since June, beginning with MongoDB World 2014, I’ve been speaking publicly about MongoDB 2.8, and its headline features: document level locking and pluggable storage engines. What I haven’t said until now is just how related these two features are.

We’ve been working on our storage API for roughly a year, and with MongoDB 2.8 rc0, we’re rolling out the first fully supported and working storage engine integration: WiredTiger.

On November 6th, I’ll be delivering the keynote address at MongoDB London 2014. I’ll be talking about the upcoming 2.8 release, the future of storage engines in MongoDB, and Automation. Since our last conference (MongoDB Boston 2014), the revamped MMS with Automation has gone from soft launch to wide release, and the response from the MongoDB community has been fantastic. We’re seeing tons of adoption and getting lots of great feedback. We’ve also been hosting meetups in our offices, to demonstrate how easy it is to use Automation to deploy a MongoDB infrastructure at any scale.

“MongoDB is as easy to operate at scale as it is to develop with.” From the very beginning of MongoDB, I’ve envisioned making that bold claim. Until today, it’s been a dream.

We just brought it firmly into the realm of the realistic. Today we rolled out a completely revamped MMS built atop Automation, our cloud service for deploying and running MongoDB. Automation works with any infrastructure, from AWS to private cloud to bare metal. It deploys brand new replica sets, adds new shards to clusters, adds replica set members, deploys version upgrades… all at the push of a button. Monitoring and Backups are maintained seamlessly via Automation as well. It also makes julienne fries.¹

I’ve been using this new toy. Well, it’s for work, but until the novelty wears off, it’s definitely also a toy.

I like taking notes in meetings on paper as much as possible. It’s less distracting, and more friendly. I’ve tried various ways of doing this, but nothing has stuck yet. The closest has been a regular notebook. The biggest problem is that I don’t like carrying things to and from work, or to different places. So I invariably end up with 4 notebooks, and then I can’t get notes from a trip when I’m at the office.

Everyone with a staff knows they need a staff meeting on a recurring basis, often weekly. And those who don’t have staff are themselves in other people’s staff meetings, making it one of the most common meeting types for anyone to attend. Sadly, there is often ambiguity around what they are for, making them annoying and inefficient.

What I Want out of Staff Meetings

The purpose of these meetings is twofold: 1) status updates, and 2) key decision making or the precursor conversations for decision making. I want status updates to be very efficient, well thought out, and delivered only for items that are really required. I want thoughtful conversation on key topics, and I want to cut short conversation when the topics are sufficiently discussed.

MongoDB 2.6 has been released. For my thoughts on many of the features of the release, please see my blog post on mongodb.org.

Beyond the features, this release means a lot to me. In five years, we’ve gone from four people trying to figure out if a document database was a viable concept, to the fifth most popular database in the world. MongoDB 2.4 and all previous releases proved that the document model can transform how modern applications are developed and deployed. Despite this, we knew many of MongoDB’s core components were imperfect. It was time to address these shortcomings.

Like The Superhero, The Martyr does their team’s work to make up for not managing. However, whereas The Superhero insists on hogging all the interesting work, The Martyr does work that no-one wants to do.

When a deadline is looming and things are looking down, they will pull all nighters to finish it themselves rather than do what a manager should do, such as motivating their team, or fixing the deadline. When things go wrong, they will take all the blame instead of teaching their team.

Like The Martyr, The Superhero does their team’s work to make up for not managing. They are super smart, super capable, and they can often do most or all of the jobs that their reports do better than their reports. They also care deeply about the quality of the product their team works on. Unfortunately, they are not inclined to delegate any of the interesting work, because they want it all for themselves. If one of their reports comes to them with a problem, they are more likely to just do the work for them than teach them how to solve the problem.