Starting in Django 5.0, you can use db_default to define database-level default values for model fields. It’s a great feature but comes with a subtle and dangerous gotcha that can silently break your code before the object is ever saved. The Gotcha in Action Let’s say you’re building a simple task manager, and you want to track whether a task is completed: from django.db import models class Task(models.Model): is_completed = models.BooleanField(db_default=False) The db_default option en...| Johnny Metz
Squashing merges multiple database migrations into a single consolidated file to speed up database setup and tidy up history. Django’s squashmigrations command promises to handle this, but it’s error-prone and unnecessarily complex. A clean reset is faster and simpler. ⚠️ Why squashmigrations Falls Short Broken in Practice In medium-to-large projects, I’ve consistently seen squashmigrations generate poor results, such as failing to optimize basic no-ops (like adding and deleting the...| Johnny Metz
If your Django queries feel slow, the problem might not be your database — it might be your ORM. Recently, I was working with a query that took 25 seconds to run through the Django ORM, but the underlying SQL completed in just 2 seconds. With a single change, I got the ORM query down to 2 seconds as well — and reduced the memory footprint by 70%. Let’s walk through what happened, and why using .values() instead of .only() can dramatically improve performance.| Johnny Metz
The N+1 problem is a common database performance issue. It plagues ORM’s, such as Django and SQLAlchemy, because it leads to your application making more database queries than necessary. Let’s look at a basic example in Django. class Artist(models.Model): name = models.CharField(max_length=255) class Song(models.Model): artist = models.ForeignKey(Artist, on_delete=models.CASCADE) name = models.CharField(max_length=255) def print_songs(): for song in Song.objects.all(): print(f"{song.artis...| Johnny Metz
