Introduction

In Django, a model field default is configured with the field’s default argument. That value is used when a new model instance is created without explicitly setting the field. The important detail is whether the default should be a fixed constant, a callable evaluated each time, or a value that also needs to exist at the database layer.

Set a Simple Fixed Default

For constant values, pass the value directly to default.

1from django.db import models
2
3
4class Task(models.Model):
5    title = models.CharField(max_length=200)
6    status = models.CharField(max_length=20, default="pending")
7    priority = models.IntegerField(default=1)

Now if you create a task without those fields, Django fills them in:

task = Task(title="Write documentation")
print(task.status)   # pending
print(task.priority) # 1

This works well for immutable values such as strings, integers, booleans, and small constants.

Use a Callable for Dynamic Defaults

If the default should be calculated when each object is created, pass a callable instead of calling it immediately.

1from django.db import models
2from django.utils import timezone
3
4
5class Event(models.Model):
6    name = models.CharField(max_length=200)
7    created_at = models.DateTimeField(default=timezone.now)

Notice the difference between timezone.now and timezone.now():

• 'default=timezone.now means Django will call the function for every new row.'
• 'default=timezone.now() runs once when the model is imported and reuses that single timestamp.'

The same pattern applies to generated identifiers:

1import uuid
2
3class ApiKey(models.Model):
4    token = models.UUIDField(default=uuid.uuid4, editable=False)

Callable defaults are the correct choice when the value must be fresh every time.

Avoid Mutable Defaults

One of the most common Django mistakes is using a mutable object such as a list or dictionary directly as the default. That creates one shared object, not a new object per instance.

Bad pattern:

class BadExample(models.Model):
    metadata = models.JSONField(default={})

Correct pattern:

class GoodExample(models.Model):
    metadata = models.JSONField(default=dict)

Using dict or list as the callable ensures a brand-new container for each new model instance. This is especially important for JSONField and other structured fields.

Model Defaults Versus Database Defaults

Django’s default is primarily an ORM-level behavior. If objects are created through Django, the default will be applied automatically. That does not necessarily mean the database enforces the same default for inserts coming from external tools, scripts, or direct SQL.

If every write flows through Django, the model default is often enough. If other systems also insert rows, you may need a matching database-level default or explicit insert logic outside Django.

Changing Defaults on Existing Models

When you add or change a default, create and apply a migration:

python manage.py makemigrations
python manage.py migrate

If you add a non-nullable field to an existing table, Django may ask for a one-off default to backfill old rows. That one-time migration value is not automatically the same thing as a permanent model default for future objects. Be explicit about which behavior you want.

When null and Blank Strings Matter

Defaults interact with field configuration. For example, a CharField often uses an empty string default rather than None. If you really want None, the field usually also needs null=True.

class Profile(models.Model):
    bio = models.TextField(default="", blank=True)

This kind of choice affects validation, query behavior, and how consistently missing values are represented across your application.

Common Pitfalls

One common mistake is writing default=my_function() instead of default=my_function. That evaluates the value too early and often produces stale or repeated data.

Another mistake is using mutable defaults such as [] or {}. That shares the same object across model instances and leads to confusing bugs when edits appear to leak between rows.

Developers also sometimes assume a Django model default automatically becomes a database-enforced default everywhere. It usually does not unless you deliberately set that up at the database level.

Finally, changing a default on an established model without thinking through the migration can create confusion between one-time backfill behavior and future object creation behavior.

Summary

• Set model defaults with the field’s default argument.
• Use direct values for constants and callables for dynamically computed defaults.
• Never use mutable objects directly as defaults; use dict, list, or another callable instead.
• Django model defaults are ORM behavior, not automatically universal database defaults.
• Migrations matter when defaults are added or changed on existing models.