The Data Stack Show - 245: The Future of Data: Postgres, Iceberg, and Operational Analytics with Pranav Aurora of Mooncake Labs

Episode Date: May 22, 2025

Highlights from this week’s conversation include:Pranav’s Background and Journey in Data (1:10)Backstory of Mooncake Labs (2:05)PostgreSQL as a Force (4:47)Curiosity in Product Management (7:33)Challenges with Iceberg (11:12)Go-to-Market Strategy (13:52)Building Community Engagement (15:56)Importance of Feedback (18:26)AI Integration in Mooncake Labs (21:29)Innovation in data interaction (23:49)PostgreSQL and startup growth (28:41)Core component of business strategy (31:20)The Origin of the name Mooncake Labs (34:12)Upcoming Product Release (38:40)Connecting with Mooncake Labs and Parting Thoughts (42:49)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

For the next two weeks as a thank you for listening to the Data Stack show, Rudderstack is giving away some awesome prizes. The grand prize is a LEGO Star Wars Razor Crest 1023 piece set. They're also giving away Yeti mugs, anchor power banks, and everyone who enters will get a Rudderstack swag pack. To sign up, visit rudderstack.com slash TDSS-giveaway. Hi, I'm Eric Dotz. And I'm John Wessel. Welcome to the Data Stack Show.

The Data Stack Show is a podcast where we talk about the technical, business, and human challenges involved in data work. Join our casual conversations with innovators and data professionals to learn about new data technologies and how data teams are run at top companies. ["Data Work"] Before we dig into today's episode,

we want to give a huge thanks to our presenting sponsor, RutterSack. They give us the equipment and time to do this show week in, week out, and provide you the valuable content. RutterSack provides customer data infrastructure and is used by the world's most innovative companies to collect, transform, and deliver their event data wherever it's needed, all in real time. You can learn more at ruddersack.com. Welcome back to the Data Stack Show. We're recording live in Oakland, California at the Data Council conference, and we have Pranav Arora from Mooncake Labs here.

I've been so excited to talk to you. I saw your post on Hacker News, I guess, a couple weeks ago, read all about it, and when we saw that you were here, we knew we had to talk to you. So give us the quick 30 second background on you. Great. Thanks for having me. Super excited for this. I'm Pranav, founder of Mooncake.

I started my career at Microsoft, ended up at Single Store where I ran Grove product marketing kind of in the middle of it all, and started Mooncake with two people I met at Single Store eight months ago. It's our second attempt to simplify the data stack, building on the right principles with Postgres and Iceberg, and that's us. Awesome, so Pranav, before we hit record,

we're talking Postgres, one of my favorite topics. Love talking about that. So we will definitely cover that, but what are some things you wanna talk about? Yeah, I'm actually really excited to talk about how we're thinking we're bringing Mooncake to market, and how to stay true to principles, and how important they are in the data landscape in this shiny object world of AI. Awesome. Well, let's dig in. Let's do it. Pranav, so excited to talk with you. It is a true story

that actually on the way out here, a city in the Dallas-Fort Worth airport, Eric brought up Mooncake. He said, man, there's a really cool company. Then I was reading about, there's some really cool stuff with Postgres. Found on Hacker News last week. And like Eric said, when we got here, we realized you guys were here as well. So very excited to chat.

Tell us, let's just start, kind of give us a little backstory on Mooncake. This is, you said, your second attempt to simplify the data stack. Sounds like working at Single Store, you and your two co-founders, is that right? Two co-founders, all at Single Store, learned a lot of lessons there. So, yeah, tell us a little more about that. Yeah. So, Joe Chang and I met at Single Store. They sat opposite me, and they were the people who were there for a decade,

actually built a bunch of the stuff themselves. So Single Store was Joe's hackathon project that he brought to life. No. And the team. So from the evolution of Mems SQL to Single Store. And I was the product manager that had a bunch of questions on databases. I knew not much, but I knew how to ask questions. And over the span of a year and a half, I became extremely close with them.

And, you know, understanding what single store was good for, what's bad for, how to bring it to market. And it was a Thursday. I got a phone call from Joe saying, I have an idea. Would you join me? And I said, yes, Joe, I believe in you. What's the idea? And that is such a great, that is such a great founder per story. And he didn't even tell me the idea.

He sent me four things to read and he said, let me know if you figure it out. And it was like Sunday, I spent kind of the weekend reading these things and I was like, I'm going to try and impress this guy. And I said, this is what I think. And he said, wrong. And yeah, he's like, by the way, we're talking to Coastal Adventures on Monday. We're like, what? We've got to get a deck ready and stuff like that.

So that was the founding story of Mooncake. And before we knew it, we had, yeah, we started this company together. So the meeting Monday went fairly well. It went well. I think it went well because we're talking with the right principles. Right and I think that's something we're staying true to. So yeah, long story short we met at single store single store was trying to be a you know, all-in-one all TPN all that database for sort of modern H tab workloads and

really cool technology just extremely hard to bring to market on either end and I think one thing that we learned is on the OLTP side, Postgres is the formidable force as you were so excited about. And a big part of it is the extensibility of things. I would say app people or DBAs want to keep their Postgres and want to keep it unchanged, right? Like that's just the first principles. And what they want is consistent data

for transactions and analytics. That's kind of what they want. They want to deal with Postgres, one client, and I need consistent up-to-date data for all of my app-facing workloads. And then we spent a bunch of time with data teams and realized like there was this iceberg looking thing that's certainly gonna merge in all of these organizations.

And their requirements looked a lot like, I just want all data to be an iceberg I want my iceberg to be up-to-date and I want all data processing all app to be stateless serverless on iceberg Yep, and this was a pattern we saw over and over again And I think that's kind of what we're up to right keep your post person changed add a mood cake to it We create these iceberg tables for you that are always consistent with your updating Postgres tables. You can query them from Postgres and get, you know, sub-second analytics performance, top 10 clickbench performance, serve your apps consistent data. And for your data teams, you have up-to-date iceberg tables, kind of data nirvana, right?

So that's Mooncake. We're seven months old, so I think today is day 196. No way. It's not that you're counting. No, I am counting. Yeah. Yeah. Yeah.

And it's like 44 days to the next release, so we're kind of all hands on keyboard timing. Yeah. Good stuff out there. Love it. Well, John, I know you're itching to talk about the Postgres side and that kind of ecosystem there Well, I wanted to cover that but I want to touch on something else first and like what a testament to as a product guy

To be that close with your technical people that they would call you and be like, hey, we're gonna do something. Yeah, I Agree, that's very cool. Yeah, I appreciate that. I learned from some of the best people at Singlesworth. Yeah, some of my mentors and close friends still there in product roles. And the product role is really interesting because there's a lot of literature out there and like what it is, but still no one knows what it is. Yeah. And I think the way I lens my role, which could be wrong, and it's just my interpretation of it, is be really close to engineering and make them really excited about what's coming.

And I looked at my role as somebody that, you can never tell anybody what to do, but you can only make people really excited about your vision, how you want to get there. And I think that's like the line I flirted with, and I was very intentional about it, is how do you excite people to get to places you you need to and I think you're that layer to translate what customers want to actual velocity and excitement internally. Yeah

Do you have any like Secrets there or is it just kind of like an organic intuitive? Uh, i'm good at getting the engineers excited well, I think I used to be pretty careful initially of like, oh, am I asking the right questions or am I being, you know, like, like interesting enough or am I wasting their time? And I think like curiosity always wins at the end of the day, right? Like there are no stupid questions a lot of the times and I think people feeling that energy that you care really matters. So no secrets secrets honestly, just curiosity.

I asked questions and I wasn't scared. I got over that pretty quickly. When you're working with database engineers, they are scared. They have been scary since the dawn of time. Yes. We're really not perfect. That's great.

I'll do that. All right. So digging on the Postgres side, I shared before the podcast, spent a short set as a DBA over 10 years ago in Postgres, fell in love with it. True story. I think it was 9.0, read the docs like cover to cover over the course of like several weeks. So I got really deep in it. I mean, then one of the really neat things about it is this extensibility piece that the first time I realized that like oh you can like

type create extension and then a word and it can do drastically different things than it does out of the box and like it's such a cool unlock and a cool idea so so anyways I wanted to you up for like talking about the kind of extensible nature of Postgres like why that's even unique and then like how you all are leveraging it. Great question. I think this is something we learned again on Single Store when Vector Search became a workload that mattered. What most teams like companies like Single Store did a database like Single Store was like, we're going to staff this project to get whatever in an index within the database and get it super performant. That's what we did.

And it took almost 12 months to get it out there. And in that time, PG Vector already in the world. And I went on Neon and did Create Extension, PG Vector. I'm like, wait a second. Was contributed by the entire ecosystem, the entire team behind it. So felt that it's scar, I got scar firsthand. And that's kind of the light bulb moment in my head where I was like, wow, this is drastically different

capability technology that's packaged with such a elegant form factor. And I think that was like definitely like the changing point in my take. And I think going back to what we're doing, our belief is, again, Postgres is kind of where application developers are, and they want to keep it as Postgres and keep the Postgres as it is.

So being an extension is kind of our model. It gets how we get our foot into the door. It's ggmoonkick. It's an open source extension. And with two or three lines of SQL, you have a truly native columnar storage table in Postgres that's operational. You can run your point inserts, updates, deletes that can be synced with your row store tables.

And yeah, even on the demo yesterday, I guess like that was what I was trying to show. It was three lines of SQL for me to add an extension, create a column store table and keep that up to date with your row store table. So big fan of that ability. And I think that was a big thing we're betting on as well. And the community loves this as well. I think that's like a big part of the Postgres love that we're seeing.

And that's really exciting to work on. Yeah. So I have potentially a little bit oddly specific question, but it's just because it came up today. So with Iceberg, I guess, specifically, so you've got this like interface between Postgres and ice grid And what I've heard is like one of the challenges is around the data and compression Essentially, they give a ton of like tiny files and then like to optimize you have to go back and make bigger files

Part of that being a cost optimization of whatever your cloud store is and then a performance thing So I'm curious like it has that problem come up you guys? And what do you guys think about that? Yes, massive problem. And I think in my two days here, that's the one thing I've heard more than anything else, which is writing to Iceberg is painful. Okay, sure. And you hear it from different points,

you hear it from write amplification, in your case many small files, price performance of these things go up. Yeah, for the roof. The reality is Iceberg isn't designed for these kind of operational workloads, and especially keeping up with the Postgres table. What are you doing with an OLTP table is constant updates, deletes. And you're telling me that you can manage a lake-based thing with many small files and a metadata layer.

Iceberg totally isn't designed for this. We approached this with a thin layer on top of Iceberg. It's the first operational layer to Iceberg. So think of it as like Iceberg DB making Iceberg an operational column store. What I mean by that is a, it's just like a metadata. It's sorry. It's a layer with an in-memory column store with indexes and, you know, just like a thin layer on top of Iceberg that periodically flushes, sort of keeps data and then flushes it into iceberg. And that allows you to do real time ingest into iceberg, inserts, updates, deletes

as you would to an LTP system. And on the other hand, like fast queries, like sub second queries that you want in your applications. And that's, you know, what we learned is actually we're very Postgres opinionated on Moonlink and Moonlink will take Postgres TDC as the source but we're seeing so many requests for even MySQL for Kafka. Moonlink will be an open source in June this year. And we're very excited to see how we can extend Iceberg for more of these sort of real-time streaming, right workloads. And that's our take on it.

That's interesting. But I think the interesting part here too, is you're pairing with Postgres. So like Postgres is already pretty good at this operation. And because they're paired together, you can use both for the best of two worlds. Yeah, exactly. So that's kind of like a key design decision in what we're doing as well, which is based on that using Postgres for what it's really good at. Yeah, right.

And I guess the second time building a database from scratch, our thinking here is there are existing tools and systems out there that are just really good at what they're doing and learn to leverage them instead of trying to rebuild everything from scratch. I think that's part of this modern data architecture that you and I talk about becoming more and more building blocks in LEGO.

And they're very strong primitives today, which make it very exciting to work on something like this. I don't have to reinvent the wheel. On the Vectorize Engine pod with.db and data fusion, on calling the storage stuff with iceberg, there's such strong primitives to build a modern system on that actually make it really fun to work with. Yeah, sure.

So, so interested to hear about the go-to-market motion, you know, which you're still a fairly owned company, but it's funny we talked earlier today with someone on the show who said when people ask him about, you know, basically having an open source project and then trying to commercialize it, his advice is don't do it. You know, which is interesting. I mean, with the Postgres community, to your point is really interesting. So how are you thinking about, how are you thinking about building a business around the technology?

Great question. I think number one, build something people love. Yep. I have to prove that still. Right. So I'm obsessed about making people really happy with what we're building. And I think first step is if I have enough people that tell me they love this, I can really think about how to, you know, think of GTM in many different ways.

But I still think like the predecessor to all of these conversations is, are you meeting people where they are and are they really happy? Yep. I think the extension play is very interesting in mind share and getting people to try it and use it. And we have great partnerships with Neon, for example, which is like, it's a first-class experience there. So that's a great watering hole.

I think the play we're seeing, and we hope to continue to see, is catch companies early on in this journey, when they hit their first sort of all-app requirement out of Postgres. And because of the way we're building these things on Iceberg, keep them as they scale. Like there is no reason to look away from MoodCake and Iceberg tables at any scale.

So start with an extension or a single box Postgres, a thing that can write into Iceberg. And then as they did in EastGrow, we can scale this up and build a business around, you know, the distributed versions of these things. There have been many ways to share it. Yeah, but our thinking is it's all OLAP and all OLAP is gonna be Iceberg. So can we get time series, can we have real time OLAP and warehousing to just kind of all the Iceberg native and be that catalog of that layer that facilitates this,

with our real time capabilities. Yeah. How are you, what are the things that you're looking at to determine if you're building something that people love? It's a great question. There are a lot of vanity metrics out there actually like and I think that's I mean, GitHub stars. People love it. It's so interesting. It's so hot. It's like it's my first time trying to build open source stuff and then like I like was like avoiding the fact that the reality is GitHub stars but then very quickly realized wait a second it is GitHub stars, but then very quickly you realize, wait a second, it is GitHub stars. Which it means different things to different people.

GitHub star could be like, I think the bookmark is to go look at it later. Or it could be like, I love this, this is amazing. Exactly. I think the way I look at it is community engagement and number of messages I wake up to every morning saying X is broken, Y is slow, Z needs fixing. And a lot of what we did for point two was based on that. We spent a lot of time with customers and users trying to just figure out which direction do you want to take this. That shaped the three main things that we're working on for the next release. And yeah, I think people are really excited for the next release. People want to become sooner, that's the ice metric. And yeah, like number of people bugging me every morning. Yeah.

And it's actually like a weird feeling because when I was at Singles, you naturally had so many things to wake up to in the morning, but when you start as soon from scratch, you really have nothing, right? Like no one prepares you for zero to one, like no book or, there's nothing that prepares you for that feeling of like day one of working on this.

And you go on Slack and there's not. You go on your calendar and there's nothing. And then you like start looking at each other and like, how do we, yeah. Move. Yeah. So, what do we do? How do I get more Slack and Wizzicam?

Yeah. Swing it to games. Those are, I think, right now it's getting in front of the right people and enough people telling me this is great or this sucks. Even where it sucks is great. And I need X, I need Y. And that's the focus this year, right? I would get people to really be happy.

We're in the business, like the way we win is by providing out of the box magic experience for people outside Postgres. For the first thing they need outside Postgres and get them pre-empted. So if I'm betting a business on great developer experience and usability, prerequisite is do people love it. Yeah, for sure.

And the engagement thing is interesting because you went both positive and negative. And the problem is indifference. If it's silent, there's a difference.ifference right if it's like silent and like there's a difference like doesn't know you like it's a real trouble but if some people are like really like invested in like mad that something doesn't work like that's actually better than being indifferent right totally true and actually another thing i changed i changed my perspective on recently was like classic hacker news stuff you know there's always like hacker news

haters right and actually that's a great thing. You want people to have an opinion on what you're doing, whether it's good, bad, or bad. And I think the risk is when people don't have an opinion because it's kind of almost non-controversial or insignificant. So yeah, it was great to actually get negative stuff as well. You want to see those comments of like, why don't I just use like fill the blank or that like, you know, whatever the top comment was like Well, push this isn't push this is too slow for this and that's exactly what we're fixing

I'm gonna dig in a little bit on the extension piece because I'm actually unaware so I was familiar with them like from years ago like I haven't really kept up with that part of the ecosystem like how is that how is that evolved like how deep can you go with an extension with Postgres as far as like really like you know I mean obviously you're optimizing for stupid use case but how deep is that rabbit hole it's actually really impressive how strong the tooling is now with things like VGRX And you can build really powerful software as an extension. I think that's like kind of what I believe in it's still tough engineering work sure and

One thing that I learned is as a when especially with our initial design Where we try to introduce a standalone column stored TAM, table axis method in Postgres was you're actually competing against Postgres here, because Postgres is so wide. The surface area of Postgres is so large. And for me to have full coverage over everything that people want, triggers, the list goes on and on, would be a three year tough engineering. And I think that's like a big reason why we're doing this refactor at point two. So we can sort of avoid having to think of the extensibility and the surface area of these tables in Postgres. So yeah, the it's very nice tooling and ecosystem work

that's constantly being worked on in the Postgres world. The risk though is Postgres is so extensible and people use it in so many different ways. And in a way you're almost trying to fight the Postgres openness and extensibility. What is there, and I don't even know if this is a thing, but what comes to mind is like browsers and extensions. Can the extensions clash? Is that a common thing?

Where like I have this extension and they don't and something doesn't work right? Okay, we've had people trying to use us with like time scale DB, the extension, the color. Is that a common thing? Where like, I have this extension and something doesn't work, right? Yeah. People trying to use us with like, time scale DB, the extension, the camera. We've had people trying to use it with Citus and like initially it's like, okay, yeah, like something doesn't work. Right, okay, yeah. And the other thing is like, actually extensibility between extensions.

Like there's post-GIS and people want some OLAF capabilities with that. Those kind of things get, yeah, there are lots of end-by-ends and now it's just to take care of. It's tough building an extension actually. There's a lot of surface area to cover and do well. Okay. Let's talk about AI because you haven't mentioned AI yet in our conversation. How do you, like where, because that is, and you mentioned early on, this new shiny world, I guess you did mention AI, a new shiny world of AI.

Where does Mooncake fit into that world, and how do you think about that as you envision the future of the company? Yeah, okay, I'm gonna go kind of orthogonal to that and how we use Mooncake today. So I'm a five-person company, and the slides you were talking about yesterday were 80% designed by AI.

My website is two and a half hours of me on VZero. Yeah, so is mine. I'm just kidding. The demo I showed yesterday of that CRM was maybe three hours on Replet Agent, and I was like, the annoying thing was like, how do I connect Replet Agent with my Docker Postgres? Right. Yeah.

And I think companies like us are extremely lucky The annoying thing was like, how do I connect Repload Agent with my Docker Postgres? Right. Yeah. And I think companies like us are extremely lucky to be in a place where we can do as fast and as lean with the help of AI. I like very lucky to be building a company at this stage and yeah, don't take that for granted at all. I think the second aspect of things is you're seeing a lot of these new terms being thrown and I think no one has figured out what's concrete and not, what's real or not.

And I think that's the reality. And I look at AI as like, there's two real things I know and I've experienced as an end user that I'm happy to bet on. The interaction between AI systems and data will happen at the app level through Postgres, likely. And're already seeing things like Repl.it Agent and Neon and Lovable and SuperVeice, Postgres MCPs. So I think we're seeing this generation of vibe-coded, maybe stateful apps. And some people maybe don't care about the backend and are okay without seeing

a single line of SQL and I think that exists. And then the second line of innovation is kind of like AIBI from Databricks, AI cataloging, AI data engineering from Chatify. So like, I think if you look at where that's headed, that's kind of all on the lay player, right? You have data that's living in iceberg or Delta. You have a catalog on top of it with really rich metadata and you can get better questions and you can do data engineering.

So if I look at those two angles, I feel pretty confident about where I'm going to kick this head in. We believe data is going to either live in your Postgres or you're going to have a lake that's going to have a very strong catalog and AI systems will know how to interact with these two things. So am I innovating on the interaction of AI and data? No. But I do feel confident in the surface areas that we're're building on are the right places where data is gonna be at rest maybe? Yeah. For it to work its magic. But yeah, I'm very curious how it's gonna work and maybe I see two other things like a cursor for data being thrown everywhere and I don't think we've seen a cursor for data and then

like chat with your data being a three-year-old like kind of thing being thrown everywhere. I don't know if-old like kind of thing being thrown everywhere. I don't know if that's like a enterprise thing just yet. So those are two things that I'm curious when we will see. I think we can all kind of agree we will see in our lifetime in some form. I'm just not sure when. Yeah.

But I think it's actually really great and in your favor of like the layer that you're working at because like any much above this like layer, there's so much uncertainty about which way these categories are going to go and who's going to like, you know, essentially like eat you as far as like this, like consolidation efforts. I do think, well, you know, well, in some ways it's like, wow, like, don't you want to be an AI? Like it's like, there's other ways of like being like

kind of below the storm. You're like a little bit below the storm that I think it's a cool space. We're going to take a quick break from the episode to talk about our sponsor, Rutter Stack. Now I could say a bunch of nice things as if I found a fancy new tool, but John has been implementing Rutter Stack

for over half a decade. John, you work with customer event data every day and you know how hard it can be to make sure and implementing RutterStack for over half a decade. John, you work with customer event data every day, and you know how hard it can be to make sure that data is clean, and then to stream it everywhere it needs to go. Yeah, Eric, as you know, even server-side, and then send it to our downstream tools. Now, rumor has it that you have implemented the longest running production instance of RudderStack at six years and going. Yes, I can confirm that. And one of the

reasons we picked RudderStack was that it does not store the data and we can live stream data to our downstream tools. One of the things about the implementation that has been so common over all the years and with so many RutterStack customers is that it wasn't a wholesale replacement of your stack. It fit right into your existing tool set. Yeah and even with technical tools, Eric, things like Kafka or PubSub, but you don't have to have all that complicated customer data infrastructure. Well if you need to stream clean customer data to And even with technical tools, Eric, And the vision? It's a very good question. I would say not nearly enough, actually.

And I think there's just the reality is most days you're firing fires as much as possible or heads down just kind of like you need to move. Yeah. And velocity is the only thing we have. And it's very, I think the word I've heard a lot of mentors and other entrepreneurs use is like the wedge and every sort of means that wedge, right? Like that foot in the door. We all kind of have the same vision and how we're going to, you know, become a platform

and eventually like graduate to that. But what's that tiny slither of train that you solve better than everybody else? So I think right now we're in that phase of being extremely focused on that wedge. Right? What is that tiny is the bad word? We put the tiny slither of pain that we solve better than everybody else and make people happier. And from there, I think we all are very aligned on the vision. And those tend to be the fun conversations. The painful ones are when you're looking at that tiny wedge and you're trying to move the needle a little bit, but that's how it works. You have to move that needle a little bit each day.

The fun ones are when you're talking about how you're going to change the world. And that's typically Friday, you're going to have some beers. One question I have actually for both of you, because John, you're experienced with Postgres as well. So you mentioned, okay, how, you know, how are you using Mooncake? And I think about friends who I have who have, you know, built really successful companies, sold them, and they start with a really small team, and they spin up Postgres. And, you know, and what's interesting to me as I think about Mooncake is that in every instance where I think about

that founder, the builder, what you're describing I think just feels so natural to them in the way that they would think about it, right? Because in conversations about Postgres with them, a lot of their questions are like, I should just be able to do this, right? Like, it doesn't really feel natural that I can't do this, right?

But Postgres has certain, you know, the limitations that we talked about. Would you agree with that? I mean, I think that's one thing that's really interesting about Mooncake is I think about this people and if I had a conversation about Iceberg with them, they would be like, yeah, like what? I'm not gonna try to build this like

enterprise data infrastructure. But this is a way for them to operate Postgres in a way that feels very intuitive. It's just backed by, you know, like really powerful lake technology. Yeah, spot on. And that's a sweet spot we see fast shipping teams outgrowing a Postgres instance, right? That's kind of how every application starts to generalization, but that's how it starts. And you hit a wall and that's kind of when you like, oh, I need either a real-time database and a warehouse. I need these two things.

And that's when you need to bring on what people are good at setting up this and for you spend two, three months POCing this, figure out data modeling, data movement from your existing OLTP system into this real-time analytics system and then into the warehouse. So yeah, developer ergonomics is what we're betting on. And I go back to app people want a single Postgres that kind of does it all, right? They need consistent data and they wanna serve

applications with their client that's already set up, whether that's joins and being able to use all of these road score console tables, ensure that they're synced, that's what they want. And data people want, I want a Duck TV and I want, and I want data and iceberg. And I think, yeah, ergonomics wise, we hope to catch these early teams and make them, I guess, like not think about this, like I need to set up these complex jobs, keep

that kind of invisible and keep them safe. Well, what's interesting is, I mean, we were talking earlier with the guests this week about, it is phenomenally difficult if you're inside of a company and Well, what's interesting is, internally, right? Because, I mean, to your point, right? Like, even if you have decisions like this at Mooncake where it's like, okay, if we did a bunch of work to do this, like we would love ourselves in three years, but the reality is you wake up to all these requests

and you have to solve those and build your wedge, right? And this is, I mean, for lack of a better term, a sneaky way to give people, like, they just make the decision to have option value and then two years down the line, they're like, oh my gosh, like this was such a great decision and we didn't even know it at the time because now our data people, it's amazing. Right. And so it's like you're helping them make a decision without them even necessarily knowing

what the downstream impact is. We're considering that as like a core component of the decision. That's the key part of our GTM. You asked me like how I'm gonna make this a real business. I see that as being the real business. You start with companies where they are, you help keep them extremely happy. And there is potentially no reason to look elsewhere.

We bring them to the end state that they would have taken a couple engineers and a couple years of like, oh, I'm a total real architect to get to that end state. And yeah, it's a tough thing to sell today saying like, hey, like you're going to get there eventually. So providing that ergonomics where it's actually like really drop in with ease, mad ass here. Well, and when the need is there, the willingness to pay and urgency will be there as well. And the technology is instantly available that you already implemented.

So that's exactly how we're seeing. Yeah. Some of those that go in. Yeah. I think this is old, but acute pain for me. And I think probably still true. And the Postgres ecosystem, like we, like the app we were doing, we had like transactional load and then we had this user facing reporting feature that was like essentially infinitely customizable

and they could like build whatever like crazy things to like get results. It was awful on the databases like you would imagine. And the things that we did to not have that workload moved off of Postgres was ridiculous. Like the thing like they're like spinning up like replication servers and trying to like route like read traffic here. We did all these things around that. So I really identify with this, developers absolutely want to stay in this single,

one for familiarity, I think is part of it, but another is like, there's a simplicity to it. I think it's very attractive, totally agree. There are two key workloads we actually see from customers. One is like filters on very wide tables. I think it's very attractive. There are two key workloads we actually see from customers. One is filters on very wide tables. You won't think of that as an OLAP analytic workload, but it's actually a work with design for common storage.

It's very hard to have indexes on such wide tables that just blows your write performance. You look at a lot of these new AI companies, you start with, oh, I get product market fit, I get traction, and then my customers want dashboards on how people are using this tool. And that's where they go, like, what you're doing, I'm going to need a real-time analytic database and kind of spend three months data modeling. And especially in that really high configurability, like personalization piece of like, each person wants something slightly different, and want to like enable some really like Deep nested filtering or whatever I mean those workloads like and then you're producing these really nasty queries on the back end That poor DVAs have to go. It was back when they had to go troubleshoot and make them faster

Yeah, old acute pain. That's like a great name for a blog post Acute pain that's like a great name for a blog post Or like a physical therapy practice PT practice. Yes. You smell the cute with two different ways Okay, we I we have to ask mooncake like we're the new Okay, this is another funny story in college college I tried to start a company called Mooncake. It was like not related data at all. It was actually like in Damlin, like sports betting.

But yeah, like when we came up with the idea, I was like, we need a fun name. And I thought, why not Mooncake again? And you're like, I have this LLC, I haven't used it in a while. Do you want to use it? So that's the real story. But the actual like funny story, not funny, but the real, like the nice marketing story is you never eat a mooncake alone. A mooncake is like an Asian delicacy. And the tiny mooncake is like 2000 calories.

And a mooncake is always meant to be shared. So you grab a slice and you always just, you never eat a mooncake alone. And we're building in the open, we're building for everyone to share. It works pretty nice from a marketing standpoint. The slice of wind cake. I like it.

And you have the, you know, built-in emojis. Exactly. The emojis are super important. And Apple does a great job. It's got like 3D rendering of it. Totally. Well done, Apple. So great. ring up and like, totally.

Most of my graphic design stuff is always one of those mid-journey-esque things. And then you chuck it into Runway ML and it generates a video of it moving around. So you said you tried to start a company in college. Has it been a dream to be an entrepreneur? That was something that was inside of you, you had to give birth to something? Yeah, I would say I never put pressure on it. I think a lot of people do put pressure on it. This is my colon and how do I get there in X amount of time and stuff like that? I never put pressure and I think that worked really well for me because it came naturally

it came from a point where we saw a real opportunity and we're solving a real pain and I think I'm very lucky to have the approach that that way because I think that's a path that a lot of Path that a lot of people fall into which is I have an itch. I have a ticking time Yeah, and I need to do it and I like to see this meme on that a lot of people fall into, which is, I have an itch, I have a ticking time, yeah, and I need to do it. And I like, I see this meme on Twitter a lot, which is like, there's no one more stressed about time than like an average 25 to 30 year old, right? You see, you think you know that's a thing.

Yeah, yeah, yeah. Yeah, I would say, I've always wanted to do something like this and I'm really enjoying it, but I didn't put pressure on it. And I think that was a good thing. Yeah, yeah. Okay, I'm interested to know like, did you work in databases at single store? Were you excited about doing a startup in that space? Like had you fallen in love with that general space? You know, because sometimes you go work at a company, you get really deep into a domain

and it's okay, this is cool, but I don't know if I want to actually, you know, because sometimes you go work at a company, you get really deep into a domain, and it's okay, this is cool, but I don't know if I want to actually, you know, build a company in the same space. I think company building is agnostic to what you're building and how you're building. I think people like, again, draw frameworks for like, if you're building B2B, B2C, infra. I think it's, again, it's pretty agnostic

to all these things, and it comes down to like, intuition. Like, are you solving a real problem for real people? And do you know how to make people really happy? And people vouch for your product, right? That's kind of like the principles, whether it's an app or an infra. And I like that process a lot. So I would say, it wasn't too picky on space.

Data became really interesting to me because we had this conversation earlier, it's all about trade-offs. And I think in building systems, especially data systems, you realize the decisions you're making are the trade-offs you make and that's why I keep going to the principles, right? What do you, like, it's very hard for you to go halfway through building this and say, like, actually this principle is wrong and I need fast and, and I'm

showing you. Yeah. In a way it's like very principled thinking where you are making these trade-offs at the right time and constantly thinking of decisions as like, what are you giving up for what you're getting? And I think that's a luxury we have actually in the space that a lot of spaces don't have because like it becomes much more nebulous if you're building a consumer app, for example, like one of the two notes.

So it's more structured thinking here that gets you to building something great I think and it's a good flex of like that I guess like first principle thinking lack of a better word but yeah yeah it seems like a logical path you can follow to get to a decision. Yeah it's done. Yeah one thing I'm interested to hear if you can share a little bit you said you'll have another release coming in 41 to 44 44 days. Okay, not that you're kind of Okay, so today is April 23rd this will release in a couple weeks that'll be even closer to release You've gotten tons of customer user feedback that it sounds like are working on things for this release Can you share I think you may mention any kind of three core things that are coming? Yeah. The first thing is the most important thing, which is creating a column store table that's always synced with a pro store table.

And that just being one line of SQL. What that replaces is a CDC tool and an analytic database that you need to keep in sync and ensure that there's eventual consistency between them. So that's a killing feature. And the beauty of how we're architecting it is actually the columnster table are iceberg tables. So in doing so, we're extending iceberg to be an operational columnster, which is pretty hard to do. A second thing is being very opinionator on the use cases we want to really go after. And I think the two use cases we see are what we call sort of real time or operational analytics. Hence we want to provide the ergonomics of I have my postgres row store table.

I have a column store table. These two things are always synced. I keep my writes into the row store table. I just query this new column store table and it's infinitely faster. No data modeling. I don't need to rewire these queries. So being opinionated on real time analytics and the second one is time series workloads

where people want to call them a compression, people want data to be an ice break actually, and people want to be able to just point and shoot data through Postgres instances to get them. So those are the two use cases where providing really nice usability and experiences around. And then the third thing is continuous work we're doing to bridge the gap to Postgres. So things like indexes, partition tables, types, making that experience really just

feel like magic. And yeah, with those three things, you know, the onboarding to somebody on PG Mootcake should be a conversation of hours, days, something I can hop on in one or two meetings and gather it over the line, over maybe a two week back and forth process. So really build that killing developer experience that we're betting. Right, so.

That's awesome. Yeah, I mean, we're, feel privileged, I think, to talk to you at this point, and we will have to have you back on the show in six months, eight months, a year, kind of see how things are going. I think we're, yeah, we're super bullish and excited. I'm really excited too.

And I'm gonna listen back to this in six months. Yeah, yeah. I did this service, and this serves as a journal of what was going on. Totally, yeah. And thanks for having me. We'd love to have you back on the show too. We wanna catch up and yeah, to follow your journey. I really appreciate it. This was an amazing experience. My first time doing something like this, and thanks for having me back on the show too. We want to catch up and yeah, I really appreciate it

This was an amazing experience my first time doing something like this and I highly recommend people coming on Cool well Eric Tony any final questions closing thoughts If you hadn't started Mencake, what do you think you would do? Like what problem space would you I mean you, you said, you know, sort of agnostic, but, you know, let's say you left single store or, you know, for some reason you need to do something else. Where would, what would you do? What problem space would you explore? Good question. I would explore like this new type of venture backed business

that's like rolling up old school businesses and sort of like AIifying them. Just like, I'm curious what that really looks like. I think it's a very interesting take on both venture, right? It's a new form of how venture money is being spent and it's an interesting business problem as well. Completely orthogonal, but I'm curious how that'll span out in the next like 18 months.

And a lot of these massive rounds to roll up these firms. So maybe that, I actually haven't given that too much thought. Yeah. You have plenty of things to say in your play. I wake up, I actually like, that's the thing they don't tell you about being in this stage is like, I go to bed thinking about mooncake and then I wake up thinking about mooncake. It's just like, here, wow, isn't this...

Probably dream about it some too, maybe? Yeah. A lot of Mooncake. Yeah. Whenever folks can find you on GitHub, where, website, I mean, how can they connect and learn more about? Yeah, so we're at mooncake.dev. We have an active GitHub project called PGMooncake, we'd love support there.

And we also have a community which you can find on the GitHub repo on the website. And it's that community that we kind of talk to most of our users and interact there. So yeah. Star on GitHub. Yes, please. I'm going to see the vertical.

Yeah, no need to star on GitHub. Do the spot-pots. Exactly. Well, Renan, thank you so much for joining us. It's been awesome. And we will get you back on scene. Great. you so much for joining us. It's been awesome, and we will get you back on scene. Great. Thanks so much for having me.

The Data Stack Show is brought to you by Rutter Stack, the warehouse native customer data platform. Learn more at rudderstack.com.