High Performance Django at Ten: Old Tricks & New Picks with Peter Baumgartner

Speaker 1: All right, high performance Django. Uh how many people have heard of the book, High Performance Django? Have read the book, High Performance Django? Okay, a few. Awesome. Uh so um it's not actually 10 years old, it's 11 years old. 10 sounded like a nice round number, but uh we released in 2014. Real quick about me, I'm the founder at Lincoln Loop. We are a web agency focused on Python and Django. We do really big greenfield project builds. We do performance and scaling and we are full stack everything from design and strategy to operations and DevOps, which is kind of my focus. Also creator of APAC.

Speaker 1: APAC is like a Roku -like interface for your own AWS account because AWS is super confusing. And um uh what we're here to talk about today, the co-author of High Performance Django. So High performance Django came out of a lot of lessons that we learned building high-traffic Django websites long, long, long ago. One of the first sites we built was a really large uh video game review uh site. Um so they yeah, they would review video games. It had like comments and a bunch of social features. And when a new game would get released, they would get smacked with a ton of traffic. Um, and also

Speaker 1: some really high uh high-scale um publishing platforms that would you've heard of that sit on the front page of Reddit or Hacker News all day long. So we learned a lot of stuff the hard way. um definitely took our lumps and dealt with outages and things on fire and um came came up with a system that worked really well for us. And I my my light bulb moment for writing the book was an engagement we had with a client who had I don't know 20 or 30 really smart Django developers on staff and they were having this performance problem that they just could not figure out. And when we kind of lifted up the hood and looked at what they were dealing with, it was, you know, uh it was a mess. Um

Speaker 1: they had just completely given up on Django being able to serve any traffic at all. It was too slow in their eyes. So uh they had built this kind of background caching system that uh Django would never serve traffic and when they made a publishing change All the pages would get re-rendered and served statically and it did not work well at all. So I wrote sat down and kind of wrote my findings down. And was like, I I could write a lot on this topic. And I probably wrote two or three thousand words and said, hey, there's a, you know, there's a book here, I think. At the time, Kickstarter was a really big deal. So before writing the the full book, I went ahead and

Speaker 1: Launched the book on Kickstarter. We set a target of $5,000 and I said if if if we can raise $5,000, we'll we'll go ahead and write the book So that was May 12, 2014. We hit our target in three days, $5,000, and we completed June 11th with just over $13,000 raised. Uh that was followed by total existential dread that like I actually have to write this thing now. Um it was uh The first few thousand words came out really easy. There were a lot of sections that were not super easy, either because, you know, I I I wasn't as deep on the topic as I should have been, I felt like to be writing a book, or it was just not something that interests me, but it it needed to be part of the book.

Speaker 1: So uh it was a painful grind Towards the end, lots of imposter syndrome, what am I doing? You know, I'm I'm not an expert here, and lots more dread. But finally got it done September 12th, 2014. Thank you. Yeah. So this is the first question a lot of people ask. Was it worth it? And I think uh a lot of people don't really share the the numbers behind all this and and um to figure out like is is it is it worth writing a book of your own Uh so I'm happy to share. I already told you we made uh a little over 13,000 on uh Kickstarter.

Speaker 1: This is Amazon. We self-published the book. So Amazon does print on demand and Kindle, so a little over $10,000 there. And this is Gumroad. So Gumroad was PDFs and like e-reader format that's not Kindle. So a little over $33,000 there. And you can see all of these There was a big push for it and then kind of a long tail. Quite honestly, I was exhausted and didn't have much to kind of keep this going over the years. So you can see Sales have really trailed off. It's now for free online if you want to read it. But the total sales $57,514.

Speaker 1: 20 So uh was it worth it? I would say yes. Uh we also, you know, uh we run a consulting agency and um certainly it helps to be able to say, you know, we wrote the book on this. So there's benefits there. There's also benefits. It's been really nice like having random people come up to me and tell us that they've read the book. This is a somebody I kind of randomly connected with on LinkedIn this uh the earlier this year and they said high performance Django was essentially required reading at their uh work and they had a million subscribers and and thousands of concurrent users. So stuff like that feels good. It's had some legs and I think we've really helped some people.

Speaker 1: So I would say I you know I haven't looked closely at the book in many years. Um the talk got accepted and I picked it up and I reread reread it. I had a lot of feelings and emotions rereading it. You know, my first one was kind of like, like, yeah, like this is, yeah, this is still pretty relevant. Like this, this will work. And kind of followed by like giving myself permission to be like, this is good. You know, I think when we really when we do stuff on our own, we see all the problems and the warts and the things that could have been better. Um but I felt like yeah like I'm I'm proud of this work. And there are also a lot of these of just like, what was I thinking? I would not do things that way anymore.

Speaker 1: uh a lot of realizations that technology in some places has moved quite a bit um from where we were in 2014. So with that in mind, I'm gonna um Go through some sections of the book and talk about uh places where I think we got it right, places where I think we got it wrong, places where uh the world has moved to a different location and and I would um do things differently. So uh this is definitely a subset. I uh I had a hard time getting this talk into forty five minutes and I last night like butchered a bunch of slides out to try to get it in there. So um start off with uh the first chapter is called The Big Picture. And the Big Picture is basically just

Speaker 1: Painting what we're going to be doing, the general architecture we're going to be using, the systems we're going to be using. We start off with talking about simplicity, uh, and and simplici simple sites are easier to scale, easier to understand, and easier to develop. Um I am a hundred percent uh Uh let's see here. 100% still uh believe this. It's it's the way to go. Uh as you build software, um over time it just has a tendency to collect complexity and you really have to push back and fight it. For us, uh simplicity is as few moving parts as possible, and you can define moving parts multiple ways. It might be services you need to run to

Speaker 1: you know, uh service of the application, it might be the num, you know, the lines of code you have, it might be the dependencies you pull in, the fewer the better. Using proven and dependable technologies, I really loved uh Carson's keynote on the first day. He referred to these as seasoned technologies instead of whatever the new hotness is. The interesting thing about kind of what we talk about in the book is it's it's really not new information. People have been scaling Perl sites and PHP sites and Ruby on Rails sites using a lot of the same techniques over the years. And uh so there's there's prior art here that we can lean on. Um uh using uh that

Speaker 1: that kind of is the next point, proven and dependable architecture. This has been done before. Um people know how to do this. And deflecting traffic away from complex parts. The most complex part of your system is probably your own code. So anything you can serve out of cache. or you could work you can do elsewhere uh is going to be beneficial in the end. Love it. Totally, totally on board. And some of you may be hearing this and saying that sounds a lot like boring technology, which we talk a lot about. I looked up uh this was an essay by Dan McKinley. It was actually published eight months after our book, so I'm not saying he took inspiration from us, but uh he definitely did. He learned all these lessons working at Etsy.

Speaker 1: And I think there was some kind of appetite in the tech world around this time of like What are we doing? We're making our lives harder and let's get back to doing things simply and and boring. Uh and one interesting thing is Django has kind of swung from one side of the spectrum to the other uh in that time. At the time in 2014, Django was still kind of new, uh kind of interesting. People didn't quite know, you know know how to work with it in this scale and now it's kind of firmly I would say in the boring technology in a good way. It's you you know how it's going to behave, you know what it's going to do. This is a uh picture from the book of roughly how kind of how a request goes through your system.

Speaker 1: It's going to go through a load balancer. We Called the next layer the web accelerator, which is kind of a term that people don't really use anymore. I don't know if they used it much then. Um it's essentially varnish uh or uh CDN um your application cache database. One thing I would change here is I would move this layer up. So we used to uh deploy our application and we would deploy varnish instances uh behind our load balancer and and varnish is a tool that lets you serve traffic really really fast. Today I would push people towards using a CDN for this uh and we'll get into that here. So these are the um some of the kind of tools we

Speaker 1: we recommended in this space. I tried to be somewhat opinionated in the book. Now I'm probably even more opinionated. So I would say these are the tools I'm looking at today. Amazon load balancer, most of our stuff is deployed on Amazon. If you're using Google or Azure or whatever, they all have a load balancer that you can use. Cloudflare is my kind of CDN web accelerator of choice. Fastly is also awesome. They handle PyPI's traffic. And they're essentially like a very fancy hosted varnish. We still use UWISGI. It has kind of uh The maintenance of that project has sort of ebbed and flowed over the years, so I'm a little like hesitant to uh

Speaker 1: say jump on that one. So I would say GUnicorn's got the mind share and it works. For a cache, I would just choose Redis or Valky, the open source fork, and we should all just be using Postgres. There's not really a great compelling reason to use MySQL. anymore. So next chapter is the build. We get into like specific tools, how we how we make this all happen. One of the big themes in this talk is the book was very server-related. You know, you're getting a bare Linux server and you're installing your tools on it. And Docker was a thing in 2014, but it still had some rough edges. I don't think the hosting

Speaker 1: platforms were were there as much. Now I think you know it's it's the place you want to be. One of the big motivations for this for me, uh maybe Big's overstating it, but uh I think a lot of folks are dealing with um compliance security issues these days, SOC2 audits and things like that. Not managing your own servers is a huge thing that you don't have to deal with in that. Like if you manage your own servers, they're gonna ask you how you manage your SSH users and what sort of you know encryption you're using and you know what antivirus you're running on your Linux servers, which is nuts, um, you know, what you're using for intrusion detection and all this stuff and uh going to manage containers, you can just be like

Speaker 1: Look at Amazon's SOC2. They'll answer all that stuff for you. So if you're in a kind of secure environment, I'd say there's even more compelling reasons to do this. And again, this is my opinion. People certainly still deploy on servers. I had a great talk with um one of the devs that works with um Adrian on SoundSlice about how they're deploying. and it's like uh deployments from 2005 and it works awesome for them and I loved it. Like I was kind of end of the simplicity of it. So you can do it any way you like, but this is my recommendation. So I'm gonna go through some quotes from the book. The uh one strength of Django is the Python ecosystem, 100%.

Speaker 1: Uh unfortunately a lot of the things you'll find out there, reusable Django apps, are not Built for high-scale, high traffic situations. So you have to be really careful about the packages you pull in. And you need to understand kind of how they're working, what they're going to do on your database. And you may find, you know, a lot of these were built for very flexible, uh, to be very flexible and fit lots of different solutions. And you might find that a very focused uh solution might be be a better option for you. So just be cautious, don't pull in the world. Another caveat here is if you want to build software that lasts five, ten years, you have to be really careful about the things you're pulling in.

Speaker 1: uh randomly from the internet because a lot of them die and don't get maintenance and you have to be ready to say um all right now I have to take ownership of this because we use it and we depend on it but it doesn't get updated anymore So proceed with caution there. We have a whole section on optimization. So in almost every web application, the database is the bottleneck. This is still what we see. There are some exceptions, but generally your database is going to be the slow part. So dealing with that. We get a lot of folks that come to us with performance problems, so we get to see lots of different apps and and the problems they have. And I'm going to highlight a few of the ones that we had in the book that I also still

Speaker 1: see with everybody that comes to us. If you don't keep track of the what your application is doing, if you don't have a way to monitor it and like an application performance monitoring system and nobody's looking at it. It's very common to see pages that have hundreds of database queries on them, sometimes over a thousand. So select related and pre-fetch related are your friends here. They're super easy to use, but you just have to identify one to use. The ORM makes it really easy to trigger these N plus one queries where you're looping over a set of blog posts and looking up an author's name, and that's triggering a query on every loop. There's a package out there called Django Zeal ,

Speaker 1: which is interesting for using in development. It can catch some of these before they make it out into production Thumbs up on that one. Uh missing indexes are interesting. So um missing indexes in your database. When you build your application and you have a few thousand rows in your database, you never notice that you're missing it important indexes. And then your application gets popular and you go from a few thousand rows to a few million rows and you really start to feel this pain. And if your developers are all working on databases on their local machine that are like you know, kind of little developer databases, they're never gonna notice this. Uh so finding these places and applying the right indexes is another place where uh

Speaker 1: APM application performance monitor can help a lot. And it kind of requires some specific database knowledge to understand where to put these and how to test that they're working and all that. Uh we go into that in the book. I will say LLMs uh are really good at this stuff. So doing an explain analyze on a query and putting your table definition into the LLM and saying like how do I make this faster? can often yield good results. Uh counts. Um again 100% on this. count on a query set, once you get two millions of rows, it's not an option. Like you know, it's it will 100%

Speaker 1: be slow and you can't can't make it faster really. You need to look at avoiding those wherever possible. You can do approximate counts and You know, there's solutions around this, but uh if you're using counts a bunch in your uh code, um that's gonna be a problem. This was a topic that we were really hot on at the time, um, query caching, and I don't hear too much about it uh these days, but it's the idea um you have a middleware in your application and essentially Any calls to the ORM get cached. So every database query you make ends up in a cache. And if you make that database query again, it comes out of cache. Uh if you write to the database, it's smart enough to know how to invalidate um

Speaker 1: parts of the cache. Uh for this I'm kind of like, eh, um I I wouldn't say many workloads, I'd say some workloads. If you're really read heavy, uh this is um still something worth looking at Johnny Cash was the package previously. Django Cash A Lot is now the one that I would look at. But these come with some big caveats, so Yeah, I don't know. Be careful there. Uh doing slow work later. Uh I am 100% on doing slow work later. I feel like just telling people use celery is maybe negligent. Like celery is a frickin' beast of a thing

Speaker 1: and it has eight million knobs you can twist on it. And uh I my what I see is it does not behave the way people expect it to um when they pick it up and start using it and you hit all sorts of um strange edge cases. So uh I still think celery is probably the job cue of choice in our world, but I would probably spend a lot more time explaining some of those knobs and how they affect the the way the queue acts. The other thing that I think has come up in the meantime is uh Async, uh Python async is really interesting and Celery is not really like a an async native um queue and we are

Speaker 1: building lots of apps now that are making calls to LLMs that are HTTP calls that take two or three seconds and if you're not using um you know some sort of uh concurrency model there Having a CPU sit and wait two or three seconds for a response from an LLM is not an efficient way to operate. So one of the projects I'm interested in, I haven't had a work chance to work with much here is called temporal. There's also some other open source stuff in the um Python world that is a little more async native uh In 2014, hosted CI was not so much of a thing. We had Travis CI, which was a big deal, and everybody used it for their open source apps, but um I don't feel like people were really using it for

Speaker 1: They're like internal projects. I would not use Jenkins anymore. We use GitHub Actions. Whatever comes with your code repository service is probably good. Your cloud provider probably has something to. This is a theme we'll get into in a little bit, but let somebody else do it. Uh so next section is deployment. Um for deployment uh We have a section on auto-scaling, and we're it's kind of like a lukewarm, like yes, auto-scaling exists, but it doesn't work in a lot of scenarios. Um Autoscaling's gotten a lot better. There are databases now that that do auto scaling, Postgres

Speaker 1: databases that do autoscaling, which is a really Interesting thing. It used to be moving your database to a larger size or doing that dynamically was like you know, impossible. Um so that's interesting. And I think um as you move from kind of server-based thinking to container-based thinking, auto-scaling gets a lot easier. So I'm a fan of autoscaling. I would probably be like a little more hot on it now. I don't use it for all databases, but in some cases it's a really compelling. uh option. The the one thing I would call out on autoscaling is auto-scaling's great if your traffic goes up like this. Or like this, I don't know. Uh but um it's not great if your traffic does this.

Speaker 1: Uh you you need a minute or two for the autoscaler to see like The load is rising or whatever metric you're catching it, and then it needs some time to pull down containers and spin them up and pass a health check. So Scenarios where we see this are overzealous marketing teams sending out an email blast to like 250,000 people and then like half of them click on a link right away. That's a good way to take your site down Ask them uh either plan for that or ask them to spread it out over some time. Uh also uh we see this in like classroom environments. So you you build like a education simulation. And a lecture hall of 300 people is all going to log into the application at the same time. Logging in is actually like a really expensive thing on CPUs

Speaker 1: intentionally because password hashing and all that. So Um those auto scaling won't help you. I mentioned this theme. Um I think In 2014, I felt much uh it was much more important to me to to run all the infrastructure ourselves and to be self-hosted. And uh I think the you know know, gray hair and um having uh ten, eleven more years of experience. I am much more in the camp of just just let somebody else do it. Um it is expensive the the People look at a cost of a thousand dollars a month and they're like, this is crazy. I could put this on a five dollar VPS and you know, um, you're counting your time for zero

Speaker 1: dollars when you make that uh assessment. The total cost of ownership of solutions is much higher than just starting a container up on a system. I actually read an interesting article about this. There was uh uh Datadog came out with um their financial report years and years ago and um there was It was obvious that they had lost a single customer that was paying them $65 million a year. And the the customer was Coinbase. This uh it's the pragmatic engineer. He went around and he 's got contacts in all the big, you know, organizations and said what This seems nuts. At what point do you actually start considering

Speaker 1: moving a vendor relationship in-house? Like what costs are you looking at? And the general consensus he got there was two to five million dollars a year. So, you know, um think about the the team it takes to maintain these things. Think about the expense of when you're working on your application versus working on some ancillary service that somebody else can probably do a lot better than you. It might not be two to five million dollars for everybody, but uh it's it's probably the the $500 , $1,000 bill um you you're probably gonna make up uh uh by being able to focus that time on your application versus other stuff. So first up in this category, Postgres.

Speaker 1: We are talking, we have we're talking about Postgres. You install Postgres on a machine. There are a whole bunch of dials you've got to turn to make sure that Postgres actually can use all the resources on that machine. Just use RDS, use crunchy data, use a managed provider, uh you know, not having to worry about backups, um, not having to worry about you know um having simple paths for upgrades, being able to quickly switch machine sizes, not having to worry about replication. This is one that I was glad to hand off and I hope to never have to administer. or database again. The observability stack. So this is one at the time we were using graphite.

Speaker 1: That was kind of what people used. Graphite 's no longer really a thing. Prometheus is the new thing. Again, I would recommend you don't bother running that yourself. Let somebody else do it. And there's beyond the kind of total cost of ownership and time, there's some compelling reasons not to have your monitoring and alerting running on the same infrastructure as your application. If your infrastructure, if something goes down, you really want your alerting system to let you know. And if it's all in the same place, that might not happen. Um alerting, this one I'm kind of just like, what the hell are we doing here? Uh it I I feel like there weren't really great options in this space in 2014.

Speaker 1: There were some systems that were Designed for I have a rack of servers in my colo, um, but like the modern stuff wasn't really all that mature. So you know again I feel like there's there's other providers that do this. Datadog 's great, Amazon CloudWatches, it works. Your other cloud providers will offer something here as well. Logging, we were on kind of this like modified elk stack. This was one where I was like, you know, we're like Talking all about like simplicity before and like now I'm asking you to run Elasticsearch and all this stuff. Like no, like don't Don't do it. Let somebody else manage this for you.

Speaker 1: Again, CloudWatch, Datadog can do it. Sentry just released a logging product, which is exciting. They're great folks. Uh error reporting. Um actually feel better about this one. We did okay. Uh I still think century is like a key piece of infrastructure for any application. Um it doesn't have to be century, but um They're Django, they're great. Like they're um yeah, I just say use century. Their open source is like they're a little less open source now, but it shouldn't matter. Use their hosted version. Okay, so preparation is the next part. Preparation is you've got your code ready. You've got your infrastructure and your deployment already.

Speaker 1: How do you make sure that you're not gonna just completely topple over once you send start sending traffic to this? So this section is largely about JMeter. We had somebody working with us at the time, Brandon Conkel, who did this like awesome blog post series on JMeter. J meter was kind of like the king in load testing at this time. His blog series is great for JMeter. I don't really think JMeter is where I would go anymore. Hey is a really cool tool. It's written in Go. It's super fast. It's great for testing like individual endpoints. If I wanted to do something more sophisticated, like I want a user to log into the system

Speaker 1: and post an image and then you know, browse to their profile page, I'd be looking at something like K6 or Locust. But the reality is I put a lot less focus on load testing these days because infrastructure has gotten so good at being elastic and it's so easy to kind of adjust sizes on things on the fly. I'm looking at load testing to just give me a sanity check that I'm in the right ballpark, but I'm not gonna have a, you know know, um massive load testing suite that um it tests every single option, you're you're gonna be wrong. uh with whatever you do with load testing, uh you're gonna think users are gonna do something and they're gonna do something else that completely surprises you.

Speaker 1: So um it's kind of like the 100% test coverage thing. You know, just because you have 100% test coverage doesn't mean you've actually uh your your code is bug free. Um okay, so uh there are some things that I didn't cover in the book, either because they just didn't exist at the time, or um stuff that I've we've kind of learned and and adopted since then. Um the first one is Django channels and async, um which is really cool new tech from Django, well new er. I have not had an opportunity to run these in a like really large-scale environment where performance is a concern.

Speaker 1: So I reached out to some folks to get info. from people that are doing it. And um a few of the folks I reached out to that had been kind of like communicating on tickets and seemed like they were using it in their bigger companies were like we can't use it. We have seen like various blockers, like somebody wanted to use memcachd or I I don't know, um the various reasons why people like couldn't use this. The people that were using this, um I got the impression that they have learned a lot of stuff the hard way. I think this is more, you know, when we talk about Django being boring technology. I would say Django channels is probably not boring technology. You're gonna find some like interesting stuff

Speaker 1: heading this way. I don't think that's to say you shouldn't use it, but just be aware. One tip I did get is uh the Django Redis, Django channels Redis uh package is use the pub sub channel, um not the Redis channel layer. Everybody I talked to that was using it said the PubSublayer is the one that um scales much better for them. Uh another topic I would talk about is continuous deployment. And I I think like everybody probably that uses a some sort of CI system is like, oh yeah, we do continuous continuous deployment. C-I-C-D, CI C D I do continuous deployment. But I'm talking about like real continuous deployment, like where like a feature's done, it's accepted, it goes live. Not like

Speaker 1: We have a date that we are going to do a release and we're going to wait for all these new features to pile up and then we're going to like toss them all out into production all at once. One of the things that's great about real continuous deployment is you get a lot of practice doing deployment. And deployments are the probably the most likely place where something's gonna break or go wrong. And the more you practice it, you know, like any muscle, the the better you get at it And then also your change sets that are going into production get much, much smaller. And it's much easier to debug Small change sets that cause problems rather than like a month backlog of work that all goes out into production at the same time. So I would really stress this.

Speaker 1: Just get good at at deploying all the time and get comfortable with it. And if you're having trouble with deployments and uh it's like Most most folks are like, we had a deployment that went bad, we're gonna do less of that. Um and really you need to do like the exact opposite, like lean into it. Why did it go bad? How do you fix it? How do you kind of keep this um ball rolling forward. Rollbacks are one of the ways um you do this well. So one of the most stressful things about a deployment gone bad is uh you have to fix it on the fly. Um and trying to debug an issue and uh you know

Speaker 1: quick code up a fix and quick push it out into production. is a good way to end up with like much bigger problems to totally stress out your team, ruin morale, like have turnover, like nobody likes this. Rollbacks are a great way to be like, hey, this deployment, there's something going on. We don't know what it is. I'm going to click a few buttons and roll back to a previous version that we know is good, and then we can take the time to figure out what went wrong. For rollbacks to work, you need backwards compatibility. So wherever the state is managed in your application, usually it's in the database, you need to make sure that the state is compatible with both the previous version of your application that's running

Speaker 1: and the current version that you're deploying. So this means looking, thinking about Django migrations a little bit differently. You can't just go in and say, hey, I'm just gonna rename this column or I'm just gonna, you know, drop this column out of the database because uh you can't roll back. You're burning the bridge behind you and you're saying like, you know, we're doing this no matter what. So um uh there's lots of good um talks and and uh uh who gave uh Tim Bell gave a great talk about this. Was this in your talk, Epha? Yeah. There's talk this uh uh This Django count about it. But um yeah, so backwards compatibility. It makes it possible to do rollbacks, which makes it possible to do

Speaker 1: uh real continuous deployment. So to wrap up, this is the quote we kind of end the book with, and I still think it's great. Instagram is famous for scaling to uh you know the size where they were millions and millions of users with a skeleton team of like three people that uh didn't really know how to do deployments or operations. And this is from a post of theirs from 2011. And so their principles were keep it simple, don't reinvent the wheel, go with proven and solid technologies. And they're Django as well if you Didn't know that. Um and one uh the threads app from Meta is also Django.

Speaker 1: Uh so lots of examples of high-scale, high-performance Django still out there today. And that's all I have.

Speaker 2: Thanks, Peter. Uh do we have questions?

Speaker 3: Uh hi Peter. Thank you so much for the presentation. I have a question. Do you have a plan like to rewrite the book with these new changes?

Speaker 1: Maybe. I'm like just recovering from all that like grief and uh trauma from before. So yeah, maybe.

Speaker 3: That would be awesome. Yeah. Thank you

Speaker 4: Um so one of your big things was just use Postgres, Postgres, Postgres. Also, you mentioned you have to be careful what you take from the internet because it might not be around in five to ten years later So if you're a commercial company with downstream users who also use your database, which is not Postgres, how do you recommend? A getting buy-in to switch to Postgres and B switching to Postgres when you have database exclusive users.

Speaker 1: If you're not feeling the pain, maybe it's not super high priority, but if you are feeling the pain, there are I'm assuming we're talking about MySQL here. Yeah. I think from a business perspective, there are s you know, the the licensing situation with MySQL has gotten cloudier over the years and how updates are handled with MySQL has gotten cloudier and uh I I'm not super deep in that, but I've just kind of seen these rumors. Um I also think there are some features in Postgres that do not exist. So if you can kind of make a compelling reason re compelling argument that like We really want to use this awesome feature of Postgres

Speaker 1: and it would help us do X and we can't do that here. Or if you can point to, you know, we had this performance issue that that affected users and it's because we didn't have this functionality over here or because you know we don't fully understand this database well. I I think another thing is um Playing to your strengths. So if you're in a place where like everybody knows MySQL inside and out, maybe MySQL is a better choice for you. But if you're in a place where people are like, ah yeah, I don't I don't know either way. Um Maybe there's a compelling reason to switch. I um there are some tools that will let you switch uh basically take like a MySQL dump and turn it into um

Speaker 1: something you can import into Postgres. I don't know them off the top of my head, but we were just working with a client who did a conversion like this, so I'd be happy to um get that info to you and or introduce you to them um because they may have some thoughts on it and they also had uh a reporting database that their um some of their clients could connect directly to the database and they switched it all to Postgres and seems like it was successful. So yeah. I can get you more info. Has anybody heard on that? Switch from ICO to Postgres? Yeah? What did you use? Oh, you have a question?

Speaker 5: Um Do you see fewer query related issues from teams that use tools like um Django Debug Toolbar for introspection during their development process?

Speaker 1: That's a good question. No, I don't think they are. I think the the worst ones are If somebody has eyes on it, it tends to like not happen, or at least somebody catches it early. The worst ones are when people are just blindly like It's not on the radar. It's like this code is working on my machine and we're going into production and then you know like we're getting reports of you know, slow responses and like nobody's plugged in any sort of performance monitoring ever or ever looked at it. Um that's where, yeah, like you you really that's kind of one of those places where like complexity just like creeps in like it's you know it's 10 milliseconds here it's 20 milliseconds there and like over five years

Speaker 1: you're at like you know 20 second response times um So yeah, keeping an eye on it 's probably the biggest thing. I can repeat her. Uh

Speaker 6: thanks for a great talk. Um along those same lines, uh good news coming in a likely future version of Django, there's a feature at maybe you've had a look, uh, model field fetch modes where model by model or query set by query set, you can tell Django to fetch related entities by default to not have to maintain manual lists of related entities, which can be brittle if you're if there's drift. Um so but I'm gonna turn that comment into a question. Are there other features like that? Do you that you and your experience you've seen if Django shipped this, it could help developers kind of stay in the stay with the grain of Django instead of developing the conception which I've seen is like, oh, Django's slow.

Speaker 1: Yeah. Uh That's a great question. Um I hadn't thought about it, but I do think uh like I I see like the all that performance stuff and I don't know if it's it's Django debug toolbar or you know something like this uh Django Zeal package like being able to Call out like you're making an N plus one query. It's a super easy fix and it's super easy to do too. So you know if we in debug mode, if you could just have a warning that's like, hey You need a pre-petch related here. That might be interesting. I think, you know, the performance monitoring stuff is probably out of scope, but I do feel like it's it's mandatory. One of the things I

Speaker 1: I'd really love to see from Django is a more opinionated, like here's how you deploy, here's how you go to production. And um I think we kind of let users just figure it out on their own and uh Yeah, I I think a lot of people flail with it or they're pulling up some random blog post that may or may not have good information and just giving people guardrails and like uh you know if you do this you're gonna be in good shape I think would be really awesome. Um I uh I don't think it means we can't let people pick weird tools and do stuff other way, but it would be awesome to just be like, this is this is what we recommend.

Speaker 1: Um yeah, which isn't really a code thing. I think it's more of a documentation thing.

Speaker 2: Thanks Peter. Uh in the interest of time I have a final question here. How do you balance performance with cost?

Speaker 1: Yes, that's a great question. Um so uh doing all this takes time. Um and At some point, uh getting a view to respond, you know, a view that responds in 200 milliseconds to get it respond in 100 milliseconds. is not a uh not not valuable to anybody, especially if it's like, you know, it's it's kind of that 80-20 rule. Like a lot of times you can get a lot of work done in the uh a performance work done in the 20% and doing the last eighty percent may not be uh valuable. So I think coming up with some Uh, you know, kind of definitions, I think, of like what what are our targets? How much time do we want to invest in this? Um, is it okay that this one thing is slow?

Speaker 1: Uh, and and kind of taking Uh not losing sight of most of us are coding for or writing code for businesses that are trying to make a profit or trying to make users happy. And um if you just kind of go down the rabbit hole of like, I'm gonna, you know, tune everything and make it great. And like, is it is it making things better for users? Um is it uh you know a lot of times Performance is often related to cost in terms of you know the the slower your application is, the more CPUs you are going to need to serve your application. So there are some compelling reasons to, you know. know get things optimized you can run on a smaller database you can use fewer containers but there's uh point of kind of diminishing returns for sure

Speaker 2: Thank you, Peter. A round of applause for Peter.