🧩 What Happens When You Use Multiple Preload() Calls in GORM

In GORM, when you use .Preload("Relation"), it automatically runs additional SQL queries to fetch related data and attach it to your main model.

For example:

db.Preload("Roles.Permissions").Find(&users)

generates something like:

1. SELECT * FROM users
2. SELECT * FROM roles WHERE user_id IN (...)
3. SELECT * FROM permissions WHERE role_id IN (...)

Each .Preload() adds at least one extra SQL query, and if you chain multiple nested preloads (Preload("A.B.C")), the number of queries can grow rapidly.

⚠️ The Performance Impact

1. More Queries → Higher Latency

Each preload is equal to one extra round trip to the database. If you have many relationships (or a large dataset), you’re quickly sending dozens of SQL statements per request.

➡️ Example: If fetching 100 users with 3 preloads → GORM might execute 4–6 queries. With nested preloads (e.g. Roles.Permissions.Actions), it could balloon to 10–15 queries.

2. Bigger Memory Footprint

Each preload loads entire related tables into memory and builds the associations in Go. If the dataset is large, this means:

• High memory usage (Go heap)
• Increased GC pressure
• Slower JSON marshaling when returning API responses

3. Complex Joins / Duplicated Data

If you mix .Preload() with .Joins(), you can get large, repetitive result sets — especially if you use Preload("Nested.Relations"). This causes unnecessary data duplication and slower queries due to large joins.

4. Difficult to Control Data Volume

Preload doesn’t support granular filters easily (e.g. “only active roles”). You can pass conditions, but if you do this for multiple associations, the query logic becomes scattered and harder to maintain.

🚀 Optimization Strategies

✅ 1. Load Only What You Need

Avoid preloading all associations by default. Instead, use Preload() conditionally or use lazy loading patterns.

Example:

if includeRoles {
    db = db.Preload("Roles", "roles.status = ?", "active")
}

✅ 2. Use Joins for Simple Relationships

If you only need fields from a related table (not nested data), use .Joins() instead of .Preload().

Example:

db.Joins("LEFT JOIN roles ON users.role_id = roles.id").Select("users.*, roles.name")

This executes a single SQL query, instead of one per relation.

✅ 3. Use Manual Batching

Instead of fetching everything in one go, fetch in batches:

db.Limit(100).Find(&users)

and then separately preload needed associations for just those users.

✅ 4. Cache Expensive Preload Results

If relationships rarely change, you can cache preloaded results (e.g. role-permission mapping) in Redis or memory and avoid repeated SQL lookups.

✅ 5. Profile & Monitor

Use:

db = db.Debug()

to print queries and count how many are executed per request.

Or log slow queries via:

db.Logger = logger.Default.LogMode(logger.Info)

Also, tools like New Relic, Datadog, or Prometheus can help track slow SQL calls.

⚡ Summary

Issue: Too many DB round trips
Description: Each preload runs a new query
Solution: Minimize preloads, use joins

Issue: High memory usage
Description: GORM builds all relations in memory
Solution: Limit dataset, use selective preloads

Issue: Slow serialization
Description: Nested data takes time to encode
Solution: Use lightweight structs for API

Issue: Harder debugging
Description: Multiple hidden queries
Solution: Enable GORM debug logs

🎉 I’m excited to share the link to my book on Design Patterns — a practical and developer-friendly guide that distills complex patterns into real-world examples. Whether you’re just getting started or brushing up on your software design skills, I hope you find it insightful and useful.

📘 Check it out here: [Software Design Patterns for Java Developers] 💬 I’d love to hear your feedback, and feel free to share it with fellow devs who might benefit!

[embed]Software Design Patterns for Java Developers Software Design Patterns for Java Developers' discusses the fundamentals of software design as well as well-established…www.amazon.in