I'm Building An AI-Powered SQL Workbench With Copilot

Transcript is auto-generated and may contain errors.

Hey folks, I'm just headed to an appointment. Um, I'm going to talk through one of the things I'm building. Um, the working name, I've talked about this before, but the working name is called Squeal just because it's supposed to be a play on um, how someone might incorrectly say SQL. And so I wanted to build a tool that was basically like a uh MySQL workbench. I'm not sure if if you're familiar with the tool um but as a developer that uses MySQL uh there is a tool that is called MySQL Workbench and basically just lets you you know connect to different databases query modify your your schemas that kind of stuff manage your actual database. And so I wanted to make a tool originally uh for two reasons. One is that when I was doing a lot of query optimization I was using like so I have my SQL workbench open.

So I'm just like in my familiar space kind of like for coding when we're in our IDE. Um just something familiar that I can see things visually, see queries, see data. Um, so I'd be doing that and then working with co-pilot on the side to basically like help tune queries. So kind of between two tools. Um, feeling like I'm doing a lot of I don't know uh juggling I guess is probably the best way to put it. Like how do I put the right constraints in place so that I'm making sure it's not, you know, writing to my database when it's trying to optimize stuff. like just I want to be careful about what's going on when I'm doing these optimizations. So that was like one sort of motivation is like how can I make this more uniform? And then the second was that when I started looking into well like what's going on with my SQL workbench, it kind of seemed like it's just dead.

Um, and I guess if I understand correctly, that the people who make it have just decided like they're not going to keep, you know, doing releases anymore. They're going to focus on, I guess, like a VS Code integration. Um, and I'm not totally sure why. And sorry, I'm checking my map here because I don't know why my GPS is telling me to drive this way to this appointment. Seems kind of silly. Um, okay. I guess we're going down this street. Feel like I've been on this street twice in my life. Um, so I guess yeah, they're they're not making new versions of it and they're planning to just do like VS Code integrations, which is fine, but like I don't use VS Code. Um, not because I paid it or anything. I just don't use it. And so I don't want to go adopt using VS Code just to be able to use an extension or a plugin just to get uh this kind of functionality.

So, what uh what do we do when we're developers? We do way too much, right? We overengineer stuff and we go build our own. Who who needs a new side project? We all do. So, I started building this thing uh called Squeal to basically replace my SQL workbench for me. And um I gave up on it like pretty quick cuz I was just messing around originally. Sorry, this uh I need a sec here because this intersection has no visibility. Excellent. Okay, we survived. Um, and so, you know, wasn't thinking about it for a while, then realized, and I made some videos about this, um, semi-reently, where I was like, why don't I just continue to build it out because it's something I need and I want. And then if I look into commercializing it, then I have, you know, something on the side that I can go release.

And it's worth mentioning, right? Like, if you're listening to this, you might say, well, aren't there already tools that do a bunch of this? Like, aren't there what you're describing, Nick? Like, that's not you're not the first person to do that. There's other people doing it. Yep. Totally. Um, and that's that's fine, right? Uh, there's many people that make shoes. There's many clothing companies. There's many car manufacturers. There's there's lots, right? Um, there's many people that make document editors and document viewers. uh doesn't mean that there isn't an opportunity. So, um I'm going to continue building it. I figured, you know, uh talk kind of through what what it's got going on for this video cuz I thought it'd be uh kind of interesting. I know a lot of my videos uh I'm either talking about like, you know, career related questions, software engineering, um focus more around like career and navigating stuff in the workplace.

And then I'll do like AI discussions. But I figured this would be kind of interesting to talk through just like stuff I'm building because stuff that's specifically work related for me I can't talk about cuz it wouldn't wouldn't be a good look to go disclosing like you know private things I'm doing at Microsoft. This I can talk about. So um Squeal is just the the temporary like working name. It's uh I wouldn't I don't think I would release it to the public as squeal because I don't think uh I don't think that that's going to be a great name. It's just kind of funny. Um but what it is, how it works, let's kind of chat through that. So um I'm always interested when I'm building software. Um you've probably heard me in previous videos talk about like plug-in based architectures. I like being able to compose things.

So I like the idea of plugins. I like being able to say like how do I take the same pieces and just repackage them in different ways to get um you know what feels like a whole new um thing even though it's the same effectively the same pieces or parts of the same pieces being reused. Um and so when I was designing Squeal that's exactly the approach I took. So um you can use Squeal as sort of like a standalone application. So you know the most simple thing right you're like what I was do doing using my SQL workbench just want to launch an app connect to my databases work on stuff and then be done not think about it so you can use Squeal that way um and so you launch the app it's got everything you need you can um connect to your databases do your querying blah blah blah you can also use it sort of in a hosted mode.

So that way um there is a hosted server authority and I don't mean the database being hosted. I mean like um your permissions and things like that uh are done through a hosted squeal server and then you can have clients connect to that. And the idea for that is sort of like central management, right? If you're thinking about a a business and you want to make sure that people have uh you know proper access or they're able to do things securely, uh instead of having everyone's desktop client just kind of do whatever they want, manage um access all willy-nilly, uh you avoid that by kind of going through um a more central authority. So you can use squeal um this way as well. And then aside from just the form factor of like client server versus standalone, um, Squeal also has like it is an application with a user interface, but you can also use an MCP server and just do the whole thing headless.

And I figured that would be a good thing to to integrate because I think probably for a lot of us we're realizing the more time we're spending with AI and a lot of AI workflows are you know terminal based. you're talking with an agent. Um, there's a lot of stuff that that I'm in like I think I've explained this many times in videos. Like I've gone from being a Visual Studio user my entire uh software development life to like I haven't opened up Visual Studio in months, right? I I'm the kind of person and I stand by it where you would hear me say like why would I ever use a terminal when I can use a user interface with more rich information. And I still stand by that. It's just that the terminalbased agent software development process is so much further ahead than being in an IDE.

It would be it feels stupid for me to stay in an IDE. So um I've been building squeal in a way that uh if you wanted to do like agentic development and you know in uh interact with your database then you can you can use squeal this way um so that you give access to your agent and it can use the MCP server. One of the things that I wanted to make sure I built into it was uh you kind of heard me talking about like plugins, modularity, composing it in different ways. I I want to make sure that one of my other requirements was satisfied. And one of the things I mentioned at the beginning of this video was that when I was doing some activity with co-pilot, I really wanted to make sure that I felt safe that it wasn't going to touch my production data, right?

I want to you I can I understand that if I'm running heavy queries on a database that, you know, isn't scaled properly, sure, I could have impact, but uh you know, I don't want to risk like losing data. Uh so you know if if I don't have trust in AI when it's connecting to my database that it's not accidentally in a delete things you know drop table kind of thing. Um I need to I need to have like a guaranteed way that it truly is read only even if it tried to run commands um that could be destructive that like it's just physically incapable of doing so. So that's one of the things I've built into Squeal is that like there are modes um where you can sort of force it into like a readonly mode and uh and that way you can operate it as such, right?

Um again this isn't a unique thing for Squeal. There's other tools that allow you to do this kind of thing, but that's like a core piece of functionality that I wanted to have. um on the plug-in idea, right? There's like there's different layers of plugins and different sort of uh areas of functionality for plug-in support. So, probably the most obvious one is like, well, what database does it support, right? You might guess already uh MySQL because I mentioned that uh but there's no reason that it has to be MySQL specific. So, the entire platform is plug-in based. Um I have already a handful of plugins for different database providers. So there's Postgress, MySQL, I think there's SQLite, uh one or two others just to kind of start with. But the idea is like it doesn't matter. Just go add more plugins. So I will continue to add more because why not?

Um and then the idea is also that if you wanted to bring your own then you can. Um, and right now it's it's technically only uh for SQL, but I I see no reason why it couldn't be extended to, you know, to other other database types. Um, I'm not rushing to do that because SQL is my primary use case and I would rather, I think, get more surface area on SQL database providers than before rushing into like MongoDB or something. But I think MongoDB is a good example, right? Like um at some point I will look into can I do a database provider for MongoDB? Um and and what surface area of the product has to change to be able to accommodate that, right? Like if we think about it for a moment, um you know, things like SQL databases are are often just represented with tabulated data, right?

You could think if you're you might be listening to this and you're not totally familiar with SQL databases and if not like one way to think about this is like are you familiar with a spreadsheet right like we have rows and columns in databases and then they have relationships between them. So, if you're not totally familiar with a SQL database, my suggestion to you would be like think about it like having uh an Excel workbook and then having um different tabs in your Excel workbook and you might say like you know on on one of your tabs you have data that is related to data on another tab, right? Just to give you a a different uh I don't know parallel to think about this kind of stuff. And um and so these are relational databases are represented this way and you have relations between each of the tables.

in a document database like MongoDB for example um we have structured data like JSON objects and so it's a lot less like tabulated data and a lot more like individual JSON blobs objects documents and so in both cases you can run queries right um in both cases you can you know insert delete, that kind of stuff. Updates are maybe like where you'd see some like uh I don't know, some more significant differences. Uh how you how you join data when you're querying data across different um like tables or collections for uh for document databases. Like that's where you might start seeing more differences. And there certainly are lots of differences, but again, just kind of introducing this concept for you if you're more new to it. So there's a lot of similarities, but a lot of differences in how the data looks and feels. So if I wanted to extend Squeal for something that's a document database like MongoDB, I need to make sure that like you can work with that data.

So if I only supported tabulated data, you might say, well, this is a real pain in the butt. If I'm opening up something like a JSON object, how would I even show that? So I think what's pretty cool though is that uh Postgress and I mean you technically can do this in uh MySQL as well. I just feel like it's uh better in Postgress, but like you can have JSON uh and you can technically have like more of like a first class type of JSON object in Postgress. So maybe the answer is like you know a good segue is making sure that I have good JSON object support for Postgress. do that early, make sure that feels really good. And then there might be some other things like this where uh by the time I'm, you know, more ready to entertain something like a document DB support like MongoDB that I've done uh some of that earlier work to make sure like it's qualified.

It's probably still going to be uh a reasonably heavy lift. I don't think it's going to be trivial to just like support that. Um, it's one of the challenges with plugins, but I think it's doable. Um, and so on that note, like what do I mean by one of the challenges with plugins? Um, I think if you're not familiar with, uh, building like plug-in based systems, uh, one of the things I kind of would get you to think about is like I'm sure for many of you, you've as you're writing code, you've come across opportunities where you're like, hey, I'd like to, you know, refactor this code so I can reuse something, right? Um, you might have code that's kind of scattered and duplicated in some spots and you'll say, "Cool, like let me take these pieces and put them into one spot." And so, one of the tricky things with doing this is like legitimately in some cases it might just genuinely be duplicated code.

Um, and it might be two, three, five, 10, 100 spots and you like, "Okay, it's literally duplicated. Let me lift and shift it and I can just reuse the same code." Excellent. Um, it gets trickier when you're like, I want to refactor because things look similar and they might be slightly different, but like let me kind of take two, three, handful of things and they look similar, but I want to massage them into like the same thing, right? Like they're not exactly the same, but I can probably do a bit of a hybrid and make them all share the same thing. When it comes to plugins, I would say there's similar sets of challenges that you need to work through. And the the biggest risk in my opinion or one of the biggest risks is like when you haven't seen enough of the pattern you're trying to do, when you haven't seen enough of the pattern and you try to make a common API, right?

Like to how what what API are your plugins going to meet and you haven't seen enough of the pattern. And what ends up happening is that you you do the best you can with the information you have and then you build a handful of plugins that meet this API and then you have something that gets introduced where you're like, "Oh no, it doesn't meet sort of the the convention or the the patterns and practices that I need to follow for my plug-in system." So now you have to go change the shape of your plugins, right? like one of these options is to change the shape of your plugin. So different API, you're doing some different work um to accommodate these new patterns and that means that for all of the plugins you have like how do you make sure that they're supported and they meet the new convention.

So, uh it just becomes a really tricky thing if you haven't seen a lot of the pattern before you go to implement um your plug-in sort of uh standard. So, you know, for me like if we use an example in Squeal, if I have, you know, three SQL database providers, adding a fourth one is probably pretty straightforward. A fifth one becomes easier. like it gets easier and easier because you've seen more and more of the patterns. And so going from one to two, if you made the plug-in interface and the spec for it only based on one plugin uh sorry like one database provider and then you go to the second you might say well okay crap like you know go to give you an example going from SQLite to Postgress like Postgress has a lot more functionality than SQLite and so like uh you

know if I want all that exposed for Postgress like what's the compromise or what do I need to do to make sure that SQLite and Postgress feel, you know, equally supported. Uh where Postgress functionality isn't nerfed because SQLite doesn't do it and SQLite can still be used even though it's not supporting all the same things Postgress does. Like how do you balance that? So now you're at two and then you go, okay, well I want to add MySQL support. Okay, well you know maybe MySQL has a lot of overlap with Postgress in terms of functionality. So it's not so bad to go add MySQL. Okay, so now we have three and then you go to add in the fourth. And basically my point is that the more pattern you see the less churn you have with adding new ones that are similar.

So by the time you have, you know, 10 SQL providers, adding an 11th one, you're probably in pretty good shape that you're not like, "Oh crap, we've we've never seen this before with a SQL database." You you probably have seen, you know, most of it. Then you might start having rare exceptions. And then at that point, you might say, well, do I even care about exposing that functionality or is it just like forget it, right? like I don't want to go change my plug-in interface when you deviate from that. And so like with this MongoDB example, if I jump over to MongoDB, is that so dramatically different now than my SQL providers? And if I've done, you know, 10 15 SQL providers, is there enough variability there that going to a document database is actually not too far of a departure? I'll have to see. But that's just something to think about with uh with plugins.

So, not only does Squeal have plug-in support for all your database providers, but AI providers as well, because it is um not only like uh an MCP server, but also within the UI application, you have an AI assistant that's embedded, which also happens to use the MCP server, which is pretty cool. But I'm not going to sit here and say, "Well, you have to go use this AI provider." Like, I don't care which one you use. Like, I don't it doesn't make a difference to me. Uh, and in fact, I think you being able to use whatever AI provider you want is probably in not only your best interest, but my best interest as well. Like, why why should I limit you? I am not the AI provider. It's not it's not in my best interest to say, "Hey, use use Nick's AI." I don't have that.

Maybe there's an option that it's like, you know, if you don't know what AI provider you want, sure, maybe I, you know, can do billing for some AI um, you know, model that I have hosted and then I I upsell a little bit on it. I'll probably do something like that for the the commercial version of it. But like I would I wouldn't force people into using that because it just seems like that's not helpful in any way. It's a more of a deterrent if anything. So the AI providers themselves are also plug-in based. Um and that way you know I ship with a bunch of them and then if you're like well Nick Squeal sucks because it doesn't support you know custom AI gateway ABC. like go build your own plugin. Um, you know, it it should allow you to do that without being an issue.

And that way, uh, I don't have to support the world. Uh, I can let you have the tools to support what you want. Um, what else? What else is interesting about Squeal? Um this for me is kind of an interesting project because uh it's using Electron. Um so there's a lot of like web development that I'm if you listen to my other videos like I am not super keen on like front-end webdev. Uh I all of my experience that I've enjoyed is in is really in backend development. So, um, it's been kind of neat to have something that I can work on like this. And, uh, in some of my other videos, like back to AI, right, for heard me talking about like how do I get patterns and practices kind of pulled together so that I can build um, you know, applications more cohesively, give AI the right guidance.

And so Squeal's been a really good one where I I feel like I got pretty lucky that early on Copilot put together a UI sort of layout and flow where I was like, "Hey, this this actually feels pretty good." Like it's not I've had definitely opposite situations where I just get something junk and I'm like, "Oh god, like how do how do we move away from this as fast as possible?" Squeal was actually like, "Hey, this feels pretty good." Um, and so like how do I take what feels good about that, how it was designed and start recodifying that into, you know, agent instructions, right? Um, I noticed that as things were getting built, um, co-pilot was doing the typical thing that AI does where there starts to be more and more drift. So, you know, having that conversation around like how do I how do I make sure that the agent is following patterns to avoid drift, right?

Like centrally uh themed uh controls so that I don't just have like a hundred variations of buttons. Um, if I told co-pilot to tomorrow, right? Like, hey, the UI is blue themed and I want it green themed, I would expect that it goes to one spot in the entire application and changes the theme, not across the entire UI like changing uh, you know, hex codes and fonts and stuff like that. Like, absolutely not. Needs to be done centrally. So, it's been a really cool opportunity for me to like to practice that because I've seen, you know, we go to add some new screen or add some new functionality and I'm like like suddenly this this UI that felt pretty good is now getting like kind of kind of wonky and then I'm like wait a second like these buttons are slightly different or like I'm

noticing on this screen there's like like eight different font sizes and maybe a couple of different actual fonts and I'm like this is just it starts to make it feel like really awkward and like cobbled together. So, how do we take a step back, unify things, and then encode instructions that way? And what's great about all of that is that not only do I encode those instructions into the squeal repository, I I borrow them back into a common one. So, the next time I go to build an application, it's following patterns and practices from day one that I'm happy with. So, um, that's been pretty cool. But anyway, I think I'll wrap it up there cuz I'm just sitting in traffic now. Um, my ETA has now blown past my appointment time. So, that's great. Uh, it's kind of a 24 minutes of traffic added on this route, which is which is lovely.

Um, Seattle is awful, but I'll wrap it up there. Thanks for watching. Um, I'll make some other videos and some of the other things I'm building as well if this was helpful. And uh, yeah, I don't know. Hopefully this kind of format was interesting where you can hear a little bit about the things that I'm building. I realize that talking about code and not showing code is maybe a little bit awkward, but maybe the, you know, the design and concepts were were kind of interesting to hear about. So, thanks for watching and I will see you in the next video. Take care. How do I turn this thing off?