Introduction
In the world of modern software development, managing the flow of data between services and applications is one of the biggest challenges. Matt DeBergalis, co-founder and CEO of Apollo GraphQL, has been at the forefront of solving this problem. His journey began with the Meteor framework, which revealed a critical need for a more principled way to handle data fetching. This led to the adoption of GraphQL, a query language that treats APIs not as a collection of disparate endpoints, but as a unified, connected graph.
In this discussion, Matt joins Nataraj to explore the evolution of Apollo GraphQL from an open-source project into an enterprise-grade platform. He breaks down the unique value of GraphQL for developers, the strategic decisions behind building a commercial product around it, and the complex trade-offs in today’s full-stack architecture. He also offers a compelling look at how AI is amplifying the need for robust API strategies, making technologies like GraphQL more relevant than ever.
→ Enjoy this conversation with Matt DeBergalis, on Spotify, Apple, or YouTube.
→ Subscribe to our newsletter and never miss an update.
Conversation Transcript
Nataraj: You’re now CEO of Apollo GraphQL. Can you give us a two-minute history of your journey until now?
Matt DeBergalis: We started the company with Meteor, which was a JavaScript development framework from the era of the first true browser-based apps. When you build software that way, you need a principled story for how you move data from the cloud into the application.
Matt DeBergalis: GraphQL and Apollo are at the heart of that story. While building Meteor, we found that the piece of the stack that brokers the flow of data from underlying databases, APIs, and all the systems that feed your software up to the app is where there’s a ton of complexity. It also accounts for a huge fraction of the handwritten code that makes building good software take so long. GraphQL is a wonderful, declarative language, so you can build infrastructure around it. We see this happening all over the stack—Kubernetes and React are examples. Apollo is that for your APIs. It’s about replacing all the single-purpose, bespoke code you might write with a piece of infrastructure and a principled programming model.
Matt DeBergalis: The name GraphQL hints at what makes it wonderful: we treat your systems, data, and services not as individual endpoints you call imperatively, but as a connected graph of objects. That completely changes the development experience. It makes it possible to express complex combinations of data in a simple, deterministic way. There’s a query planner in there, so you can do all kinds of transformations and other things necessary to build software in a repeatable, understandable way. We’ve found that this dramatically helps companies, especially larger ones with lots of APIs, accelerate how fast they can build good software.
Nataraj: GraphQL was initially open source while you were working on Meteor. At what point did you realize there was enough opportunity to make this a new company?
Matt DeBergalis: A couple of things were happening. First, the original version of Meteor was based on MongoDB, so we received many requests to support other databases, data sources, and REST APIs. The Meteor development experience was almost like black magic; you would write a MongoDB query directly in your client code. Meteor would run that same query on the Mongo server in the cloud and synchronize the results across the wire. This infrastructure efficiently kept them in sync in real time. The consequence was that Meteor apps were real-time. You’d write a query, connect it to a component on your screen, and as the database changed, the screen would automatically update. That was amazing, especially in those days, but it had to be in Mongo. So we needed a more general query language.
Matt DeBergalis: Just as we needed that, Facebook announced GraphQL. This brings me to the other part of the answer, and why I think GraphQL has flourished where similar ideas haven’t. In my view, GraphQL is the first API technology that really asks about the needs of the clients—the consumers of data—instead of the providers. REST APIs, or older technologies like ONC RPC or SOAP, are all defined by the server. The consumer gets what they get—the payload, the format, the protocol. This puts a huge burden on the application developer because it’s rare that what comes back from the API is exactly what you need. You might need to filter it, transform it, or join it with another API.
Matt DeBergalis: GraphQL has an incredibly good developer experience for the consumer. You write a strongly-typed query, which means great tooling support in your editor. Now there’s great tooling support in agentic editors because it’s semantic and self-documenting. A lot of what makes a technology win is the feeling a developer gets when they try it—how easy it is to use and how quickly you can get to something good. GraphQL had that delightful characteristic. It came from the same team at Facebook that created React, so it had a lot of energy as web development moved into the modern era. Those two things made it an easy choice for us.
Nataraj: It’s interesting that so many developer technologies came out of Meta that they didn’t monetize. Unlike Amazon or Microsoft, they seem to define themselves strictly as a social media company. Why hasn’t Meta become a fourth cloud provider? They have the technology, developer experience, and money to do it.
Matt DeBergalis: Here’s one quick point on that. A lot of the energy around React, for example, really came out of recruiting. Many companies do this. Open source was a tool for driving an engineering brand, especially in an era when it became very difficult to hire. There was a war for application development talent. So, one reason to open source something like React, even without a direct business case—it’s hard to monetize React, Vercel is probably the best example and it’s a tenuous connection—is that if it helps you recruit, you can justify a lot.
Nataraj: That’s a very important point. It likely explains Microsoft’s strategy shift to becoming one of the biggest open-source contributors. So, we have these open-source products that find developer love, and then a company forms around them, like Databricks with Apache Spark. What was the journey like for GraphQL, taking a great open-source product and turning it into a business with a product worth paying for?
Matt DeBergalis: One surprising thing is that open source on its own often doesn’t get a ton of adoption, especially when it’s designed for a larger company’s needs. Take Databricks and Spark. One way to look at it is that they built the company because people weren’t adopting Spark. Why not? Because it was hard. It’s a complicated piece of machinery. The company that needs that problem solved needs more than just Spark. The best vehicle for solving those kinds of problems is a business because it allows you to create a whole product, a solution. The enterprise sales process is really about helping the customer navigate the decision. The monetary cost is one thing, but the much bigger cost is the complex, multi-stakeholder architectural decision.
Matt DeBergalis: With GraphQL, we asked a simple question: How do you get something like this adopted? I can give you a compelling technical reason why having a graph and writing a query is better than writing a bunch of procedural code for every new application experience. But in practice, how does that get adopted? If you pull that thread, interesting things emerge. Who owns APIs in an enterprise? Who makes architectural decisions? How do you balance the executive who owns the roadmap with engineering needs? The VP of engineering job is maybe the hardest job today. You’re under enormous pressure to ship quickly. If you ship slower than your competitor, it could be the end of your company’s viability.
Matt DeBergalis: At the same time, you can’t mortgage the future. If you race to ship a product but create a big security vulnerability, you’ll get fired. If you build a product and then discover Amazon shipped Alexa and you need a voice app, or OpenAI shipped GPT and you need an agent, you’re in trouble if you’ve painted yourself into an architectural corner. You’re caught between a rock and a hard place. The consequence is you’re going to want help—more than just a raw piece of technology. You’ll want a plan, end-to-end integration, and all the ‘ilities’: observability, security, auditability. That, for infrastructure at least, is the heart of how you go from an exciting open-source project to something that makes business sense and can be adopted at scale.
Nataraj: When a business adopts an open-source technology, they’re not just adopting a product; they’re adopting a certain level of risk. That’s why you have legal agreements about things like data privacy issues.
Matt DeBergalis: That’s right. And the biggest risk by far is picking the wrong technology. Think about the cost of getting that wrong. If you adopt a database and five years later it has no users, the open-source project is on life support, and there’s no vendor to help you, you’re in real trouble. You’re facing a migration.
Nataraj: The problem with Meta open-sourcing Llama is that if I’m building on top of a model, I need someone to host it and guarantee 99.99% reliability. There are all these dynamics between open and closed source.
Matt DeBergalis: You see this across the stack. Maybe 10 or 20 years ago, a developer would start by asking what’s open versus closed to avoid vendor lock-in, especially after experiences with companies like Oracle. Now, it’s a little different. There’s so much to buy across the stack that you don’t have time for a deep analysis of everything. The biggest risk is getting it wrong. With AI moving so fast, you see a preference for what’s prevalent. You’re probably going to be in good shape if you go with the market leader. That means you can hire people who know the technology, and there’s a good chance it will mature quickly enough to meet your future needs. It’s a virtuous cycle. That’s the pitch I make for GraphQL: you have an API strategy to decide on, and you should start from the premise that picking the one developers like, with a vibrant user community, is a safe choice.
Nataraj: I have a view on the evolution of full-stack development and wanted your thoughts. Are we making it more or less complicated? I feel like we’re making things more complicated to stand up a scalable web application.
Matt DeBergalis: I grew up writing software on a Commodore 64. It’s definitely gotten more complicated, and it’s all across the stack. Microservices make sense for scaling engineering efforts, but they drive the need for things to manage those processes, like Kubernetes. You need a way to orchestrate API calls across them, which is our GraphQL story. Does Apollo add complexity? There’s an argument that it does. On the other hand, each of these layers, when done right, adds value and lets you go faster. A good architecture should have the property where the more you build, the more valuable the whole thing becomes. Some technologies feel like the opposite; you keep putting energy in, but it slows you down.
Nataraj: It feels like there’s a lot of distance before you see that geometric growth. The early investment is high, and you’re always thinking two or three years down the line. You can’t start something fast because you’re planning for the future, like choosing the right database.
Matt DeBergalis: It’s gnarly because many technology decisions boil down to: do I want a quick result today, creating debt for tomorrow, or do I want to set myself up for a bright future? It’s a hard call. Our job is to try to square that circle. Kubernetes was really complicated for a long time, but it has gotten easier to use. Now, we see all the benefits. That’s been a big priority for us at Apollo. The knock on GraphQL is there’s a lot of upfront setup work to build a schema—the catalog of all your APIs. Once you’ve done that, it’s wonderful, but getting there is a pain. Much of our roadmap over the last year has been about making it really easy and fast to get to that point of value. In 2025, most people will choose to solve today’s problem and worry about tomorrow later.
Nataraj: For a small company with just one or two APIs, at what point does adopting GraphQL make sense? What type of customers do you have today?
Matt DeBergalis: It makes sense from the client’s point of view. When you’re using GraphQL and React, you just write a query in your component, and that’s it. From the API side, with one or two REST APIs, it’s not a big deal. You can easily change them. But for a company with 10,000 REST APIs, it becomes very difficult to change them because you have no way of knowing what fields are being used. The thing that’s really interesting now is agents. Everybody wants to have some kind of agentic experience on top of their APIs, and GraphQL is a fantastic fit. GraphQL is an orchestration language. It’s about transforming, changing protocols, filtering. We’re excited about agents because they put those needs front and center.
Nataraj: Can you talk about the size and scale of Apollo today as a business?
Matt DeBergalis: GraphQL is used in about half of the enterprise world. We see this because we provide most of the standard open-source libraries. Commercially, we’ve focused on larger companies because graphs have a network effect; they are most valuable when they’re large. For example, we have a lot of retailers. Think about an online store. On a product page, you want to show the customer, ‘Arrives on Friday.’ To do that, you need to make a ton of API calls under the hood—inventory APIs, shipping partner APIs, loyalty APIs. It’s the kind of thing that seems trivial from a user experience perspective but explains why it often takes months to ship. Larger, established companies in retail or media, like The New York Times, find GraphQL incredibly valuable. Also, companies that have grown through M&A and have heterogeneous systems need to bring products together into a single user experience. That’s where GraphQL is historically adopted most. But again, agents are changing that, creating excitement around GraphQL at companies of all sizes.
Nataraj: How do you acquire customers and market to new developers to ensure you remain the go-to product?
Matt DeBergalis: For most open-source companies, including us, open source is an important part of the funnel. Development teams make the technical decisions. It starts with a developer who reaches for something they’ve heard of that makes sense and that they can try quickly. Open source is a great vehicle for that. It starts with a React developer reaching for Apollo Client or an MCP developer wanting to define an agent declaratively. You can build from there, but that open-source entry point and the content around it are by far the most important things.
Nataraj: You recently transitioned from CTO to CEO. How has your focus changed?
Matt DeBergalis: It changes a lot and changes nothing, depending on how you look at it. I’ve always felt our customers are where everything comes from. The first version of Apollo Client was really bad, but it had one killer feature: we took pull requests. People would adopt it, and that turned into wonderful partnerships, like with The New York Times. It was a formative technical partnership that became a customer partnership. For me, the heart of it has always been partnership. I don’t see that differently from the CEO seat. Startups that do well all say users and customers come first. I always spent a lot of time with our sales team and on marketing. That hasn’t changed. And I still do product demos every Friday. I don’t ever want to lose touch with that. If we don’t have a great product that developers love, the rest doesn’t matter.
Nataraj: What does the sales motion for Apollo look like? Who are you typically talking to?
Matt DeBergalis: It varies. You can look at Apollo from two different perspectives. One is the team trying to ship a piece of software. For them, Apollo helps them ship faster and with less risk. That’s who you want to sell to because that’s where the value is. They own roadmaps. The other lens is seeing Apollo as a platform. You have platform engineering teams that own developer productivity or operational excellence outcomes. Ideally, we initially bring Apollo to a team with a specific use case. If you’re selling to someone for whom the value isn’t immediate, it’s much harder. You start there, but you think about eventual expansion. When you think about expansion, a technology like this will naturally find a place in a platform organization’s portfolio, so you want to meet those people early on.
Nataraj: Let’s talk about AI. What are your thoughts on the current hype cycle, and what is the opportunity for Apollo in AI?
Matt DeBergalis: I’ve never seen anything like it. It’s so disruptive. The immediate thing for us is that AI will drive a lot more API consumption. Every company is scrambling to build some kind of agentic user experience. The line between an agent and an app will get blurry. For example, a bank has one mobile app for a wide range of customers, from retirees to college students. With agents, maybe that one app can serve both by learning what I’m into and adapting the user interface. That’s a really different kind of app, and every one of those efforts will drive a whole bunch of net new API calls. That’s good for Apollo and GraphQL.
Matt DeBergalis: Also, the nature of those API calls is different. You can’t trust a non-deterministic model, so the API layer needs more access control and policy enforcement. GraphQL is a nice fit here because it’s semantic. Token management becomes really important. The best way to keep a model on track is to not feed it tokens it doesn’t need, which also saves money. That sounds like GraphQL—only the fields I want. So, we’re seeing a lot of demand for GraphQL because of agents. The way we build software is also changing. Every part of our company is changing. If we’re going to be an essential part of the AI-first stack, we have to be an AI-first company.
Nataraj: Has AI changed the business metrics for your company? Has it helped save costs or optimized capital expenses?
Matt DeBergalis: AI definitely accelerates some things. Sometimes you use that to get more done, and sometimes to do it more cost-effectively. We’ve seen both. It’s also not magic; we’re still figuring out what it can and can’t do. Personally, AI helps me do a lot of things faster and better. I use it a lot for research, and I feel more informed than I was a year ago. I don’t have a research team at my disposal. I don’t think of it as changing how we hire as much as having more relevant information at my fingertips, which helps us make better, faster decisions.
Nataraj: It almost feels like AI is overestimated in the short term and underestimated in the long term.
Matt DeBergalis: So much is like that. I think that has to be true.
Conclusion
Matt DeBergalis provides a masterclass in identifying a core developer need and building a powerful platform to solve it. His insights into GraphQL’s client-first approach and its growing importance in an AI-driven world offer a clear vision for the future of API architecture.
→ If you enjoyed this conversation with Matt DeBergalis, listen to the full episode here on Spotify, Apple, or YouTube.
→ Subscribe to our Newsletter and never miss an update.
