Gorm Basics Go

Beginner·3 min read

Fast recall

Quick revision

Core answer

GORM is Go's ORM: structs map to tables (gorm.Model + field tags), AutoMigrate creates tables, and CRUD is method calls (db.First, db.Create, db.Where). It replaces raw SQL with struct operations — at the cost of generated queries and abstraction.

Interview Answer3 min

The model + operations:

type User struct {
    gorm.Model              // ID, CreatedAt, UpdatedAt, DeletedAt — built-in
    Name  string
    Email string `gorm:"uniqueIndex"`
}

// Setup
db, _ := gorm.Open(sqlite.Open("app.db"), &gorm.Config{})
db.AutoMigrate(&User{})   // CREATE TABLE — from the struct

// Create — INSERT
db.Create(&User{Name: "Al", Email: "al@x.com"})

// Read — SELECT
db.First(&user, "name = ?", "Al")          // SELECT * WHERE name = 'Al' LIMIT 1
db.Where("age > ?", 18).Find(&users)       // SELECT * WHERE age > 18

// Update
db.Model(&user).Update("name", "Alice")     // UPDATE users SET name = 'Alice'

// Delete (soft — sets DeletedAt)
db.Delete(&user)                          // UPDATE deleted_at — not actually gone

What GORM adds over database/sql:

1
Models — the struct IS the schema (no SQL column mapping in Scan)
2
AutoMigrate — the table appears from the struct (dev convenience; production migrations use a tool)
3
Associations — db.Preload("Orders") handles the JOIN, the related structs populated
4
Hooks — BeforeCreate, AfterUpdate — lifecycle callbacks on the model
5
Soft deletes — the DeletedAt field = 'deleted' rows filtered automatically

The honest costs:

The generated SQL isn't always what you'd write (N+1 without Preload; surprising WHERE clauses)
The abstraction leaks — you still need to know what SQL it's producing
Performance-sensitive paths drop to raw (db.Raw(...), db.Exec) — which GORM supports

Interview-ready guide

Interview answer

The model + operations:

type User struct {
    gorm.Model              // ID, CreatedAt, UpdatedAt, DeletedAt — built-in
    Name  string
    Email string `gorm:"uniqueIndex"`
}

// Setup
db, _ := gorm.Open(sqlite.Open("app.db"), &gorm.Config{})
db.AutoMigrate(&User{})   // CREATE TABLE — from the struct

// Create — INSERT
db.Create(&User{Name: "Al", Email: "al@x.com"})

// Read — SELECT
db.First(&user, "name = ?", "Al")          // SELECT * WHERE name = 'Al' LIMIT 1
db.Where("age > ?", 18).Find(&users)       // SELECT * WHERE age > 18

// Update
db.Model(&user).Update("name", "Alice")     // UPDATE users SET name = 'Alice'

// Delete (soft — sets DeletedAt)
db.Delete(&user)                          // UPDATE deleted_at — not actually gone

What GORM adds over database/sql:

1
Models — the struct IS the schema (no SQL column mapping in Scan)
2
AutoMigrate — the table appears from the struct (dev convenience; production migrations use a tool)
3
Associations — db.Preload("Orders") handles the JOIN, the related structs populated
4
Hooks — BeforeCreate, AfterUpdate — lifecycle callbacks on the model
5
Soft deletes — the DeletedAt field = 'deleted' rows filtered automatically

The honest costs:

The generated SQL isn't always what you'd write (N+1 without Preload; surprising WHERE clauses)
The abstraction leaks — you still need to know what SQL it's producing
Performance-sensitive paths drop to raw (db.Raw(...), db.Exec) — which GORM supports

03 · Deep dive

Gorm Basics Go

About 2 min with examples

Direct Answer

Deep Dive & Architecture

The N+1 problem, which is GORM's most infamous trap: looping over users and calling user.Orders loads each user's orders with a separate query — 100 users = 101 queries. Preload fixes it (one IN query — db.Preload("Orders").Find(&users)), but only if you know it. The equivalent raw-SQL mistake is fewer levels removed — which is the abstraction trade: GORM makes the wrong path easy.

The GORM vs database/sql decision, which is the interview's real question: database/sql + explicit SQL for query-critical services (full control, no surprise queries, no GORM dependency); GORM for CRUD-heavy internal services (speed of development, the struct-schema binding). The middle path many teams use: GORM for the CRUD scaffolding, raw SQL through GORM's db.Raw for the hot/complex queries.

The migration story: AutoMigrate adds columns but doesn't remove or rename — it's a dev convenience, not a migration tool. Production uses versioned migrations (goose, atlas, golang-migrate) — the discipline GORM doesn't replace.

Common Mistakes & Pitfalls

Giving a definition without explaining a practical trade-off.

Check your understanding

Answer these without looking back at the article.

When would you use Gorm Basics Go in a real project?
How would you compare Gorm Basics Go with an alternative?
What is a common mistake when using Gorm Basics Go?

debug a problem involving Transactions Go Basics

Continue · Next question · Q 22/30

When would you use Gorm Basics Go in a real project

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories

Previous Next

Gorm Basics Go

Beginner·3 min read

Fast recall

Quick revision

Core answer

Interview Answer3 min

The model + operations:

type User struct {
    gorm.Model              // ID, CreatedAt, UpdatedAt, DeletedAt — built-in
    Name  string
    Email string `gorm:"uniqueIndex"`
}

// Setup
db, _ := gorm.Open(sqlite.Open("app.db"), &gorm.Config{})
db.AutoMigrate(&User{})   // CREATE TABLE — from the struct

// Create — INSERT
db.Create(&User{Name: "Al", Email: "al@x.com"})

// Read — SELECT
db.First(&user, "name = ?", "Al")          // SELECT * WHERE name = 'Al' LIMIT 1
db.Where("age > ?", 18).Find(&users)       // SELECT * WHERE age > 18

// Update
db.Model(&user).Update("name", "Alice")     // UPDATE users SET name = 'Alice'

// Delete (soft — sets DeletedAt)
db.Delete(&user)                          // UPDATE deleted_at — not actually gone

What GORM adds over database/sql:

1
Models — the struct IS the schema (no SQL column mapping in Scan)
2
AutoMigrate — the table appears from the struct (dev convenience; production migrations use a tool)
3
Associations — db.Preload("Orders") handles the JOIN, the related structs populated
4
Hooks — BeforeCreate, AfterUpdate — lifecycle callbacks on the model
5
Soft deletes — the DeletedAt field = 'deleted' rows filtered automatically

The honest costs:

The generated SQL isn't always what you'd write (N+1 without Preload; surprising WHERE clauses)
The abstraction leaks — you still need to know what SQL it's producing
Performance-sensitive paths drop to raw (db.Raw(...), db.Exec) — which GORM supports

Interview-ready guide

Interview answer

The model + operations:

type User struct {
    gorm.Model              // ID, CreatedAt, UpdatedAt, DeletedAt — built-in
    Name  string
    Email string `gorm:"uniqueIndex"`
}

// Setup
db, _ := gorm.Open(sqlite.Open("app.db"), &gorm.Config{})
db.AutoMigrate(&User{})   // CREATE TABLE — from the struct

// Create — INSERT
db.Create(&User{Name: "Al", Email: "al@x.com"})

// Read — SELECT
db.First(&user, "name = ?", "Al")          // SELECT * WHERE name = 'Al' LIMIT 1
db.Where("age > ?", 18).Find(&users)       // SELECT * WHERE age > 18

// Update
db.Model(&user).Update("name", "Alice")     // UPDATE users SET name = 'Alice'

// Delete (soft — sets DeletedAt)
db.Delete(&user)                          // UPDATE deleted_at — not actually gone

What GORM adds over database/sql:

1
Models — the struct IS the schema (no SQL column mapping in Scan)
2
AutoMigrate — the table appears from the struct (dev convenience; production migrations use a tool)
3
Associations — db.Preload("Orders") handles the JOIN, the related structs populated
4
Hooks — BeforeCreate, AfterUpdate — lifecycle callbacks on the model
5
Soft deletes — the DeletedAt field = 'deleted' rows filtered automatically

The honest costs:

The generated SQL isn't always what you'd write (N+1 without Preload; surprising WHERE clauses)
The abstraction leaks — you still need to know what SQL it's producing
Performance-sensitive paths drop to raw (db.Raw(...), db.Exec) — which GORM supports

03 · Deep dive

Gorm Basics Go

About 2 min with examples

Direct Answer

Deep Dive & Architecture

Common Mistakes & Pitfalls

Giving a definition without explaining a practical trade-off.

Check your understanding

Answer these without looking back at the article.

When would you use Gorm Basics Go in a real project?
How would you compare Gorm Basics Go with an alternative?
What is a common mistake when using Gorm Basics Go?

debug a problem involving Transactions Go Basics

Continue · Next question · Q 22/30

When would you use Gorm Basics Go in a real project

Full prep

Looking for a structured roadmap?

Every module on this page is also part of the full Java backend interview track.

Open the full roadmap Browse all prep categories