MongoDB outlines what today’s developers need to be successful


Mark Porter (MongoDB)

Image credit: MongoDB

Mark Porter is CTO at MongoDB and a technologist with a wide range of interests and many years of experience in the management and practice of software.

Porter joined MongoDB in early 2020 after serving as CTO at Grab, a Singapore-based “super app” company for ridesharing, delivery and mobile payments.

Prior to that, he spent nine years building Amazon RDS managed database services at Amazon Web Services (AWS). Earlier in his career, he spent 12 years at Oracle where he worked on the Oracle RDBMS, led the Oracle RDBMS server development team and eventually rose through the ranks to report directly to CEO Larry Ellison.

I recently had the chance to chat with Porter about joining MongoDB, his relational database snobbery, the benefits of the document model, how to make software developers happy, how to make software deployments secure, and what today’s developers need from the database tier.

Porter also spoke about what it was like working with Larry Ellison and why developers don’t have to become managers to be “successful”.

Matthew Tyson: Hey Markus, thanks for chatting with me. You took over as CTO at MongoDB in early 2020. What was that experience like as the pandemic spread?

Markus Porter: Matt, thanks for taking the time. My journey to MongoDB has been interesting. To be authentic and a little mortified, I really didn’t understand what I was getting myself into. Although I had used MongoDB in several jobs, I have to say that I was still a relational snob.

But when I saw the power of the document model, built-in scalability, and fully engineered high availability, I became much more open-minded. Frankly speaking, MongoDB is a native highly available distributed system that processes transactions, while relational databases are single-primary transactional systems that struggle with distribution and availability.

It also took me a while to fully understand the power of a modern platform – with MongoDB’s drivers, you code naturally in your language and don’t have to go through that incredibly cognitively difficult SQL translation layer. Sure, SQL is really mathematically pure. But with MongoDB, you can do things more conveniently, easily, and efficiently.

Tyson: Where do you see the limits of the data? Where is MongoDB researching and driving the state of the art?

Porter: Well, JSON, believe it or not, is still pushing the boundaries of data. We introduced JSON back in 2009, and the power of this type of data, which can be read and processed by both computers and humans, is still being felt around the world. Open standards like JSON, Parquet, etc. are so powerful.

And the combination with streaming standards and huge economical object stores at the cloud providers makes integration of systems easier than ever before. We’re really focused on making it easier to move data between MongoDB clusters and data lakes, but also in and out of MongoDB. And we manage it all for you.

Just as we’ve eliminated the need to create, maintain, and update a separate search cluster, we’ve integrated open-source Lucene search directly into our back-end engine. Almost every app now needs a search, and with Atlas you turn it on with the click of a button or API call.

I envision more and more integrations like this, while still remaining standards-based and combinable, so people can integrate us anywhere in their workflow – as a system of record, a landing pad for IoT data, or a sink for all of an organization’s 360-degree data about its customers and suppliers. It’s about building easily.

Tyson: It’s amazing to imagine how a seemingly innocuous language feature like JSON could have such a massive impact (thanks, Douglas Crockford).

I’m really curious how you guys manage to stay in touch with developers “on site”. How do you keep your finger on the pulse when maintaining and expanding such a large operation?

Porter: MongoDB has always been a developer-first company. But it is one thing to say it and another to do it; They must want to listen and learn from the feedback that is given, rather than just using “developer first” as a hidden marketing ploy. You see through this, and rightly so.

So first of all, I think it’s more a question of mindset than execution of “how”. In all our early years, MongoDB engineers spent a lot of time in meetings and conferences. Of course, not every interaction can be in person, and the pandemic has definitely made that point clear to us and many other tech companies.

Now that we’re bigger, with millions of downloads and hundreds of thousands of registrations a month, we have a fairly large developer relations team, a champions program, and are relaunching the same meetups and conferences. But frankly, the stuff has trouble scaling.

So we have a lot of great tools that help us stay in touch with developers and our open source roots, and a lot of open source products keep us in touch with the community.

For example, we continue to accept issues and pull requests via GitHub. We use Jira and our improvement tickets are public, so users can comment on them and correspond directly with our engineers. We use Intercom for chat support.

You can contact MongoDB support engineers and they usually get an answer within five minutes 24/7. And then we use, which records and transcribes check-ins and conversations with users.

On the back end, our product team goes through these transcripts and uses this data to inform what we prioritize and what we build. On a more aggregated level, we analyze and review all developer surveys we can find annually – the JetBrains survey, the Stack Overflow survey, and the State of JavaScript survey are a few examples.

I think we’re sometimes in the same position as our customer base, which is that we have so much data — sorting through it and analyzing it to prioritize and decide — that’s the hard part. So let’s do one much to keep in touch with the developers personally and due to the size we also bring software and data to help. There is no compression algorithm or shortcut for this part of the business – people are complicated.

Tyson: When I saw the title of your last article (“Overcoming the fear and loathing of pushing Prod”) I had to laugh. There’s always some apprehension when the rubber hits the road and the business is about to depend on code we’ve just written.

You’ve written a lot of great posts about how to make deployments more robust (“The 180 Rule”, “The Goldilocks Trail”, Etc.). My question here is how hard is it to get people and culture to embrace these practices? Do you have any insights into this?

Porter: (laughs) I’m kinda nervous she read my Things. I think I might surprise your readers with my answer. In fact, these posts and these discussions are far more popular and in demand with me than anything I say about databases or data.

I regularly present at all-hands meetings of engineering teams, and we mainly talk about two things: engineering culture and deployments. I was recently asked to speak to a group of 56 CIOs and all they wanted to talk about was culture and deployments.

Because, as you say, they are two sides of the same coin. I help teams focus on honest and open conversations along the management chain. Managers need to give developers context, and developers need to give managers honest and timely updates—especially when there’s bad news.

But back to your original question… I think that both managers and leaders need to be more brave. They know what makes their deployments more secure, what makes their developers happier, and what makes their sprints more predictable.

So when I speak to them, I am talking about having honest, low-stakes conversations where all parties are speaking and listening with good intentions. Once that is established, the rest can happen. Without that trust, everything is so difficult.

Tyson: They have been involved in several patents including a with Larry Ellison from Oracle. How does an idea progress to a patent? How do you see the role of patents in the software business?

Porter: Larry has a funny backstory. I was at a garage waiting for my car to be fixed and Larry called me about something completely different. But over an hour later, long after my car was finished, we had this idea for network-aware bandwidth and resolution adjustments for video streaming.

Read more on the next page…

Subscribe to the newsletter!

Error: Please check your email address.

Tags MongoDB


Comments are closed.