Custom user model with AbstractUser in Django - Performance & Optimization

Performance: Custom user model with AbstractUser

MEDIUM IMPACT

This affects the initial page load speed and authentication-related interactions by changing how user data is loaded and managed.

Extending user data with a custom user model

Django

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    extra_field = models.CharField(max_length=100)

# Set AUTH_USER_MODEL = 'app.CustomUser' in settings.py

Extending AbstractUser keeps all user data in one table, reducing joins and speeding up queries.

📈 Performance GainSingle database query per user load, reducing authentication latency by up to 50ms

Extending user data with a custom user model

Django

from django.contrib.auth.models import User
from django.db import models

# Adding profile info via separate model with OneToOneField
class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    extra_field = models.CharField(max_length=100)

This pattern causes extra database joins on every user query, increasing query time and slowing authentication-related views.

📉 Performance CostTriggers multiple database queries per user load, increasing response time by 50-100ms depending on DB size

Performance Comparison

Pattern	Database Queries	Joins	Query Latency	Verdict
Separate Profile Model	2+ queries per user	1 join per user	Higher latency due to joins	[X] Bad
CustomUser extends AbstractUser	1 query per user	No joins needed	Lower latency, faster auth	[OK] Good

Rendering Pipeline

Custom user models affect server-side data fetching and authentication logic, which impacts how fast user data is ready for rendering.

→Data Fetching

→Server Response

→Client Rendering

⚠️ BottleneckDatabase query time during authentication and user data retrieval

Core Web Vital Affected

INP

This affects the initial page load speed and authentication-related interactions by changing how user data is loaded and managed.

Optimization Tips

1Use AbstractUser to keep user data in one table and avoid joins.

2Add database indexes on custom user fields to speed queries.

3Avoid separate profile models that cause extra database joins during authentication.

Performance Quiz - 3 Questions

Why is extending AbstractUser better for performance than using a separate profile model?

A It automatically caches user data in the browser.

B It reduces the number of database queries by storing all user data in one table.

C It eliminates the need for authentication.

D It uses less memory on the client side.

DevTools: Network

How to check: Open DevTools, go to Network tab, filter for authentication API calls, and inspect timing details for user data requests.

What to look for: Look for multiple sequential requests or long response times indicating extra queries or joins slowing down user data loading.

Practice

1. What is the main reason to create a custom user model by extending AbstractUser in Django?

easy

A. To add extra fields or change user behavior while keeping Django's default features

B. To remove all default user features and start from scratch

C. To automatically create admin users without configuration

D. To avoid using migrations in the project

Solution

1. Step 1: Understand AbstractUser purpose

   AbstractUser provides Django's default user fields and behavior as a base class.

2. Step 2: Reason for extending AbstractUser

   Extending it allows adding custom fields or changing behavior without losing built-in features.

3. Final Answer:

   To add extra fields or change user behavior while keeping Django's default features -> Option A

4. Quick Check:

   Custom user model = Extend AbstractUser for extra fields [OK]

Hint: AbstractUser keeps defaults; extend it to add fields [OK]

Common Mistakes:

• Thinking AbstractUser removes default features
• Believing custom user models skip migrations
• Assuming admin users are auto-created

2. Which of the following is the correct way to declare a custom user model by extending AbstractUser in Django?

easy

A. class CustomUser(AbstractBaseUser):\n pass

B. class CustomUser(User):\n pass

C. class CustomUser(models.Model):\n pass

D. class CustomUser(AbstractUser):\n pass

Solution

1. Step 1: Identify correct base class

   The question asks for extending AbstractUser, so the class must inherit from it.

2. Step 2: Check syntax correctness

   class CustomUser(AbstractUser):\n pass correctly defines class CustomUser(AbstractUser): pass which is valid syntax.

3. Final Answer:

   class CustomUser(AbstractUser):\n pass -> Option D

4. Quick Check:

   Extend AbstractUser with class CustomUser(AbstractUser) [OK]

Hint: Use AbstractUser as base class for custom user model [OK]

Common Mistakes:

• Using User instead of AbstractUser as base
• Inheriting directly from models.Model without user features
• Confusing AbstractBaseUser with AbstractUser

3. Given this custom user model:

from django.contrib.auth.models import AbstractUser
from django.db import models

class CustomUser(AbstractUser):
    age = models.PositiveIntegerField(null=True, blank=True)

# settings.py
AUTH_USER_MODEL = 'myapp.CustomUser'

What will happen if you try to create a user without specifying age?

medium

A. User creation fails due to missing age field

B. User is created successfully with age set to None

C. User is created but age defaults to 0

D. Error because age is required

Solution

1. Step 1: Analyze age field definition

   Age is defined as PositiveIntegerField with null=True and blank=True, so it is optional.

2. Step 2: Understand user creation behavior

   Since age is optional, creating a user without it sets age to None (null in database).

3. Final Answer:

   User is created successfully with age set to None -> Option B

4. Quick Check:

   Optional field with null=True allows missing value [OK]

Hint: null=True means field can be empty on creation [OK]

Common Mistakes:

• Assuming blank=True means field is required
• Thinking missing fields default to 0 automatically
• Confusing null=True with default values

4. You created a custom user model extending AbstractUser and set AUTH_USER_MODEL in settings. After running migrations, you get an error about conflicting user models. What is the most likely cause?

medium

A. You set AUTH_USER_MODEL after initial migrations were created

B. You forgot to import AbstractUser in your model

C. You did not define a primary key in your custom user model

D. You used AbstractBaseUser instead of AbstractUser

Solution

1. Step 1: Understand migration timing

   If AUTH_USER_MODEL is set after initial migrations, Django creates default user tables causing conflicts.

2. Step 2: Identify cause of conflict error

   The conflict arises because two user models exist: default and custom, due to late setting of AUTH_USER_MODEL.

3. Final Answer:

   You set AUTH_USER_MODEL after initial migrations were created -> Option A

4. Quick Check:

   Set AUTH_USER_MODEL before first migration [OK]

Hint: Set AUTH_USER_MODEL before first migration to avoid conflicts [OK]

Common Mistakes:

• Ignoring migration order importance
• Assuming import errors cause this conflict
• Confusing AbstractUser with AbstractBaseUser issues

5. You want to add a bio text field to your custom user model extending AbstractUser. You also want to display this bio in Django admin user list view. Which steps should you follow?

hard

A. Add bio field to model, override save() to print bio

B. Add bio field to model, no admin changes needed

C. Add bio field to model, register custom user admin with list_display including 'bio'

D. Add bio field to model, create a new admin site

Solution

1. Step 1: Add bio field to custom user model

   Define bio = models.TextField(blank=True, null=True) in your model to store user bios.

2. Step 2: Customize admin to show bio

   Register your custom user model admin and set list_display = ('username', 'email', 'bio') to show bio in list view.

3. Final Answer:

   Add bio field to model, register custom user admin with list_display including 'bio' -> Option C

4. Quick Check:

   Model field + admin list_display shows field [OK]

Hint: Add field + update admin list_display to show it [OK]

Common Mistakes:

• Forgetting to update admin list_display
• Overriding save() unnecessarily
• Creating new admin site instead of customizing existing