MongoDB is replacing its founding chief technology officer with a veteran who has come straight from the relational database world. Mark Porter, most recently CTO of Singapore-based Grab, a ride sharing and digital payments platform, joins the C suite at MongoDB after being appointed to its board back in February. He replaces founding CTO Eliot Horowitz, who was very much responsible for MongoDB’s JSON document database orientation. Porter will take over as CTO on July 20.
The announcement wasn’t much of a surprise. MongoDB announced Horowitz’s stepping down as part of its Q4 earnings announcement last March, giving July 10 as the date that he would transition into a technical advisory role.
Porter is a longtime database veteran, having spent over a decade in director roles at Oracle in server development, and nearly four years as general manager of Amazon’s RDS business (which included the Aurora database) in a stint that lasted up to 2018.
In a blog post published this morning, Porter spoke of a goal to simplify the database experience, having boasted of speeding the release process for new Oracle versions from a week-long manual ordeal to a more automated process taking 20 hours. In a confessional tone, this SQL veteran admitted that “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,” referring to the inflexible data models.
In our conversations, Horowitz always communicated a strong belief that the document model was the most natural way to represent data and was never a big fan of SQL. Significantly, while rival platforms such as Couchbase and Cassandra incorporated some SQL-like constructs in their query languages, that was not the case for MongoDB’s query language. The company only developed a BI Connector after customers called for the ability to generate visualizations on popular tools such as Tableau. But even with the BI Connector, MongoDB has continue to tread its own path with MongoDB Charts on the rationale that eliminating the need to force-fit document data into relational tables preserves its richness, especially with the hierarchical and nested schemas inherent in JSON.