Talking Postgres with Claire Giordano

What do guitar busking, geospatial queries, and agentic coding have to do with Postgres? In Episode 33 of Talking Postgres, principal engineer Rob Emanuele at Microsoft shares his winding path from Venice Beach to building a new VS Code extension for PostgreSQL—that works with any Postgres, anywhere. We dig into GitHub Copilot, ask vs. agent mode, and how Rob now codes in English—and then spends even more time in code review to decide what’s good, what’s bad, and what’s dangerous. Also: how PyCon changed his life; his work on the Microsoft Planetary Computer with spatio-temporal queries and PostGIS; and how music, improv, and failure shape his approach to developer experience. 

Links mentioned in this episode:

Creators and Guests

Host
Claire Giordano
Head of open source community efforts for Postgres at Microsoft. Ex-Citus Data, Amazon, Sun Microsystems, and Brown University CS. Serves on PGCA board. Prolific Postgres conference speaker. Co-creator of POSETTE: An Event for Postgres. Loves sailing in Greece.
Producer
Aaron Wislang
Open Source Engineering + Developer Relations at Microsoft + Azure ☁️ | Go (golang), Cloud Native, Linux 🐧 🐍 🦀 ☕ 🍷📷 🎹 | Toronto 🇨🇦🌎 | 💨😷💉 | https://aaronw.dev/hello/
Guest
Rob Emanuele
Principal Software Engineer at Microsoft working on GenAI, PostgreSQL, and VS Code.

What is Talking Postgres with Claire Giordano?

Talking Postgres is a podcast for developers who love Postgres. Guests join Claire Giordano each month to discuss the human side of PostgreSQL, databases, and open source. With amazing guests such as Boriss Mejías, Melanie Plageman, Tom Lane, Simon Willison, Robert Haas, and Andres Freund, Talking Postgres is guaranteed to get you thinking. Recorded live on Discord by the Postgres team at Microsoft, you can subscribe to our calendar to join us live on the parallel text chat (which is quite fun!): https://aka.ms/TalkingPostgres-cal

CLAIRE: 00:00:05
Welcome to Talking Postgres. It's a monthly podcast for developers who love this database. I'm your host, Claire Giordano, and in this pod, we explore the human side of Postgres, databases, and open source. And we delve into why do people who work with Postgres do what they do, and how did they get there? I want to say thank you to the team at Microsoft for sponsoring today's community conversation. And today's guest is Rob Emanuele, who is a principal engineer at Microsoft on the Azure team, where he creates generative AI tooling to help developers work with Postgres. He's a co-creator of a new VS Code extension for PostgreSQL and a primary developer on the Copilot extension. And before this current job, I suppose, he was a geospatial architect on Microsoft Planetary Computer. And before that, he worked on open source geospatial code bases for years at, I might mispronounce this, Azavea. We'll have to talk about that. Welcome, Rob.

ROB: 00:01:12
Hello, thank you for having me.

CLAIRE: 00:01:14
I'm glad you're here. All right, so today we're going to be talking about building a dev experience for Postgres in VS Code. But before we dive into VS Code and even Postgres, one of the things we do on this podcast is we often delve into people's origin stories. So I'm really curious about how you got your start as a developer, and then after that, when you first got involved with Postgres. So can we start there?

ROB: 00:01:42
For sure. Yeah, awesome. So I actually took a pretty winding path to becoming a software developer. In my early days when I was in high school, I was in a lot of bands. I've been playing guitar since I was 10, and was pretty dead set on being a musician. So I ended up going to the Berklee College of Music in Boston. And yeah, sort of, you know, it was 18, kind of living that rock and roll lifestyle in bands playing out, not super focused on my studies. But started hanging out at MIT with a friend of mine from high school and meeting a lot of the folks involved in STEM there, auditing some classes, and decided to drop out of Berkeley and go pursue a physics degree, which led me to Rutgers University, where I took a mathematics course. And it was the first time that I had seen proofs and done proofs and really the abstract logic of mathematics and got really interested in that. So I switched my major to mathematics. But then after college, I got on a motorcycle, headed west to L.A. to go live with a friend and go back to chasing the music dream. so you know doing everything from busking on Venice Beach to just a lot of very random Craigslist gigs which were some pretty interesting pretty interesting jobs. I decided the hustle of the music scene, I'm too east coast for for California anyway, sold the motorcycle. [Awww. I'm in California] Oh, I'm sorry. Are you? I love California. [Northern California, though.] Northern California has such a special place in my heart. L.A. is, you know, just, I love it for what it is, it's just not for me. And yeah, I need seasons, you know? But yeah, so I, I headed back and was doing some random gigs there. Saw a ad for a software development job where they'd actually like teach you on the job, decided that would be like, you know, good use of my math degree. So ended up doing Sybase Power Builder, which I wonder how many of your listeners remember or have heard of. But did a lot of coding there for like an ERP solution, ended up switching three jobs, really discovering Python and some of the more interesting design patterns and coding, and seeing some of that logic of the mathematics show up in code and fell in love with that, and ended up at Azavea. So many, many people pronounce it the way that you... [Azavea, Azavea. Okay.] Azavea, yeah.

CLAIRE: 00:05:02
Sorry about that.

ROB: 00:05:03
No, no, no. It's not your fault. Yeah, so at Azavea, which was a geospatial software firm, I worked on open source tooling for doing large-scale raster processing, geospatial rasters being like satellite imagery or climate model output data, and using Apache Spark to do distributed operations on that data, and really got involved with the open source community there, building out libraries, not just the one called GeoTrellis, but there were others I was involved with. And then at Azavea, there was a lot of project work going on where we were building web apps with geospatial data, and they were all backed by Postgres. That was my first experience with Postgres, seeing it sort of through the lens of PostGIS, PostGIS, where it seemed like, you know, a super capable database that everybody used that was very, you know, popular in the community and also had all of the operations and data types that we as geospatial engineers deal with every day.

CLAIRE: 00:06:33
One of the first episodes of this podcast was with Paul Ramsey and Regina Obe, who are both very much involved and were there at the beginning of the PostGIS project. So it's amazingly popular. And I haven't yet been to a FOSS4G conference, but I'm hoping one of these days I will. So anyway, I'll drop a link to their episode in case there's anybody listening who is more into geospatial data and PostGIS than they are into VS Code, and so that way there'll be something for everybody.

ROB: 00:07:11
Definitely go to a FOSS4G. Anybody out there who's thinking about it, it's such a great community. And, you know, I've been to many FOSS4Gs. I was on the conference committee for FOSS4G North America. It's such a great conference and community. So I definitely encourage you to check that out.

CLAIRE: 00:07:32
Yeah, we even had Regina Obe as a keynote speaker for POSETTE a couple of years ago and she tried in her talk, and I think she did a good job at, it to tie together the open source geospatial community, and PostGIS, and Postgres, and talk about those kind of three different communities and how they overlap and intertwine and and what their connections are. So I guess I'll drop that link in there too if I can find it. Maybe Aaron will find it for me. Okay so that explains your first experiences with Postgres and PostGIS, too. How many years ago was that, or do you not want to say?

ROB: 00:08:18
I probably, I'm trying to do the math. So I think I started at Azavea maybe 2011 and then was there for about ten years, nine years.

CLAIRE: 00:08:37
Okay, all right. So then, what's your background with VS Code? Like when did you start using it as a user or start working on it as a developer? And this in particular, the extension that came out that we'll talk about in a few minutes.

ROB: 00:08:51
Yes, I actually didn't start using VS Code until I joined Microsoft in 2020. Before then, I was an Emacs user. I was somebody who loved the key bindings of Emacs, which I really appreciate the ability to map the key bindings. I still use Emacs key bindings for everything. But yeah, it's kind of a bare bones, I mean, it's not a bare bones editor, but it's not the integrated environment that VS Code is. So yeah, I was working at Azavea, first as an engineer, then as a manager, and then I was VP of research development, leading up a couple teams doing product development and research into machine learning as applied to geospatial data, but saw the opportunity where the Microsoft Environmental Sustainability Team was building what they were calling the Planetary Computer. And it was a geospatial data platform that I had, you know, really had been working in that area for a while, for many years, and so went back to being an individual contributor on that team. And yeah, that's when I switched to VS Code, and I didn't actually do any extension work with VS Code until later, about four years later, I joined the Azure Postgres team.

CLAIRE: 00:10:32
Okay. And before we start talking about Postgres and VS Code, I guess I want to know a little bit more about your work on the planetary computer. So I know very little. I looked it up. There's a multi-petabyte catalog of global environmental data with APIs, and it seemed like the target audience were people who were interested in conservation. And it gave people a scientific environment in which to analyze the data, query the data, get their questions answered. That's the limit of what I know.

ROB: 00:11:07
You got it. It's a really cool, it's a really cool project. Yeah in, I think it was 2019, there was a series of environmental sustainability goals that were issued by Brad Smith and the Chief Environmental Officer at the time, Lucas Joppa, for various conservation goals, carbon output goals. And then they announced they were building this planet to computer. The sort of grand vision of it is, you know, we spend all of our, all of this time and technology on building machine learning systems to analyze how humans behave and our click through behaviors and, you know, to sell us ads, but why aren't we applying that same technology to understanding the Earth and how it's changing and how we can live in a sustainable way? And so the sort of seed of that is there's so much open data that gets produced that is about the surface of the Earth, so many satellites orbiting the globe from places like the European Space Agency, USGS, NASA, collecting really important and interesting data that is extremely heavy. And it's very hard for academics, for anybody building sustainability solutions to access that data, to find the right pixels in the, you know, 60 petabytes of data. So we built a system that stored about 60 petabytes of openly licensed environmental sustainability related data on Azure storage and then had APIs that allowed a standards-based search. So there's a geospatial standard called SpatioTemporal Asset Catalog that we implemented and built services for people to go and search for the data and be able to actually use it in a lot better way. And we've had a lot of feedback from academics and people building applications that use satellite imagery that the way that the data was organized, and again, like building on the standards in the community, which I was on the steering committee for STAC, so sort of with the STAC community building this out, made it easier for people using this data to access it. And I think that's an interesting, like, you know, I had worked in library, like building libraries for engineers to use and build into their projects and building, you know, code APIs to. allow them to move faster and build on libraries, and this was sort of an example of like, how do we build APIs that are dead simple to go access this really, really complicated data? And I think that developer experience focus kind of follows through with the VS Code extension eventually.

CLAIRE: 00:14:27
Okay, so there could be a whole episode on this topic by itself. Like, and I could bring someone from the European Space Agency on the show and, you know, or bring you back and talk about it, but we probably need to pivot to VS Code and Postgres. But, oh my gosh, I think there's something so fascinating about maps and all of the satellite data and what you can do with it, and I think, well, for me, it's really cool to work in the Postgres space and know that Postgres is an underpinning underneath some of these applications and the work that scientists and researchers do in this space.

ROB: 00:15:09
Yeah, absolutely. And I kind of spoke about the data and the APIs, but underpinning it all was Postgres. And that, to me, was my first real look into the power of Postgres. Like I said, we had 60 petabytes of data. millions and millions of rows with these complicated geometries and we, you know, that were spread out over time. So you're doing these spatiotemporal queries and we landed on using Postgres to back all of that to be the main data engine where multiple pipelines were feeding data in. There was, you know, like 20 million API hits a month, serving those out across like scaled API servers. And yeah, it was really interesting to see how Postgres, you know, to start with it was dead simple, and the data model was like pretty straightforward, uses JSONB to encode the STAC metadata, and the properties. But we, you know, had scaling issues early with the like ORM that I was using in the API servers. It was not querying correctly and we brought in a vendor, I'm going to shout out David Bittner at Development Seed who was our Postgres expert. He built a sort of SQL-only, not an extension extension, but just like a SQL-only layer on top of Postgres to handle spatiotemporal asset catalog data called PgSTAC. And there were just so many optimizations, so many things around like partitioning, you know, dynamic partitioning at scale. There was like dehydration and hydration patterns for JSONB storage. All of this like really interesting, very powerful capability baked in. And I sort of saw the true power of Postgres then because, you know, we went from kind of throwing hardware at it, we were using Azure Flexible Server, and were able to scale up the memory and CPU easily. But with these performance improvements, we're able to scale it back down and serve the same amount of traffic. So I thought that was really interesting to see in this production highly used scenario how Postgres easily handled it, but it took a lot of work to kind of tune it and use it correctly, and have the expertise involved to actually have it perform that well in that scenario.

CLAIRE: 00:17:58
I could keep going on this, but I'm going to bite my tongue, not ask more questions, and pivot. So why are we here today talking about building a developer experience for Postgres in VS Code? What happened? Because I imagine some listeners don't know about this new thing that you worked on over the last year and that launched back in April or May. It launched at PyCon, right?

ROB: 00:18:28
Yeah, it was PyCon and MS Build. [Okay.] Yeah, so the VS Code extension is, yeah, it's an awesome extension. So how I arrived at it is...

CLAIRE: 00:18:39
Wait, what is it? Yeah, before how you arrived, what is this VS Code extension?

ROB: 00:18:43
Yeah, so it's a VS Code extension that you can install from the VS Code Marketplace. It has an icon on the side that you can click and then a user interface to manage connections. So you can create new connections, manage the servers and the database you're connected to. It has regular password authentication. It also supports Entra authentication. And this is sort of like a theme with the extension, it works for any Postgres database. If you're using Postgres on AWS, Google Cloud, just on your own server, it works really well. There are some things that it works specifically well for Azure Postgres, like Entra authentication, but it works across any Postgres. It gives you the ability to connect to the database, bring up a query window, which is really just a VS Code editor, and then go ahead and type your SQL. If you have Copilot completions enabled, you can use all your VS Code goodies there and then execute queries. It gives a results viewer where you can export to CSV, JSON, etc. You can browse the database objects, do maintenance activities like script any of the objects as CREATE or DROP. It also has a way to visualize schemas, so you can really easily navigate a database by visualizing the schemas. A newer feature we just released is a dashboard for the servers that include metrics, so you can see sort of real-time metrics collected from your server. There's also a tab for historical data. If it is an Azure Flexible server, it will pull from Azure Monitor to show you all of your historical CPU usage and memory and all those good metrics that we collect about our Postgres deployed servers. And then a critical aspect of it, I think, is the Copilot functionality. So it provides an integration into GitHub Copilot that makes it really easy to work with your database with the LLMs in Copilot. So it has a chat participant, @pgsql, that you can chat at and is able to use tools to work with the database, determine the schema, query the database, answer natural language questions really easily. It also has agent mode tools, so GitHub Copilot has a few different modes. Ask mode is where the sort of chat participant comes in, but agent mode allows agents to be orchestrated and make modifications to your code base, modifications to, you know, like can crawl things, can kind of do iterative development. And so we have tools that the agents can use that can then, you know, do read-only queries to your database, can open scripts on your behalf to get the database schema, modify the database with your approval, and also now with the metrics in the dashboard can help you diagnose issues with your server. You know, if you see CPU spiking, you can ask Copilot, like, hey, why is this CPU spiking? And it can actually go and figure out from the metrics, hey, I see that this, you know, this table is missing this index, and so there's a lot of queries against this and, you know, it's causing problems, here's a suggested index. Do you want me to run this against the database? So that's that's sort of the scope of the VS Code extension.

CLAIRE: 00:22:36
Okay. And when you started, I think you co-created this with Matt McFarland, am I right?

ROB: 00:22:44
Yeah, and others on the developer experience and AI team at Azure Postgres.

CLAIRE: 00:22:53
And did you start from a blank sheet of paper? What was it, what was the process of building this thing? Because, you know, it didn't exist six months ago or a year ago. So when you first started, I don't know, do you remember the beginning?

ROB: 00:23:07
Yeah, for sure. Well, it was interesting because it did actually exist. There was a Postgres extension by Microsoft in the marketplace that had sort of, you know, not been maintained.

CLAIRE: 00:23:27
Another way of saying it is it had been neglected since 2020.

ROB: 00:23:31
Yeah, it had been neglected since 2020, and that was what we kind of started with. There was a Python code base that did a lot of the connection management stuff, and then the TypeScript extension was actually based off of the MS SQL VS Code extension, so that had made leaps and bounds in the meantime. So one of the first things that we did, so Matt and I started at the team in about, I'd say, like September, October of last year. So it's been about a year. And we sort of updated the code base to more match what MS SQL had and then revamped the language server and sort of did work to bring it up to speed. So it is sort of net new in that it's completely refurbished, I'd say. But we did start with a really solid ground from, you know, that previous work and also the MS SQL folk, which, you know, I have to shout out the helpful engineering team that definitely we were able to leverage to accelerate the development.

CLAIRE: 00:24:48
And then VS Code itself is super popular amongst developers, so did you end up collaborating at all with the VS Code team, or were you really more focused on collaborating with another extension creator in the MS SQL team. This is not a leading question. I have no idea what your answer is going to be.

ROB: 00:25:12
Yeah, we didn't end up working with the VS Code team specifically because they have such a rich extension capability and like it's very well documented and they've built it to be super flexible, which is one of the great things about VS Code. And actually kind of now that I'm thinking about it, it's like Postgres has this extension capability that's like, this is sort of baseline. Like what can you do on top of this? Here's a bunch of hooks to be able to extend this functionality because that's where the power comes from. I feel like VS Code is the same way. It has very clearly documented extension points that you can build on top of. So we didn't really need to get the VS Code team involved too much. We let them keep working on the awesome core functionality that they're doing. And yeah, it was pretty clear how to build it out. And then we gathered requirements from users and had user interviews about what functionality would be most important and just got to work building that out.

CLAIRE: 00:26:23
Did you or or Matt, maybe you speak for him, come to the table with any specific philosophies about what a good user experience or what a good developer experience would be? I mean, you said you did user interviews. You said you got requirements from users, both of which are like solid things to do. But I'm just wondering how opinionated you were in making decisions about the focus of "no, we're not going to do that. Yes, we're going to do this" or "these are our guiding principles."

ROB: 00:26:59
Yeah, I think some guiding principles were to, you know, start in a scoped way, like try to not do everything, right? And the extension doesn't do everything. There's, you know, there's other database IDEs that are much more full-featured and deep into what Postgres can do, like pgAdmin. We can't do all the things that pgAdmin can do, but we try to be selective about what are the most important things and try to do them really, really well. I think for like developer experience and developer tooling, you know, I had said I spent a lot of time building libraries in the open source community and really, you know, understanding what do engineers need and how do you give them just that in the most simple way and get out of their way and let them do, you know, be flexible, right? And so that sort of thoughtful design process, understanding what the workflow is that you're targeting and how to assist in that is something that I think we brought into this extension. And I think led us to, yeah, making design choices, especially, you know, the integration with Copilot that, you know, sort of imagining what, you know, engineers are going to use this for, and then also a lot of dogfooding, right? We use Postgres all the time internally, so we're our own users and it's really sort of easy to understand what the, you know, what the thorny parts are, what improvements could be made when we ourselves hit against issues.

CLAIRE: 00:28:44
I often wonder what the etymology is of the word dogfooding, and so I will probably look that up as soon as we're done today. Unless you happen to know.

ROB: 00:28:57
So very interestingly, there was [You do know.] yeah well I don't know exactly, but I just hit my five years at Microsoft and there was like a page about the history of Microsoft and it actually had that question, like it was an FAQ, and it's like "where did dogfooding come from?" and it was something really early on, I think in the eighties, about somebody had like a printer service in a building, and then they used the term "we should eat our own dog food" and everybody used this printer service, so it actually did originate from Microsoft.

CLAIRE: 00:29:37
Oh, interesting, because I worked at Sun Microsystems back in the early 90s, and we definitely used the phrase as well, like "eat our own dog food." You know, we would run on the last night's build of SunOS, for example. But yeah, I didn't know it originated at Microsoft. And it had to do with a printer.

ROB: 00:29:59
Yeah, somebody fact-check me on that, but it was something from Microsoft.

CLAIRE: 00:30:04
All right. So you were running on top of Postgres, and you were using VS Code, and you were using the extension, so you had your own reactions and visceral reactions probably about what was working and what wasn't working as you were doing development. Did I paraphrase that right? [Yep.] Okay. Any other guiding principles?

ROB: 00:30:27
I think another one was to, you know, really recognize that AI and coding agents are going to be a huge part of the future of the developer workflow, and so trying to set up the functionality such that it gives the coding agents visibility into and the ability to interact with all the functionality that we build. That's been a pretty guiding principle and something that really highlights why are we building this into VS Code. There's already other IDEs that really work well with Postgres. And the fact that GitHub Copilot is there inside of VS Code and the extensions can hook into it and give that capability to coding agents and you can enhance coding agents in that workflow that is evolving in front of our eyes in the industry. That was sort of a principle that we want to best enable that functionality that's still being built out.

CLAIRE: 00:31:45
How did you think about, I don't know, governors, protection, like putting in place guardrails that will obviously enable the agents to be helpful, but prevent the agents from doing things they're not supposed to do?

ROB: 00:32:01
Yeah it's a good question, I think it's an interesting question in the industry these like, today like, "okay what if we let the agents run wild? What could they do?" [Is that called YOLO agents or something?] yeah, YOLO agents. Go ahead and delete my entire code base if you deem necessary. [Nooo.] Yeah. So I think that we're kind of following what VS Code is doing, which is the sort of approval process. So whenever an agent uses a tool, you have to approve it. Now use this tool, this is like a read-only query, just accept it, allow it to do whatever it wants, and that helps accelerate the workflow. But, you know, for instance, in my environment, I let the extension tools kind of run wild except for modify database. And I have to review and approve anytime that it does that. We also have some configurations set up to specifically state that one of the databases in your connections is a read-only for agents. So you can add sort of another layer of protection there. So we've thought about how to prevent it from running anything that's dangerous. But at the end of the day, you're leveraging these tools to write SQL on your behalf, for instance. And so if you're able to write that SQL and execute it, the agent also should be able to with sufficient review capability. And it's up to users to don't let the agent do it, don't YOLO, right? Like review everything or else you're going to... don't disengage. Actually be a participant. Let the Copilot be a Copilot. You're in charge and don't let it do anything that's silly. And I've seen it try to do some silly things before, and it's just like, yeah, not against the database, mostly against like, git, like try to clear out my unstaged changes. And it's like, no, don't, why are you trying to erase my work? Please, please stop doing that.

CLAIRE: 00:34:25
I joke sometimes that, you know, obviously I started off as an engineer in developer tools eons ago, but these days English is my programming language, right? Communicating, writing, talking to people. That's how I do my job within the Postgres world. And so I've obviously been using LLMs a lot too. And I love them as an editor. Well, I love them sometimes as an editor only when I have great prompts, only when I've been really specific about the tone of voice requirements. And I mean, very specific. And it's great for me that at two in the morning, I can get some really useful feedback, but I can't use it all. Like there's a bunch of, a lot of suggestions. I'm like, no, no, no, this doesn't work. This doesn't work. And then there were some fantabulous suggestions and feedbacks that I am just so glad, right, that I had this assistant to help me. So I don't know if that's what your experience is like as a developer.

ROB: 00:35:30
Oh, absolutely.

CLAIRE: 00:35:31
I definitely have to review all the changes. And I think that's where I'm being more successful than other people who are using it and just not reviewing all the changes. And then they're getting a mixture of goodness and crap together. Whereas I just pull out the goodness and it's amazing. Anyway.

ROB: 00:35:50
Yeah, it's interesting. I mean, it is a tool. And the models are super, super capable, but they're not just like throw a problem at it and it just does exactly what you want. You know, I've actually in my engineering career, I mean, this is such a turbulent time because AI is disrupting all of our workflows of how, you know, we build code. And I'll be honest with you, I now use English language to code. I don't write code anymore and haven't for a bit. I mean, I do make edits. I do a lot of code review. But most, I would say a vast majority of the code that I output daily is written by agents. And I'm writing markdown files. I'm writing specifications. I'm writing and reviewing implementation plans. And a lot of the workflow that I'm fitting myself towards is what is the flow of agentic coding that can build a specification, build an implementation plan that I can review and make sure those are right, and then build a phased implementation that I can review as GitHub PRs and make comments on and say, no, don't do this, do this, yada, yada, and have the agents do the coding, but like in a very controlled manner to reduce that AI cruft that ends up happening when you let the agents kind of code without really knowing the context of what you need.

CLAIRE: 00:37:23
Yeah, and when you're reviewing someone else's code, or in my case, someone else's writing where that someone else can be a human or can be an LLM, it's almost harder than when you wrote the code yourself or you wrote the English yourself, right? Because you really have to be on your toes to pay attention and look for those nuances and those subtle things and those edge cases and and to review it. But on the other hand you end up with a more efficient workflow even with all that attention to review detail.

ROB: 00:37:56
Totally. Yeah. It's the new, it's sort of the shift of skill sets where the generation part can be handled by LLMs but the review part, identifying what is good, what is bad, and what is dangerous, what is actually wrong, is so important. And I think for me, I'm finding myself having to really craft that skill set and exercise it a lot more and build that new muscle. I mean, it's a muscle that I've had, I've done a lot of code reviews for humans, but it's just sort of different and a lot more than I'm used to. And yes, it's interesting because the potential for accelerating and the output that I can create is way higher now with these tools, and that's definitely something that I'm excited for the Postgres community to also be able to embrace. because something like VS Code and GitHub Copilot is really focused on modifying source code. But what about the database? And what about the complexities of the database? When we built the Planetary Computer on Postgres, we hired an expert vendor to build out this PgSTAC project over months to do very complicated optimizations that eventually made Postgres really work. I realized I had only been using 10% of Postgres and the power of Postgres before that instance, and I just don't have the expertise in Postgres to know to build that out. But with agents, with LLMs, with the knowledge that LLMs have of Postgres, because Postgres has been here for so long and all of its history is online and the LLMs have trained on all of the public data on the internet, so it knows Postgres so deeply, probably better than any other database out there. It can now be a copilot to help me actually try to use all of that power of Postgres in my work. So I'm really excited about that sort of leverage that you can gain by using coding agents and Postgres specifically.

CLAIRE: 00:40:28
Yeah, the classic phrase that you'll hear, and this isn't specific to Postgres, I think that you'll hear this in a lot of conversations with database engineers, is you'll ask a question about optimization or how to do this better or how to solve this, and the answer is always, do you know what the answer is? It's two words. It's, it depends. [Yeah.] And that's the classic answer. It depends because there are all of these factors, and there's a whole cottage industry of wildly intelligent and knowledgeable database consultants, and in particular, Postgres consultants out there. And I actually haven't talked to any of them. Maybe that's a good podcast conversation about how their world is changing as a result of LLMs and AI, and are they seeing it as a competitive threat or an existential threat? Or are they seeing it as, okay, this is a tool that's going to make my team, my company even more productive and effective. And I know it's, well, it feels like it's still early days and yet it's not. We're several years into this. I'm just thinking out loud, sorry for the ramble.

ROB: 00:41:40
No, that's a great point, and I'd be interested in what they have to say as well. And I think that this VS Code extension is, you know, targeting developers mainly just because that's, you know, VS Code is already sort of a environment for developers that maybe don't have that database expertise. But I'd also love to see it be able to be used by DBAs and SREs in order to leverage the agents that GitHub Copilot provides to do their work better. So I can imagine you've amassed this database expertise, and just like we were talking, the ability to see what is right or wrong from LLM output is so important. So if you have all that expertise and you let an agent investigate potential optimizations for a database, it might come back with some ideas that are bad and some that are good. And for you to be able to review that and have the knowledge to actually say, OK, that one is actually good, let's expand on that one. Why don't you check X, Y and Z? Let's go look at the code and and see if there's any bad queries that are being issued because of this like index structure or whatever. That's hugely valuable and the tooling can accelerate that work. So my hope is that they would see it not as an existential threat, but as a potential force multiplier.

CLAIRE: 00:43:18
Are DBAs and SREs part of your target audience today for the VS Code extension for PostgreSQL? Or do you envision that they will be part of your target audience in the future? Should a DBA go and check it out right now?

ROB: 00:43:35
I think so. I mean, you know, I'm not myself a DBA or SRE. I mean, I've done some of that work, but I would say that it would be awesome to have them use it and then tell us why it doesn't work for them. And we have, for instance, the performance metrics and the Copilot functionality to ingest some of the dashboard metrics and investigate the database to understand where there might be performance issues or why are there locks happening and all of a sudden my APIs are freezing up. This is something that we definitely want it to be useful today for. And if it's not, and if we fall short, then we would love to understand what we can do better.

CLAIRE: 00:44:26
Switching gears for a sec, one of the things that I think is really interesting, and as one of the co-creators, you might not have been involved in thinking about like, how are we going to launch this? Or how are we going to announce this? Because sometimes those discussions are handled more on the marketing side or the product management side of things. But I think it's so cool that it was initially launched at PyCon. And I know you corrected me earlier in the conversation. you're like, yeah, PyCon and MS Build, but PyCon came first. It was late April, early May, whereas I feel like MS Build was more middle of May. And I just, it's, PyCon is such a popular, I mean, obviously there's PyCons all over the world and in specific targeted local regions. But the one where it was announced was the big US-wide, I forget what city it was in last year. Was it Salt Lake? [I think New York.] I don't know, it moves around. It'll be in a particular city for two years and then it goes to another location and another location. But it's just there's so much buzz, there's so much energy, there's so much excitement. I just think it was a perfect place to roll it out. But I'm curious, were you part of that? Thinking about how to how to introduce it to developers?

ROB: 00:45:51
A little bit, but not so much the decision-making, sort of like here's the deadline to get it all together, right? Because I was specifically working on the Copilot functionality and the GitHub Copilot agent mode released to GA a month before our launch. And we were targeting build the whole time, so maybe that's why it's kind of in my head. And yeah, PyCon was, I think, the week before, and there was a talk announcing it, which was so awesome. I love PyCon. I mean, I actually attribute it to changing my career path in 2008. I just took myself to PyCon Chicago to see all of the amazing work that people were doing and ended up kind of switching jobs because I was like, oh, I want to be doing stuff more like this. So yeah, totally, PyCon is such an amazing conference. But yeah, we were pretty heads down in trying to get it to work. I mean, it was working, but we just wanted to put the best extension that we could out there. So we were kind of targeting Build, but yeah, that was sort of conversations, like you said, by marketing and other folks.

CLAIRE: 00:47:15
What do you love, I mean, this is like a softball question, but what do you love most about this thing that you built? And it doesn't have to actually, the answer can be anything. It can be about the experience building it, or about the thing itself.

ROB: 00:47:34
I think it's the ability to leverage the Copilot functionality. I'm very interested in how AI and LLMs are changing a lot of stuff, I mean, everything, but engineers' workflows. So to be a part of figuring that out and advancing that is really cool. And GitHub Copilot is such a great platform to build on because the users just have to have a license to those LLMs. They don't have to go and set up different services or put in API keys. It's kind of there, and as an extension author, we get to just hook into it and enhance the agents that are already there. So I love that part of it, and I'm looking forward to like continuing to build out that, that, you know, AI functionality. quality.

CLAIRE: 00:48:44
As you talk about agents and GitHub Copilot, I know that as we were preparing for the episode we started talking about the challenges with moving goal posts that's, you know if you imagine you're playing soccer, or football as my European friends call it, and the goalposts are moving in the middle of the game it makes it so much harder. And I feel like you had a timing issue, with the rug moving out from under you as you were trying to hit your deadlines for PyCon and MS Build. Would you agree or disagree?

ROB: 00:49:22
Yeah, for sure. That was the way to integrate with GitHub Copilot was chat participants, so you'd have that @pgsql handle, and then when you would chat at that handle, it routes to your extension, and then you're able to use sort of the bare bones completions APIs for the LLM. So you have sort of a lot of control over how the LLMs are used to respond to that chat message, and it's sort of like a one and done. You go and process and then you give your response and it shows up in the chat window, which is awesome. And that chat participant still works and is great. But then they GA'd agent mode, which is a very different workflow where you're not actually using the LLMs directly. You're just giving tools to the LLMs and trying to describe the tools and organize the API for the tools in a way that the agents understand how to use them and hand that off to the agents and let them go do their work. So it's a pretty big pivot to go from this, you know, chat, this ask mode, to agent mode. And I think it's the right pivot, right? It sort of allows GitHub Copilot to own the orchestration of the agents and improve on that at very rapid speed. And then the extensions sort of enhance the agents with these capabilities and tools. But it was tough to switch gears and sort of add that functionality a month before. And I actually leveraged GitHub Copilot significantly. I think that's when I started kind of not writing a lot of code anymore. It was actually building agent mode with agent mode for the release of the extension, and we were lucky enough to get it in in time. Usually you don't want to be adding new big features right before a release, but we discussed it with the team, and it was, you know, we tested it thoroughly. It was solid. And we sent it out with that functionality. So it does kind of represent the pace at which all of this is shifting and continues to shift. And it takes a lot to kind of stay up to speed on how, you know, LLM usage and agentic coding patterns are moving. But that's exciting. It's a really exciting industry to be a part of. You're constantly have to stay on your toes and say, okay, okay, what's next? How can I help, you know, actually push forward the boundaries, and then how do I make sure that this other technique that looks like it's about to be the thing that we now all do, you know, let's account for that and make sure that we're, you know, building towards that as well. So it's a very exciting time.

CLAIRE: 00:52:22
Well with all this change there's a phrase, an adage I guess is the right term, that says that the most familiar tool is always the best tool Or maybe it's backwards, maybe it's the best tool is always the most familiar tool and I don't know like for people that have never worked with a Postgres extension in VS Code or maybe don't even use VS Code yet who were using other IDEs to work with Postgres, I don't know, why shouldn't they keep doing what they've been doing? I'm not trying to make a sales pitch or give you a softball to make a sales pitch. I just wonder sometimes about what is the motivation to try something different?

ROB: 00:53:10
Yeah, I think it's a good question. And then there is, there is a lot of value in doing what, you know, works. However, the industry is changing. I know through my career, I've had to come up to speed on new techniques, new topics, new technologies that become the sort of dominant technology. And if I don't go and level up my understanding and try new things, then I end up getting a little bit left behind and having to catch up. And I think that, you know, if what you're doing works in those IDEs, great. If you want to try something new that exposes you to this new AI functionality and brings you into a developer environment, even if you're not, maybe you're not a developer, but I mean, VS Code, if you're organizing SQL files, that's coding, right? I think this difference between developer, non-developer, especially in the era of agentic coding, is dissolving. We're all developers. And if you want to kind of try that and see what it's like, see what could be possible, it's not easy. And this is something that's important to realize about AI and agentic tooling. It doesn't make it push-button easy. Set your expectations correctly. But if you work to try to leverage it and leverage something new you may find that you're able to do your job or the things even things beyond what you're normally used to doing in a lot more efficient way so I would just invite people to experiment and try new things always because there's always room for improvement.

CLAIRE: 00:55:14
We Simon Willison on the podcast a couple of episodes back during the summer and, I don't know, for anyone listening who knows Simon, or reads his blog, or has heard him interviewed he is knowledgeable, crazy smart, and very exuberant, which makes him really fun to listen to because he brings a lot of passion to his work. But one of the things he said is that for people, like you're, I think, recommending that people roll up their sleeves and try to figure out, experiment and figure out like how their workflows could change or could be different or could get better using these tools. But he gave even more basic advice when I pushed for someone who felt like, oh my gosh, I'm years behind. How do I get started? He's like, you know, just talk to some of the LLMs. He's like, sometimes I get them to help me make a, I don't remember the specific example, I think it was salsa. It was something to do with food and he was having them give him recipes and then he had it change the recipe and make it even tastier, and make it even tastier. And I thought that bringing that interaction with the LLMs into even non-coding things to get comfortable with it was an interesting approach. Maybe at a more basic level, but that's probably where some people need to start or are more comfortable starting.

ROB: 00:56:50
Absolutely, I mean I use it for literally everything, from my shopping to recipes to, you know, it's such a useful technology if you learn how to leverage it well and, like you said, that iterative hey do it this way now, make it better, or that's not quite right. You know, the LLMs only have the context that you give it. They're a blank slate and you have to say exactly what you need from it and all the backstory that's important. And that's a skill. That's a absolute skill. That's, you know, in the industry nowadays it's called context engineering. But you're engineering the context so that the LLM does the right thing, and that applies everywhere. If you're trying to get it to build a good salsa, you're trying to get it to debug a deep technical problem with Postgres, that applies across the board.

CLAIRE: 00:57:50
You know that demo you gave on VS Code Live with Olivia Guzzardo? When was that? Do you remember? Like what month was that?

ROB: 00:57:59
That was May, close after the launch.

CLAIRE: 00:58:03
Okay. I thought it was a good demo. I'm wondering if I should link to it in the show notes. Is it? Or do you have a better, newer one? Not that it wasn't good, but that you maybe have something you prefer that's newer.

ROB: 00:58:17
No, I think that's a great resource, and we're looking to come out with more video content showcasing some of the capabilities but I think that live stream is a good public video to showcase.

CLAIRE: 00:58:32
Okay because I'm a big believer in "show, don't tell". I mean I love the fact that earlier in today's conversation you enumerated kind of all of the capabilities in this new thing and again, this podcast is not meant to be a marketing vehicle for it. I really wanted to talk to you and about what it was like to build it, and how you thought about developer experience, and how you think about how AI is changing the world, and you are doing all those things for us, which is great. But I imagine some listeners are going to want to go check it out. So I will include a link to that demo from VS Code Live in the show notes. And I think the other thing I will include is Matt McFarland's talk at POSETTE earlier this year too. POSETTE 2025, which is a virtual Postgres conference, so it's a pretty good video, and I will link to that one too.

ROB: 00:59:29
Yeah, that one's a great one, it's shorter and more kind of an overview and demonstration of all the different types of functionality that the extension provides. So I'd recommend folks maybe look at Matt's talk first, and if you're interested in I think it's like an hour long coding session with Olivia in the VS Code Live stream, that's another place to look at more of the Copilot oriented functionality.

CLAIRE: 01:00:00
One of the things you said earlier, which I want to make sure nobody missed, because, okay, I work on the Postgres open source team at Microsoft, so occasionally I will absolutely help out my Azure teammates, as I should. Microsoft pays my salary, and so that makes sense, plus they're good people. But my main focus is with community work and Postgres open source, and I have, and I can actually only think of two people that have said this to me, but there have been people who sometimes, they still see Microsoft through that ten, fifteen year old lens of being anti-open source. You know, back in the days of, what was it called? Embrace, extinguish, something, something. It was a very negative part of Microsoft's past. Whereas these days, like I feel from inside the company that Microsoft is really, really supportive of a lot of open source projects, including Postgres. Anyway, the point is that the fact that this new VS Code extension for PostgreSQL works really well with any Postgres, I think that's fantabulous. That means I can recommend it to anybody I know in the Postgres open source community and users, whether they run on-prem or on other clouds with other hyperscalers, whatever. I think that's awesome. But I'm curious, and maybe you can't tell me, was there a debate about that? Was there any discussion or was it always obvious that that's how it was going to be built?

ROB: 01:01:37
It was always obvious how that that we wanted to support and make a great experience for any Postgres user. That's been the goals from the start. There is, I think the debate, and it's not really a debate, I mean Microsoft's building this extension, we want to have the, like there's things that we can leverage when it is an Azure Flexible server, an Azure Postgres database, that are special functionality that's not available to other types of Postgres. So we do build out those things like Entra authentication.

CLAIRE: 01:02:20
Or the Azure monitoring hooks you mentioned earlier,

ROB: 01:02:22
Yeah, the Azure monitoring hooks, exactly. With the server dashboard, you get metrics that are generally available with any Postgres. If it's an Azure Flexible server, now we have this enhanced functionality. We want to support the entire user base of Postgres, whether you're on Azure or not. We want to really enhance the experience of Postgres users in VS Code and users that are using GitHub Copilot. So we're not specific to the Azure Postgres functionality. And so if you have any listeners are using the extension and have suggestions on ways to improve it for the general Postgres use case, please do let us know. Go to our GitHub discussions or issues and submit feature requests, we are looking to support you very well.

CLAIRE: 01:03:27
And we will drop a link to that GitHub discussions area in the show notes as well to make it easy for people to submit feedback or ideas. And I love that you're going out of your way to invite that too. Okay, so I have a really random question I want to ask you. When David Rowley, who is a Postgres committer, Postgres major contributor, works at Microsoft, really brilliant engineer from New Zealand, okay, now I'm telling you too much. When he was on the show and he told his origin story, it turns out he worked in a cheese factory and that experience, and he was not initially there as a developer, but that led to Postgres for him. And then somebody else said, oh, I have a cheese story in my early Postgres days. And somebody else raised their hand and they had a cheese story that related to their work in Postgres. So I don't know, do you have, is there a cheese story in your background?

ROB: 01:04:30
I don't know if there's a cheese story that directly links me to Postgres, but there is a sort of odd job that I had that maybe put me towards the path of developing, being a software engineer instead of what I was doing that I could share.

CLAIRE: 01:04:50
Okay, go for it.

ROB: 01:04:52
So this was when I was in L.A., you know, busking on the streets, busking on Venice Beach and, you know, taking odd jobs from Craigslist. One of the jobs that I found was a data entry job. And it just was really, you know, generic, like data entry, like $10 an hour. Cool. I was like, all right, let me go into this. So I go to Beverly Hills and go into this office, and the guy greets me. He's like, oh, you're the one from Craigslist? All right. And he sits me down at a computer and he says, okay, what you're going to do is you're going to create a email address, use Hotmail, use Gmail, whatever you're used to. This is, you know, back in 2006, I think. And I went through that and it's like, okay, now you're going to go to the MTV site and create an MTV account with the email account that you just made. It's like, okay, log it on the spreadsheet. And then you're going to go to the Total Request Live website. And I looked at him like, what? And he's like, listen, we're Enrique Iglesias' management company. And it's really important to him that he win Total Request Live. So you're just going to vote for Enrique Iglesias. And that was the job. That was the data entry job. So I spent one day there. And as I was leaving, I mean, he seemed like embarrassed and he was like, listen, if you're not coming back, I was like, I'm not going to come in tomorrow. But it's like, if you're not coming back, you're never coming back. It like kind of understanding the ridiculousness of the job. And I think that was a little bit of a turning point for me to be like, I think I'm going to get out of L.A.

CLAIRE: 01:06:38
Yeah, you decided you wanted I don't know to do something more meaningful, was that why it was a turning point ,or you tell me I don't want to put words in your mouth.

ROB: 01:06:49
Yeah, yeah it was just it was sort of like you know the ridiculousness of you know sitting and voting for somebody with fake accounts is like I am yeah gonna be on a path to go back East and like figure out like what I am actually doing instead of this and that kind of led me down to finding the programming job.

CLAIRE: 01:07:13
Is music still part of your life though?

ROB: 01:07:15
Oh, absolutely.

CLAIRE: 01:07:16
I mean, it must be because the bio, the bio pic you sent me, which I had to crop, so people probably can't tell, but you were holding a guitar and you were wearing a t-shirt with the name of a band emblazoned on it, right?

ROB: 01:07:29
Yes. Yeah. I still do music, uh, a lot. Actually in some of our internal demos, that maybe you've seen at the all hands meetings that we have, I slip in some of my music in the background or at the end, these little jingles. But yeah, I recently did some music work for a play in Philadelphia. I'm working on a live set to go out and do some more gigging. So, you know, it's, it's tough with, with all the work and the, you know, I got a new kid, to find time for it, but music is still a huge part of my life.

CLAIRE: 01:08:13
Do you think it makes you a better engineer and better architect?

ROB: 01:08:19
I do think that there's an interesting connection to creativity, and I've done a lot of improvisational music. And sometimes when I'm thinking about a problem or working in code, there's an improvisational aspect of like, okay, well, what's a creative solution that I can apply here? And I think actually in this like age of AI coding, the creativity of how to apply AI, because it's such a wildly flexible tool and really has no like specific uses that are like, you know, super well, like, oh, you do this, this and this, right? It's like, use it however you can. There's an element of creativity that I really enjoy about life in general and like in my music being creative and then also now. And, you know, there's a lot of creativity that you can apply in architecture, in engineering that I do think that I get to leverage.

CLAIRE: 01:09:26
Yeah and I guess if you do improv you've had to get comfortable with experimentation and trying things and also I imagine that you try things sometimes in improv and they don't always work, and maybe you've gotten comfortable with that.

ROB: 01:09:43
Oh yeah, Yeah, failing failing is a big part of creativity and and a lot of improvisational music, that it's like, it's not failure. It's just like, oh, this sound was here, and now we're moving in another direction and everything's okay. Like it doesn't have to be perfect all the time. That's kind of the joy of it. There's joy in messiness, in creative processes, that I really value even, even if it's like, you know, not aesthetically or not super pleasing to the ear, it's just like seeing that messiness and, you know, occupying that. And then where does that messiness lead you to? That I think is, you know, really awesome. And that's, that's what you need to, that's the mindset you need when doing experimentation. And like we were talking about trying new things, why not just stick with what we know? And it's like, well, when we experiment and we see what works, what doesn't work, and we fail and learn from it, and grow, that's just like really interesting to me in all things.

CLAIRE: 01:10:52
What you're saying resonates so much with me because I have kind of an unusual job. And one of the things that I think helps me is that I'm willing to fail. I'm willing to say stupid things. I'm willing to, I mean, like classic, classic, silly example. Like when I'm writing something or trying to come up with a title, I often say that I have to come up with like at least 20 really bad titles in order to get to a really good title. And I'm always encouraging other people who, who kind of have a little bit of stage fright or, you know what I mean? They want to write the perfect title. They want to come up with the perfect approach. And I'm like, no, just get the first draft out there. It just, be willing to produce something bad so it can be iterated on to get to become something good. Anyway, that's my philosophy and I feel like it connects a lot to what you were just saying.

ROB: 01:11:54
Yeah, absolutely and I think that it's like something that people early in their career it's a hard thing to like kind of internalize and and occupy but as you mature in your career you get more comfortable with who you are and sort of failures that lead to success, I have proven track record, I don't need to be perfect all the time, but I'd encourage folks to kind of chase that, to say, it's okay, it's okay if it's messy. And, you know, own that, and I think that that helps grow. Absolutely.

CLAIRE: 01:12:30
I really appreciate you coming onto the show today and using the new VS Code extension for PostgreSQL, which I know is wildly popular and people are really excited about, but almost using that as an excuse to just talk. I love learning more about your background and your philosophies. I also want to give a shout out to the fact that Elizabeth Christensen reached out to me a couple months back about a monthly virtual meetup that she has started organizing along with Ryan Booz on the behest of PG US. And it's called Postgres Meetup for All. And it sounds like Matt McFarland is going to be a guest on that on Thursday, December 11th to talk about the new VS Code extension. So for anybody who wants to maybe see a newer demo, or learn more about the latest version of it, I will include a link in the show notes to that as well. Is that just Matt or is it Matt and you? Do you know? I think it's Matt.

ROB: 01:13:35
I think that's just Matt, and he's great. So definitely check that out. He'll teach you some awesome stuff.

CLAIRE: 01:13:44
Matt asked a question in the chat a few minutes ago, by the way, he wanted to know and and I can't believe I didn't ask this, I guess I fail as a podcast host today, but he wants to know if the singer that you were talking about, that you did that data entry job for, which was Enrique Iglesias, right? I mean, there's two Iglesiases, so I sometimes get confused about what the first name is. But he wants to know, did he win Total Request Live or not?

ROB: 01:14:15
You know, I never looked it up, but me and my wife did just the other night. I wonder if he actually did, and not during that time period. I was hoping somebody like the Foo Fighters might have won it, but they also didn't win.

CLAIRE: 01:14:35
Who won?

ROB: 01:14:36
But yeah, no, I think it was mostly like NSYNC.

CLAIRE: 01:14:37
Do you know?

ROB: 01:14:40
And I think during that time period, it was just like a couple bands that like won it all. But yeah, Enrique Iglesias did in, I think, 2001, win it like four times for, or 2002 for Hero. And I guess he was just chasing that dream of winning Total Request Live again.

CLAIRE: 01:15:03
Oh my goodness, I can't even say that Total Request Live is in my vocabulary. Like I've heard of it. I don't know much about it at all. So that's another piece of learning I guess I have to go do after today. All right. Before we wrap, is there anything that you want people to know? Either about Postgres, PostGIS, planetary computing, or the VS Code extension for PostgreSQL, or music? Anything that I didn't ask that I should have?

ROB: 01:15:37
No, I think we covered a lot. I would just encourage people to go try the extension and please let us know what you think, and ways that we can improve it. And if you end up using the Copilot functionality, this is, like I said, an emerging field that's changing quickly and would love to hear about how people are leveraging it in ways that it works and doesn't work, and just, yeah, getting conversations going about all that. So, yeah, really appreciate you having me on in this discussion. I think it was so great to talk about all these topics. And really appreciate your audience taking the time to listen, and thank you.

CLAIRE: 01:16:18
Thank you, Rob. All right. Thank you so much to Rob Emanuele for joining us. And if you are listening and you like today's episode and you want to hear more of Talking Postgres, then you should subscribe on Apple, and Spotify, and YouTube, or wherever you get your podcasts. And please tell your friends because word of mouth is one of the best, well, it's a nice gift you can give to your friends, but it's also one of the best ways to help a podcast succeed. And if you leave a review, that helps even more people discover it. You can always get to past episodes and get links to subscribe on the different podcast platforms by going to TalkingPostgres.com and transcripts are included on the episode pages there on TalkingPostgres.com as well. And a big thank you to everybody who joined the live recording today and participated in the live text chat on Discord.