Eric Anderson: Hi everyone. I wanted to give you a quick update on Contributor. We are now 70 episodes in. We publish almost every two weeks. We have now a great group of open-source founders and some of the fans of those projects, and I need a community manager. If you want to help us out to inspire and organize this group of folks, look up by our email on contributor.fyi. Ry Walker: We just need the truth. If it's half as fast, fine. It means that if you just use a computer that's twice as fast you can achieve the same thing as the other guys but you don't have to leave Postgres. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open-source projects and the communities that make them. I'm Eric Anderson. Today we're talking about Tembo with Ry Walker. I feel like Ry is an old friend. We've been talking for years now about open-source and companies all along the way. Ry thanks for chatting today. Ry Walker: Oh, thanks for inviting me, I'm excited to talk. Eric Anderson: I feel like today's going to be all about Postgres. But ostensibly the project will be Tembo or Tembo Stacks. Maybe you could quickly, Ry, tell us what Tembo or Tembo Stacks is. Ry Walker: This is all coming out of the meme of hey, use Postgres for everything, right, which we've seen in recent years. There's some great extensions on it that stretch it in different ways, and it's been stretched in all directions now. It's like what is Postgres? What can it do? Most people still just use it ... I'd say 99% of users use it as a transactional store, and 99% of users don't really use fun extensions. It's interesting that it's got all these capabilities but most people don't use them. And part of the reason I think that is because the commercialization of those stretches are immature still. A lot of it's just straight-up open-source which is pretty hard to get people to pay attention to your project, especially in the number of millions if you're just the side project. We just saw it as an opportunity. Last year I opened my eyes, I took the ... I forget what the Matrix thing ... The pill that lets you see everything, I took that one, I think it's the red pill, and realized what's been going on in Postgres. And I was like, I've been using it since I can remember, it's like I grew up on Postgres, and yet I didn't really know it. Most developers are in the same boat. Eric Anderson: So Tembo is this Postgres platform, you run Postgres for people, but you also offer them a bunch of extensions that are easily available. And Tembo Stacks is an open-source project that allows you to do a lot of this. Ry Walker: Tembo Stacks is the data plane. We're building a managed service. The table stakes for building a managed service in 2023, 2024 soon, is incredibly challenging. I don't know if you've ever tried it, Eric. You have to have IP waitlisting, you have to have auto-scaling, you have to have ... There's probably literally 100 things that ... People want RBAC, they want fine control. There's 100 table-stakes features we have to build, and we're building a managed service. I wish we could do BYOC, bring your own cloud, already but that's down the list of features. Basically, we wanted to give people an outlet if they like what we're doing but can't use our admittedly shitty cloud service in the first few months. A way to use it ... A way to access everything we're building. Well, not everything. Our UI is in our control plane which is not open-source. I mean, basically, the guts of spinning up a Tembo stack is ... If you use Kubernetes you can use Tembo Stacks to spin up our backend solution. Does that make sense? Eric Anderson: No, it does, it does. I'm trying to figure out where we take it from here because not everyone who's listening has swallowed the red pill yet, Ry. Ry Walker: Yeah, they have. Eric Anderson: We have to bring them up to speed. So Postgres has all these ... It's much more than a database it has all the extensions. What can you do? Open our eyes? Ry Walker: Machine learning is hot, vector databases are hot. You as an investor you probably already invested in three or four of those. No, I'm kidding. I actually think the bar for building a product now in 2023 is you need a transactional database, you need to provide some sort of charts to your users which means you have to have some sort of analytic stack in a data pipeline to create aggregations off that data that you're collecting. You need to probably have a message queue of some sort. You want to basically take an order but tell the user "Okay, we got it" and then process it. Eric Anderson: For some long-running processes to download capability, whatever. Ry Walker: Having an ML algorithm inside your product is absolutely mandatory now. It's actually negligent not to in some ways. Basically, wherever there's analytics there's data, and wherever there's data you can build an ML algorithm instead of just a simple chart. I was working on OSSRank last year, I think we talked about it. OSSRank's just like a website that I was building personally using Ruby on Rails. I was doing a ton of data crunching and I was like do I need to go spin up Snowflake? I'm running these queries that are beating the shit out of the database every hour and it affects the front-end user experience, but solo developer it's like eh. Then I have to build a data pipeline. That's actually when my eyes opened to Postgres because I'm like wait, isn't there something like ... Someone's done columnar inside of Postgres. I think you can have a columnar table instead of a row-based table inside of Postgres. And then I started researching that and I realized it was built by Citus, and then it was forked by X, and then it was forked by Y, and it's unusable. Basically when something exists but it's been forked three times and you're not sure what the right fork is. Just as a developer you walk away from that. We want to pick a winner for what the right columnar is for everybody, and build it in, and just make it a switch. Tembo basically gives you single click installation of these extensions and single click enabling of the extension. It's sort of a two-step process. You could say it's two clicks to install and enable. We've basically bottled up all the technical complexity of this. The other thing that happened is you could now build Postgres extensions in Rust, and Rust is the most beloved language I think. And now pairing it up with the most beloved database to me means Cambrian explosion of extensions. I think the situation's going to get far quote worse before it gets better. I was like, who's going to commercialize this giant pile of things? And I looked around at the existing players and no one seemed to have that strategy. It's a suicide mission because it's a support nightmare. I'm like okay, well let's do that then, the hard things. You want to do the hard things. We're building a company that we know that there's clouds ahead but users will get value. Eric Anderson: With Postgres, I can have an app DB which is what everyone's using it for, but I can also have this analytical OLAP-style database, a cloud data warehouse, if you will, Postgres style. You mentioned a vector database we're familiar with. Say I want the basic ... Or not the basic but the full-fledged app we discussed. Do I have one database that does all the things, or do I have several Postgres's that are each specialized? Ry Walker: So that's the challenge is you could try to lump them all together but that's a no-no because you don't want analytical workloads getting in the way of transactional workloads. What we would really want is a way to have them work together but in isolation. Feel like they're together but the compute is separated. Citus basically built a sharded Postgres system that has a facade at the front that delegates all the queries to an array of backend Postgres's, right? If you run a query that hits them all it'll actually aggregate across all those and return it. My thought is, let's build a similar facade, but what's behind it they're not all shards of the same database, they could have entirely different configurations. A message queue has a different configuration, best case configuration, than transactional or OLAP does. Even the hardware shooter could be different behind each of these use cases. Our vision eventually is that you just start ... I mean, ideally, it'd be like how Google AlloyDB and Aurora work that where you just run queries and you don't have to think too much about it, but in the short term you do have to think a little bit. We're making it really easy for you to spin up each of these stacks and you have control over the resources. And we want Postgres to achieve this where it just feels as if it's got specialized workers for the different uses. Eric Anderson: I mean, that is the ultimate vision. That's what the cloud database should offer us is that ... I don't know what complexity is happening behind the scenes, I get a single API. It's like GPT-4 where it's like who knows how many models are back there? What kind of magic's happening? Ry Walker: That's right. I think we all want that. But I think ideally, we don't want that as a proprietary product either. Eric Anderson: No, no. And we probably also want the, I want to have control over my infrastructure and know how this thing is working option as well. And so that's where you're starting. Ry Walker: And I'm a big open-source person, I'm a big fan of it. But that's the challenge. Chat GPT-3, five, four come out, and then boom, suddenly it's LLaMa, LLaMa, LLaMa. I would not think to build anything on OpenAI just because they could change their pricing at any time. All the reasons we don't love being locked into a vendor. Looking at the history of Postgres, there have been attempts to do true open-core company, and a lot of those attempts get thwarted later on by executives who want to harvest instead of grow the open-source projects that they're working on. For example, multi-master in Postgres doesn't exist in any open-source fashion. It has in the past but then it's been taken away. Those projects get canceled because they're so strategically important to a given company. And to me, as soon as you do that you've doomed your company to be in that proprietary category. So I don't know. I just think that if we do a pure-play open core, keep me in charge forever so that we don't make any stupid executive decisions later on to shoot ourselves in the foot by changing the license, then we could build something great. This community and the traction of Postgres is literally unbelievable. But there are 100 competitors that we're going up against so that's the con, right? Eric Anderson: So Ry, let's also fork the conversation real quick and talk about extensions. What are these things exactly? And they're all over the internet. And tell us about TRUNC and how you can bring some sanity to the world of extensions. Ry Walker: I mean, one of the value props we want to offer our users is we'll allow you to use any extension, even a custom extension that you've just written or that you're working on, right, you should be able to run that in the cloud. You can run code under development everywhere in the cloud, right, but not in Postgres. In Postgres, if you're working on extension you're stuck to local dev, there's nobody who's letting you run their stuff up in the cloud sharing it with team members, et cetera, et cetera. Eric Anderson: Because most managed Postgres are like "Here's our version stack and you're just" ... That's it. Ry Walker: Here are the 75 we allow, they're all tried and tested. Basically, enough customers complained that they added those but not enough customers. So we just want to basically support any extension, all extensions including your own private extensions. And so for that we're like okay, we want to have a universal installer for Postgres. We're doing this for Ubuntu. Ubuntu and Postgres 15, we have to start small. But we've got 150 extensions that work really, really well, are validated as working. There's about 50 that we thought were working but aren't so we've- Eric Anderson: Oh, wow. Ry Walker: Most of our competitors have 75 or so, we've got 150. And we're just basically just dealing with ... We're just wrapping inside of our CLI all the BS that goes into installing an extension, at least on Ubuntu. On our architecture too there's actually ... We're learning all kinds of stuff. Oh, actually, if you build it for this architecture and try to run it on that architecture it fails. There's a lot of places where someone's instructions ... If a developer just wrote out, "Hey, here's how to install this," it is never complete because they didn't take into consideration your operating system or not all the operating systems. So we want to have a matrix of all the operating systems, all the Postgres versions. We're going to have these tests running all the time just confirming that they work or that they still work. And so that's what TRUNC is. It's also a place to discover extensions though. It's very basic to start with. We got the basics up and running. And it's just basically serving our product mostly right now. Eric Anderson: Got it. So I can use TRUNC as an online registry, go discover extensions, but I can also develop my own extensions. Ry Walker: You can publish them with TRUNC, you can build them, and you can install them. So it's got a CLI behind the scene. Similar to MPM install, we want that experience for Postgres. I don't know everything that happens inside of MPM install but I imagine there's sometimes some hard stuffs happening inside that command. Luckily as a developer I don't have to worry about it, there's a squad in the world who's doing that. Eric Anderson: I'm sure some people are hearing this and thinking, is Postgres Vector DB as good as another vector DB? Ry Walker: That's a great question. I want to discover the truth just like every other developer. I am a developer. I'm chief developer of the company more so than chief executive officer because I'm not ... I'll never be a great executive but I am a longtime developer and so I want to know too. To be honest with you, I still want to know how to get that columnar or table, I want to know how to do that. We don't even have a guide yet, okay? Oh, okay, so you're a developer and you want to have one table be columnar, here's the guide, right? We're still working on that. It's that hard to do all this stuff. We're working on five stacks. And then we want to basically compare them to what I call North Star competitors. How does this columnar solution in Postgres compare to Snowflake or ClickHouse. Same thing on the pgvector stuff. How does it compare to Pinecone or the various startups there? We just need the truth. If it's half as fast, fine. It means that if you just use a computer that's twice as fast you can achieve the same thing as the other guys but you don't have to leave Postgres. So that's the exciting discovery for me. As long as it works, and if it's about half as fast, it means I would prefer to keep it in Postgres rather than buy another vendor. As we all know, buying a vendor it can be pretty nice in the early days of a startup, but every year after that it gets worse and worse as they start hiring the sales bros and they start coming at you to expand, and all that stuff. I just think most devs, most CTOs would prefer less modern data stack vendors if they can get there, especially one that has a philosophical agreement with their developers. I feel like that's what Heroku was, man. Heroku was so in my tribe and I just ... I never had to talk to anybody, all their decisions seemed on point. It was clearly run by devs, and we want to do the same thing here. Eric Anderson: You've gone into the deep end on these extensions, even built a few of your own, is that right? Ry Walker: I personally haven't but I've ... Our team has written a couple, maybe three or four now. One is PGMQ which is the heart of our messaging stack. So we're like "Hey, let's build a" ... "Let's bill out a reticence competitor using Postgres." What Redis does is to me a subset of what Postgres does. It's like a very specific narrow database that's hyper-optimized for its workload and so we set out to do a similar thing using just Postgres and configuration. We've got some benchmarks coming out for that in the next few weeks. Actually, I don't know the results of the benchmarks yet. We want to just tell the truth. There's no benefit to lie here. Like I said, even if it's not as fast at least everyone will know. We don't need to be the fastest, as far as I'm concerned. I just did a post on LinkedIn today about this Leatherman multi-tool. It has the scissors in it, and I use those scissors so much more than ... They're not the best scissors but they're right here. Give me a tool that can handle the start of something and we can always go to a big vendor later if scale's a problem. I don't think it will be. Eric Anderson: Being that Postgres can do all these things, Postgres starts to feel less like an application database management system and more like some platform, general-purpose computing tool. What is Postgres to you now? If we had the proper vision of what this horizontal broad general purpose thing is, what do you call it? Ry Walker: I think data platform's a pretty good word for it. You could call it database platform because it is definitely database-centric. I mean, you can run Python scripts, you can run Rust scripts, you can run even Java code. You can run a ton of stuff inside of your Postgres running container too through these extensions. Again, a lot of these extensions aren't available on your favorite cloud, they are available on Tembo. We have to write some guides on what the hell can you do with all this stuff. I mean, okay, now let's talk about sidecars. All right. This is a big part of my vision too. All right, I'm using Rails to build this little OSSRank, and now I've got these scripts that I'm running in Modal. Do you know Modal, by the way? Modal.com? Eric Anderson: Yeah. Ry Walker: Erik Bernhardsson, great service. Eric Anderson: Modal app. Ry Walker: Those guys crush. And I'm writing these Python scripts that run on Modal for OSSRank and I need to create a new database. And I'm like okay, I guess I'm going to go over into my Rails app to generate a migration to create a new table so that my Python app can use it, right? And that seemed weird. I'm like why shouldn't the database be in charge of migrations, not an app framework? We want to have the equivalent of Rails migrations inside of Tembo, it'll all be open-source, of course. I just think the database is the center now it's not the app. It used to be on Heroku apps have sidecar databases. The way I'm seeing it now is that the databases should have sidecar apps. That's a feature we're working on right now is the idea that you can run a sidecar process next to your database, whether it's ... pganalyze is a little tool that you can use to analyze the performance of Postgres. There's this thing called pg_timetable, which is a ... Essentially you can run a DAG of work controlled by Postgres but it does require a sidecar to run. So we're going to add sidecars. Once we had sidecars, man, this thing could do ... It could actually be an app hosting platform too. Again, the database is the heart, apps are appendages, and ... That's exciting too. Let's say you're building a database, okay, and you got a little app where you're doing your migrations and you need a couple of dbt jobs to also be running on ACRON. We'll have a dbt folder, you just drop them in there and we'll run them, you don't have to think about it. In that case, now it's doing definitely more than just database I think it should be data pipelines. But the cool thing is, if all these databases are literally ... They're sitting back to back against each other, there's no latency. We're doing it now. You can use something called the Postgres Foreign Data Wrappers, Postgres FDW, to query another table in another database. And if they're sitting right next to you there's literally no latency. We're doing all this now for our own internal data warehouse and stuff. I don't know. It's cool that we're able to build something, I think, that is very new and modern with something that is very old. I mean, most of the code in there is probably new. As you know, open-source projects like code churn happens and really ... Well, it might be a 26-year-old project that's probably pretty damn hard to find any code that's lived that long inside the project. Eric Anderson: It does feel a little bit back to the future. It's like the new SpaceX rockets look like the Saturn V. Forget the shuttle we're going back to just rockets but now they are reusable or something. Ry Walker: Or like a mainframe computing. I'm basically saying, "Put all your data in one spot and all your applications right there too." I just think there's a lot of efficiency to that. That's what I want as a developer. I don't love this new modern data stack where my data's smeared all across the internet and it's just really, really hard to access it. You've got to build pipelines and buy vendors to get your data back and that sucks Eric Anderson: Your point on the database being the center. I actually had a guy, a venture investor from Goldman, ask ... We were talking infrastructure and databases and he was like "Aren't there too many database companies? I mean, do we need another database?" And I was like "Well, if you realize that databases now are much more than just databases, they're application platforms, and they basically" ... "With the cloud they represent all of compute." In that sense, the market size for database is the market size of AWS and it's huge. Ry Walker: Including the compute is what you're saying. I agree. Eric Anderson: Right. Ry Walker: Snowflake's trying to get you to bring your compute. They have all these extra things. They're trying to get you to run your workloads there because that's how they make money. I really want to protect Postgres from Snowflake, that's part of my mission. I talk about Snowflake a lot on LinkedIn because they want to use Unistore, or whatever they call it, to be transactional now and they're proprietary. I definitely don't want to see a reversion to ... I don't think there's any chance it'll happen. I just think a competitor to them needs to emerge that is trying to play the same playbook as them but using open core instead of proprietary. I mean, that's a big, big enemy to take on. Our other competitors are AWS, RDS. That's a huge company. Especially RDS, there's not a very big motivated team innovating at RDS, they're working on Aurora or whatever. So I just think on the open-source side of things there's some great new companies too. I mean, again, I got competition like 360 Degrees. I think our strategy's different than the other new guys and it's hopefully powerful against the old guys but we shall see. Eric Anderson: Why do you do this? What compels you to go on this, as you called it, suicide mission? Ry Walker: I also call it the startup Mount Everest. Why do people climb Mount Everest? It seems dangerous, it seems scary. That's one of the reasons they're doing it. I think that's one of the reasons I'm doing this too. Once I realized that there's this dangerous path up to the top of Mount Everest ... Someone figured that out at one point and they're like "We got to go, we got to try it." I had a good outcome with my previous company. I was able to sell shares in secondary and basically have ... I was just reading on Twitter today someone was like "How much money is the right amount to be just done," whatever? And I got that amount of money but then what? I could go golf, but no, I want to take what we did at Astronomer and ratchet it up a few notches because I'm still ... I just turned 50, I've got a lot of years left of working in my ... And it's fun. It's like building startups, I could have just become an investor, angel investor, whatever, but it's not direct enough. I just found myself with the itch to build. Fortunately and unfortunately for me, Ethan Batraski from Venrock came knocking on my door and had a similar vision. He's like "Hey, I'll give you five million bucks to go try to climb the mountain." I'm like "Oh, shit." I'm like "No." That's pretty tempting as a founder. It's like a napkin sketch idea and you got money promised. I'm like "Let's see. That means my fake net worth goes up to what?" I was tempted by the commercial opportunity. It's a tough battle, man. It's going to be really hard to win customers because there's so many companies already out there. And most of our users, potential users, haven't taken the red pill yet. That's the problem too. So they're just like "How can we wake them up and get them" ... Again, product quality is a big part of that. They'll wake up once the product is good enough to wake them up. Eric Anderson: Now, let's say you've got some people semi-converted through this conversation. Now we'll shift into call to action. How can they explore the new world of what you're doing? Ry Walker: Well, right now we have no pricing, we're working on that. If you just sign up at cloud.Tembo.io you get free Postgres so that's pretty nice. We're going to try to price it lower than RDS, which is challenging, but I think it has to be that way. We've got a lot of functionality already, we're missing a lot still. If you sign up I'll share with you my roadmap. I'm being very open. What's the term? Like an open company. I don't know. I could try to hide my roadmap from everybody. The only people that really care about it are my customers, my competitors. Eric Anderson: You're building in public. Ry Walker: Building in public. There you go, yes. Not officially but unofficially, yes. It's not fully public yet but it's very easy to get the roadmap from me and help influence it. Eric Anderson: These folks who have built extensions or want ... Or are now curious like I could build that. I didn't know you could build Redis out of ... What else can I build? Inspire somebody here to go build some wild extension for us. Ry Walker: Okay. I'll give you an example. I hired a co-op, a second-year student at the University of Cincinnati named Jay. He started a couple weeks ago. And I'm starting our data warehouse project inside of Tembo. I need to build internal metrics, and billing, and all this stuff. We're using Clerk for auth, which again, I'm sure you're familiar with Clerk. A great product. I need their data into my data warehouse. You could try to write a little Python script to pull it that's easy enough. We actually built a foreign data wrapper for Clerk. He did this in literally one week so that you could just say select essentially star from Clerk users and it just returns a table just like it if it was a database but it's actually using Rust, and calling their API, and prepping all that data, and packaging it up, and so on. Eric Anderson: Oh, interesting. Ry Walker: So these foreign data wrappers can be for any system. So I think right off the top, if you have an API and there's not a foreign data wrapper for it for Postgres, send me a note and I'll show you. Eric Anderson: I actually wanted to SQL query an API recently and I was like I don't ... Can that be done? How is that done? Ry Walker: Superbase released an SDK for this called Superbase wrappers and we're utilizing that. So shout out to Superbase for open-sourcing it permissively. And we built Clerk FDW. Like I said, a very young developer did it in no time. I just think that's a great opportunity right there. I mean, basically, you have all these data ingestion tools, there's thousands of connectors that exist in some of these tools. There's definitely a couple hundred important FDWs that we could create. Again, it makes Postgres more valuable. I'll go hit that table, I do an insert into a local cache of that, and put that on a little kron and can ... There's something called temporal tables extension in Postgres where you install this extension, it automatically creates a history of changes to each row. There's some really cool stuff that most of us are doing very manually in our data pipelines that ... These Postgres extensions. Again, we're going to build all these guides out and we're going to try to help. We're probably going to build a little Postgres academy of sorts just so people who want to learn this stuff and use it have an easier path than their predecessors. Eric Anderson: I can imagine Postgres people wanting to hang out around Tembo and talk about how to do these things, the red pillars. Is there a place where they can live and hang out? Ry Walker: We have a Slack community, it's starting to fill up. It's interesting because the core team in Postgres, they have a really hard job, man. Maintaining this core engine that has all this extensibility is just so hard. I basically love that our core team in Postgres is that they're all facing inward and they really don't have much time to talk to anyone other than themselves. Evaluating ideas that are coming in and committing them. There's this need to have a community, the next ring around that. We've got a couple of other ideas that maybe I'll share later on. I think that building this community is a really important part of it. And not just around a specific vendor but around the concept of Postgres as a database platform or whatever we want to call it. Eric Anderson: Super. Ry, this has been fascinating. I'm so glad you're doing this. Regardless of whether you summit, you're going to leave a whole new way of getting work done in your wake. Ry Walker: And that's why I thought okay, you had a nice exit, you could just give away money. To me, this is a better use of my time that we're going to ... Even if we never win a single customer, we're going to leave a trail of Postgres improvement hopefully behind us and that's good for the world. Again, it's not quite the same feeling as serving homeless people food or that kind of stuff but this is ... I have the privilege of trying to build a company and doing good for a community all wrapped into one. It's something I love to do so work doesn't feel like work and it's a good fit for me. Appreciate that. Eric Anderson: Okay, thanks. Ry Walker: Thanks, man, see you. Eric Anderson: You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been contributor.