On July 20th, I’ll be joining MongoDB as CTO and leaving my position at Grab. It’s an exciting change.

The best jobs are the ones you run towards, not the ones you take when you’re running away from something else - and my new role at MongoDB is the perfect role for me to run towards. It had to be pretty amazing, in fact, to overcome my angst about leaving Grab. Grab has been a privilege and a gift; being a tech leader with the mission to bring the economy and people of Southeast Asia forward has been amazing. I’m leaving one family and joining another - and for anybody who knows me, they know that’s hard - I’m pretty sappy and emotional about this kind of stuff.

So why leave a great company helping millions of people to go build core data storage and access technology? I’ve always been passionate about tools, about simplifying things for my customers. At Oracle, when I joined out of college, the first thing I did was to turn the release process for the database from a week-long manual process to a single-button push that took about 20 hours. Later, at AWS, our passion in RDS was to make provisioning, accessing, and operating relational databases as simple as possible, and I loved building that for AWS customers and watching how it increased their speed of experimentation. Obsessing over the needs of people who used my work, whether it was developers or customers, has always been my primary goal and where I get the most satisfaction.

For some reason, I’ve always been intrigued by databases. The concept that a computer can reliably store state, protect it from all the various kinds of damage the world can visit on it, and still continuously access it (lightning fast!) feels magical. We even have the CAP theorem to tell us just how hard it really is.

No matter how amazing databases have been, however, building apps on them has never been simple. Normalized data, mathematically pure or not, is agonizing for humans to program against; it’s just not how we think. Mssrs Codd & Date, are you listening? And while SQL might look pretty in an editor, from a programming point of view, it’s close to the hardest way to query information you could think of. Relational databases tout their fixed and predictable data model as a feature, but in reality, inflexible data models are a shackle around any real world developer’s productivity. Just ask any CIO how often they “roll new schema” to their application fleet, and they typically put their head in their hands and mumble “Once a quarter…if we’re lucky.” The speed of your schema changes is directly related to how fast your teams innovate and thus to the innovation speed of your business. Once a quarter isn’t fast enough anymore, if it ever was. Also, sadly, because of their creation long before distributed systems were the norm, relational databases have focused on scale-up rather than scale-out, meaning that they are intrinsically hard to grow, hard to operate, and hard to keep available. It’s time for a change.

For the last couple decades, I’ve wondered whether there would be a way to have the power of a database but also with the ease of programming that we all want. More personally, I was searching for closure (and maybe redemption) for the deep personal guilt I have because I’ve put so much of my career energy into building data engines that don’t make people’s lives as easy as they could. If you don’t know the guilt I’m talking about, look at the SQL generated by any of the popular ORMs out there - it’s clear that there is a disconnect between what developers are trying to accomplish and what their datastores allow them to do.

I’ve got lots of examples of how broken the legacy programming model is. I started debugging database apps in the 1980s (yes, I’m that old) at Oracle and NASA/JPL, and I was shocked at how convoluted the database access code was. People would do amazing things just to ask questions of their computers - for example, in 1989, at Oracle, we had the first >64K SQL statement (I know because it crashed Oracle 6 and I had the bug assigned to me). A couple years later, we had the first SQL statement >1MB (again crashing Oracle, apparently my original fix wasn’t terribly robust). I have talked to hundreds of customers and I’ve taken apart the code of hundreds of apps. Modern companies need reliable simplicity. At Grab, we have over 400 microservices that run the transportation and delivery infrastructure of most of Southeast Asia. Like most fast-paced companies today, and especially during COVID, we need to envision services, prove them out, deploy them, and put them in full production in days - not weeks or months. The relational model, though theoretically correct, is hard to use. It often feels like we’re rearchitecting more often than we’re innovating.

#mongodb