podcast
Neon Co-founder & CEO Nikita Shamgunov
Post on
April 18, 2024
Post on
April 18, 2024
Listen on Spotify, Apple, Amazon, and Podcast Addict | Watch on YouTube.
Today, Palak Goel hosts Nikita Shamgunov, co-founder and CEO of Neon, a 2023 IA40 winner. Nikita is an engineer at heart, with early stints at both Microsoft and Facebook. He previously co-founded SingleStore, which he grew to over $100 million in revenue. Neon is powering the next generation of AI applications with its fully managed serverless Postgres. In this episode, Nikita gives his perspective on the modern database market, building a killer developer experience, and how both are speeding up the creation and adoption of intelligent applications. Congratulations to Neon for recently hitting GA. And if you’re watching on YouTube, make sure to hit that subscribe button. With that, here’s Nikita.
This transcript was automatically generated and edited for clarity.
Palak: Nikita, thank you so much for joining me. Why don’t you share a bit about your background and what your vision is for Neon?
Nikita: I’m a second-time founder, and my core background is systems. I started, after finishing my Ph.D. in computer science, my first kind of real job, even though I was doing a lot of moonlighting jobs while studying, my first real job was at Microsoft, where I worked on the SQL Server engine. From there, I started a database company called SingleStore. It used to be called MemSQL, and I started as CTO. I wrote the first line of code. I had the experience of building a startup from scratch, went through Y Combinator, and lived in the office for a year until I got a place where we would wake up and code until we went to sleep. Then, I took over as CEO in 2017. The company had about $7 million in run rates, and I scaled it to — as a CEO, that’s how you measure yourself — I scaled it to about $40 million, after which I joined Khosla Ventures as an investing partner. Walking in, I told a famous venture capitalist, Vinod Khosla, that there was another database idea that I was really itching to build, which I couldn’t act on while a SingleStore because you can only have one engine in the company. As I was thinking about it, I already had the idea because I had been thinking about it for three years. And he’s like, “Why don’t you just incubate it here at Khosla Ventures?” Which I did. It took off really quickly. Now that’s the company. Neon is three years old, raised over $100 million, and we’re running 700,000 databases on the management.
Palak: That’s awesome and super impressive. You’ve worn a number of different hats. One of the things you said that caught my attention was that you had the idea for Neon for three years. When did you feel it was the right time to build it?
Nikita: I think I’m late. That’s what I think. This idea should have started when AWS introduced AWS Aurora, and it became clear that this is the right approach to building and running database systems in the cloud, as well as the separation of storage and computers. It was just such a good idea for the cloud in general. It doesn’t matter what staple system you’re running. Once that became obvious — and it became apparent in 2015, so I might be seven years late — I was trying to convince some of my former colleagues at SQL Server to go and build it while I was still running SingleStore. I said, “Every successful cloud service inside a cloud could be unbundled, and every successful SaaS service deserves an open-source alternative.” Those are the clear openings for building an AWS Aurora alternative, which I already knew was just such a juggernaut as ramping revenue really, really quickly.
That allows you to first counter-position against Aurora and have very clear messaging because people already understand what that is. I was sitting on that for a while and unable to act on it. I also thought somebody else would build it, and no one did. I see all these database attempts by building shared-nothing systems such as CockroachDB, Yugabytes, and CytosDB. None of them were that gigantically successful, but Aurora was, and I was like, “This is the right approach.” Because I was thinking about this for a while, the map in my head was already planned out. The downside is timing is everything. The opening is narrower, but our execution was very good because the plan was well-thought-out.
Palak: Technology leaders at companies have a number of different databases to choose from. You mentioned CockroachDB, Yugabytes, Aurora, Postgres, and even SingleStore. Where does Neon stand out?
Nikita: It’s important to map the modern database market. It’s roughly split in half for analytics and operational systems. The company that still reigns operational systems or OLTP is Oracle, but nobody is excited to start new projects in Oracle. If you take somebody graduating college and want to build a new system or app, they’ll never choose Oracle. Because of the commoditization pressure, they will choose one of the open-source technologies, which is MySQL, Postgres, or Mongo. People won’t choose Yugabytes, or SingleStore, which breaks my heart, and people won’t choose a long tail of niche databases.
Fundamentally, there are two major use cases in that very large modern database market. One is “I want to run my analytics,” a data warehouse and use case or big data analytics use case. And then there is “I want to run my app,” your operational use case. Those of nature on the operational side, it’s clear that Postgres is becoming the dominant force, and workloads are shifting into the cloud.
Now the question is who will own Postgres in the cloud and who will own the share of Postgres as a service? Right now, the king is Amazon, which is why we’re not inventing a new database. We are actually saying we’re Postgres and will be on the trend lines of Postgres becoming the most important operational database on the planet. All the trend lines are there. We want to be on the right side of history. The question is, how do you become the default Postgres offering? And that’s the question that we ask ourselves every day. The answer to that is differentiation. Like what differentiation do you bring to this world? And, what we think that differentiation is — it is the cycle speed for developers. Operational databases exist in the service of their users, and their users are developers.
Palak: That makes a lot of sense. You even touched on a consumerization of developer experience. I’d love to get your thoughts on how you build that 10X better developer experience.
Nikita: When we think about our ICP today, it’s a team of developers who don’t have enough skills to start building their infrastructure. That small team wants to deploy daily and optimize them for cycle and overall speed. Over time every team is going to be like this. What you want to do is zoom out first and see what the set of tools developers use today is. Some of them have complete permanence. They’ve become standard. Something like GitHub has a ton of permanence, and GitHub is not going anywhere. Every day, GitHub entrenches itself more and more in developers’ minds.
Standing up VMs and running node servers in those VMs will go away. Then you keep zooming in, and in there, you will see, “What do developers do every day when they build a feature?” That comes down to the developer workflow. In that developer workflow, people create a branch, and Git Sync creates their developer environments and sends a pool request. Inside that developer workflow, modern tools plug in there very, very well. If you take something like Vercel, it allows you to generate previews. Every pool request will have a Vercel preview. It’s like a copy of your web app but created for just this pull request before you pushed it into production. Guess what doesn’t fit that workflow? Well, the database.
The database is the centralized piece, and you give access to all your previews and developers for that centralized piece, but you run this thing in production. “Whoa, this is scary.” Right? What if some developer writes a query that destroys the data or does something with the database, so now you protect the thing, and databases don’t support that branching preview slash preview workflow? We’re changing that. At Neon, you can always branch the database, so that becomes an enabler. Of course, we are prescribing developers that use Neon, and we’re telling them how they go about building features and what the role of the database is as they build features.
We introduced the notion of branching. We understand migrations, but what I mean by that is schema migrations. We let developers instantly create those sandbox environments with full protection. If there’s PII data, you can mask the PII data and whatnot. Their local and staging environments are fully functional and have access to a clone of their production database. And you can create those environments easily with an API call or a push of a button. This is an example of zooming into the developer workflow and ensuring developers feel like this is built for them. It follows their day.
Palak: As you think about building, especially a modern database company, there’s pressure to have good performance and reliability. How do you build the culture of the company? Or advice for founders who are serving the developer market? how do you keep developer experience as a first-class citizen both in the culture of the company, the people that you hire, and the customers that you bring on? And the reason why I ask is I think Neon has just done an incredible job of that.
Nikita: There are a couple of things. One is developer experience, and the other is time, performance, and reliability. The latter is incredibly important for a modern database company. If you don’t have them, you will never succeed. The first one is the developer experience, which is your differentiation. You have it, you’re succeeding because the latter — performance, reliability, uptime — they are requirements, it’s necessary. But it doesn’t guarantee that you will be able to compete with Amazon because they have it. Let’s be honest about it. RDS and Aurora are good, reliable services. You can build a business on them. You need both. So how do you get both? Reliability is a function of a few things. Do you have a robust architecture and a good team to develop that architecture? Once you have that in place, it’s a function of time.
You won’t be reliable day zero. That’s why we took more than a year to be in preview, and we started with being extremely open and transparent with ourselves and the world of where our reliability is by showing our status stage and feeling a little naked when people see how reliable your system is. For a modern database company, if you’re not reliable, it attracts a good amount of criticism. And we got it. A good amount of that was in the fall, where the usage went up, and we had this hockey stick growth. We were onboarding, call it a hundred databases a day, at the beginning of 2023. And we started to push 3000 a day by the end of 2023. And so all hell broke loose. Then, if you set the priorities right when you write postmortems, you have a high-quality team, and you slow down your feature development when you need to in the name of reliability.
The architecture is key. If the architecture is off, you’ll never get there. Then, over time, you will get incrementally better and better and better, and eventually, the reliability will be solved. Now that we’re a GA, we feel good about the past history of our reliability and the systems in place, but we can’t, with a straight face, say we are a hundred percent reliable. I don’t think there is such a thing when you run a service, but you can get incrementally better, and at some point, you have enough history to take the calculated risk of calling yourselves GA. When it comes down to developer experience, there are a few things that are important to get right. One is the team like Jiro’s Dreams of Sushi; you must eat good food to make good food.
The tools that we use internally should be top-notch. The tools that we praise out in the world should be top-notch. We love GitHub, we love Vercel, we love Linear, we love super well-crafted, razor-sharp tools that get a lot of developer love. I’m going to call my competitor, which is like a big no-no, but I think Supabase is doing a great job in terms of developer experience. We’re not shy about talking about this internally to level up and potentially exceed the developer experience that they provide. I guess it’s emphasizing what’s important, which is relentlessly investing in your team, having good architecture, understanding what good looks like, and getting better every day.
Palak: You have a long history of working on SQL Server and SingleStore, focusing on reliability and winning those upmarket accounts and workloads. When do you start thinking about when it’s the right time to prioritize that at Neon versus focusing on net new workloads and really good developer experience?
Nikita: Heroku is a $800 million run-rate business. Half of this is Postgres, half of that is PLG Postgres, product-led growth, small teams coming into Heroku using Postgres, and the other half is enterprise. You can make a lot of money by providing the best Postgres in the world for small teams, but you don’t want to get stuck in the same place as DigitalOcean. By the way, there is no shame in building a public company, and it’s still growing very healthily all these things, but the stock does not reward DigitalOcean at this point in time. DigitalOcean didn’t go upmarket. We want to go upmarket, but we gate it. We gate it as the signal that we’re getting through our own users that are coming through the side door and just signing up.
We have a good number of enterprise customers, companies like EQT and companies like Zimmer Biomet. There’s a fairly long list of small use cases inside large enterprise customers that will obviously keep expanding, but we don’t want to spread too thin and over-focus on that. So, for example, what does it mean specifically? We don’t have a sales team. We don’t have a sales team, and in all our growth in the last month — we grew 25% months and months in revenue — it is all PLG. And so that’s what focus is looking like. We do have a partnership team and the partnerships team helps us with strategic partners such as Vercel, Re-Tool, and Replit, and making sure we give them the best quality of service possible. And now we’re also in the AWS marketplace and then working with some strategic partners.
Standing up a sales team is not a strategic priority today. We have a very good and thoughtful board that is completely aligned with us in that strategy. And so, how do we gate it? We’ll look at the signal of people coming in on the platform converting and what kind of teams those are. And we are also looking at the partner pool, and these are the things that will eventually tell us like, “Okay, now is the time.” And the book that created a very good impression on me was “Amp It Up” by Slootman. And when he talked about the data domain, they were in the technology development, and then they’ve proven their go-to-market motion in the enterprise because the updated means, obviously, enterprise.
They scaled their sales team very, very quickly. I want to live in the PLG world, and my 200 million of Heroku is telling me that there are plenty of dollars to be captured in this world, but track very closely what’s happening with larger customers driven either them coming in directly to the platform or through partners. And once that’s happening, I’m going to scale the sales team very, very quickly. What I want to avoid is a prolonged process of having a sales team and then keep scratching my head about how expensive it is and how effective it is. I think having a very tiny team early on proving everything, but then scaling very, very quickly is the right way to go.
Palak: It’s 2024, and everyone’s talking about AI. You mentioned you’re in two unique roles. Not only are you CEO of a company like Neon that’s raised $100 million, but you’re also a venture partner at Khosla. You’re uniquely able to weigh in. How big do you think this wave is going to be? Is it all hype, or is it something that is here to last for a while?
Nikita: So I’m a true believer this will change the world. It’ll change the world of software development and it will change the world of living. The question, how long this is going to take and are we going to have a trove of disillusionment sometime in the future? I don’t know the answer to this question, but I’m as bullish on this thing. I even think that we’ll live in a much more beautiful place — as in our planet — because AI will eventually drop the price of beauty down so much that it will just make sense to have it. And you know how in the seventies we had all this Brutalism architecture, which is super-duper ugly.
I was born in the Soviet Union and grew up in Russia, where Moscow was very pretty. A lot of cookie-cutter houses were built, mostly in the sixties and seventies. The reason they’re so ugly is that they’re cheap to build. I think we will arrive at a place where the cost of building things, software, or even physical things with robots and all those models will be in their robotic brains, will allow us to live in a much more beautiful world. The cost of design is going down, the cost of software engineering is going down, the cost of construction will go down. We’ll kind of re-terraform the planet through this.
Palak: One of the things that every enterprise is figuring out is that every AI strategy requires a data strategy. How are you seeing this impact at Neon, especially focused on net new workloads and net new projects?
Nikita: We’re potentially moving into OLTP, which is more important than analytics. What I mean by that is we just went from, zero cloud spend on analytics to, I think Microsoft is 20 billion. It could be 10, it could be 20, you can cross-check.
Palak: It’s a lot.
Nikita: This is your big data; this is your data warehousing; this is your data lakes; this is your training models and stuff like that. Training like old school models, just like ML and AI workflows of the past. We’re going to have more apps. Apps need databases, operational databases, modern databases. That’s not going to go away, that we’re going to have more apps and therefore we’re going to have more databases. The whole inference thing does not belong to an operational database. It’s all a new thing. It’ll be triggered by both. So that’s an additional line of spend.
Some days, I’m bullish on data warehouses, and other days, this will be older technology because it feels like we’re babying those data warehouses way too much. I’m observing by looking at the data team at Neon, where we’re obsessed with the semantic model, how clean the data is, and how much that represents. The data quality is very important because garbage is in and garbage is out. If you want to have the data in your data warehouse reflect the state of your business, you have to be obsessed with it. Today, people are working on that. I think tomorrow, that whole thing might be a lot more simplified where AI can deal with data being a little dirty because it understands where it’s dirty.
So, you won’t need to make a picture-perfect schema representing your business. I think the center of gravity might shift a little bit where people calling into AI, and I’m going to call out my friend and his tweet on Ankur Goyal and Braintrust Data, where he talked about what changes we are going to have for the data warehousing. He’s obviously looking from his standpoint, and he thinks evals will start pulling data closer to the model and start replacing observability and start replacing maybe even some product analytics at the minimum and then, over time, data warehousing there. I don’t know. It feels archaic to collect data around ETL jobs and run a SQL on a SQL report, but the alternative doesn’t quite exist today, so it’s still best in class.
But that whole AI thing should, some one way or another, disrupt those things where the quality and the full history of that data will matter slightly less.
Palak: Totally. Referencing Ankur’s tweet, it is almost like a real-time learning system of how the app can update itself using AI versus doing it offline, the human way, looking at the warehouse, looking at how users are reacting, et cetera, et cetera.
Nikita: Yes, and the engine of crunching the historical data should still exist. I still want to know how my business is performing. I still want to analyze the clicks, traffic, and product analytics, but how tedious it is today to set all those things. How tedious it is, that should somehow go away. A self-learning kind of AI system that ingests the data like kind a human brain and that thing becomes the driver for running those aggregations, that may change the center of gravity. Today, it’s firmly in the data warehouse or data lake; that is where the centerpiece of the enterprise data today is. We’re super eager to partner with all of them because that’s what the data is. You want to be close to that. Is it going to stay there or not? I don’t know.
Palak: Do you see there being tailwinds on the transactional side or how do you see Neon fitting into some of these new modern AI architectures?
Nikita: Look who’s doing AI stuff today versus yesterday. In the past, yesterday, it was a data scientist. I don’t know if we need that many data scientists anymore. Today, it’s app developers and prompt engineering and building RAGs. All of them are real-time operational systems. Every app still needs a database. So we’re not replacing operational systems; we are augmenting them. The people who are driving AI value in the company are mostly product engineers running stuff in TypeScript.
The whole Devin demo broke the internet, and we had an incredible amount of excitement about Devin and how Devin can add print statements and, debug your code and run full task. We’re actually using Devin already at Neon. We gave Devin a task to convert our CLI tool from TypeScript to go. It didn’t complete it, but it made enough progress for us to see that maybe it’s not quite there, but it’s almost as good as an intern. And then tomorrow, well, tomorrow, we’ll just do the task. There are so many tedious things that you want to do, like you see, look at the design, and it could be picture perfect. Replace this button from red to gray. We just ran something like this today, and then a human had to do this, but those things shouldn’t be humans doing this kind of thing.
Palak: What intelligent application are you most excited about and why?
Nikita: I’m mostly excited about Devin-like systems. In the whole AI world, we’re replacing humans. We’re not giving humans sharper tools. Software engineering is one of the most, it’s an elite job. We’re able to replace a software engineer, obviously starting from a very junior one, but over time, that’s an incredible amount of economic value because most companies are bottlenecked on the amount of engineering they can ship. I think that’s probably my high-end excitement there. And we’re certainly doing work internally on that front.
Palak: Beyond AI, what trends, technical or non-technical, are you excited about and why?
Nikita: Obviously, our developer experience is very on-brand for us. I think we’re entering a world where there’s just so much technology, and the way to stand out is the incredible degree of craftsmanship that goes into creating a new product or a new tool. I’m both excited about it and in fierce competition with Supabase. They get it, too; we get it, and we will see. This is a Jiro Dreams of Sushi kind of argument here again.
Palak: This isn’t a question, but on one hand, you have AI that’s potentially replacing the junior developers, and then you also have killer developer experience that’s making software engineering more accessible.
Nikita: Correct. By the way, if you make software engineering more accessible for humans, you are also making it more accessible to agents.
Palak: What unexpected challenge have you had where something didn’t go as expected, and how did you deal with it?
Nikita: The team was born as a systems project. Then, the developer experience was layered on top, and we couldn’t really move on to anything developer experience until the foundation of that storage was built. Those things were not on the core DNA of the founding team; it took us a couple of iterations to get there, and we’re not quite there yet, but we’re better and better and better that we see material progress. Something that for a systems engineer may look like, “Oh, of course, that’s a lot easier than doing the hard stuff like the storage thing.” But that turned out to be quite hard to get, and I appreciate the skill sets and the people who go and work on those things.
Palak: Any other parting advice for founders who are just starting the founder journey?
Nikita: I think the one that I would give is, A, don’t wait. I waited on this idea. I should have started this earlier. If you feel like you are ready— and maybe you feel like you’re not quite ready, but close enough—just go and do it. Then, go on the lifelong journey of learning and being passionate about your users and the technology that goes into making delightful experiences for those users. And never look back.
Palak: Awesome. Well, thank you so much, Nikita. I really appreciate you taking the time.
Nikita: Absolutely. Thank you so much.
