Overview
GORM was created by Jinzhu in 2013 and remains the default ORM for many Go projects. You declare structs with tags, open a connection with a driver (MySQL, PostgreSQL through pgx, SQLite, SQL Server, TiDB, Oracle or GaussDB) and query with chainable methods such as db.Where(...).Preload("Orders").Find(&users). It supports has-one, has-many, belongs-to, many-to-many, polymorphic associations and single-table inheritance, plus hooks, nested transactions and save points.
AutoMigrate creates tables, missing columns, indexes and constraints and can widen column types, but its docs say it will not delete unused columns. That makes it convenient in development; for reviewed, versioned migrations teams usually pair GORM with a tool such as Atlas, goose or golang-migrate. GORM Gen, a companion project with its own guide, adds code generation on top.
Because queries are built from strings and interface{} values, many mistakes show up at run time rather than compile time, which is the usual reason Go developers choose sqlc or Ent instead.
Pricing and plans
| Plan | Price | What you get |
|---|---|---|
| GORM | $0 | MIT licence |
What it does
- Associations
- Has one, has many, belongs to, many to many, polymorphism and single-table inheritance.
- Preload and Joins
- Eager-load associations with Preload or Joins to avoid N+1 queries.
- Hooks and transactions
- Before/after create, save, update, delete and find hooks; nested transactions and save points.
- AutoMigrate and Migrator
- Create and alter tables from structs, plus a database-independent Migrator interface.
- Plugins
- DB Resolver for multiple databases and read/write splitting, Prometheus metrics and more.
- GORM Gen
- Optional companion code generator documented alongside GORM.
Strengths and limitations
Strengths
- Large community and many examples for Go
- Covers most ORM needs out of the box, including associations and hooks
- Official drivers for Oracle, SQL Server and TiDB as well as open-source databases
- Quick to start with AutoMigrate
Limitations
- Most query mistakes surface at run time, not compile time
- AutoMigrate never drops unused columns and is not a versioned migration system
- Reflection-heavy design adds overhead compared with database/sql or sqlc
- Development is concentrated around its original author
Who it suits
Good for
- Go CRUD APIs and admin backends
- Teams coming from ORMs in other languages
- Prototypes that benefit from AutoMigrate
Look elsewhere if
- Teams that want compile-time checked SQL (sqlc) or a generated typed API (Ent)
- Performance-critical hot paths where reflection overhead matters
Alternatives to GORM
| Tool | From | Free option | Stages |
|---|---|---|---|
| Eloquent ORM Active Record ORM for Laravel | — | ||
| SQLAlchemy Python SQL toolkit and ORM | — | ||
| Drizzle ORM SQL-like TypeScript ORM | — | ||
| Entity Framework Core .NET ORM | — | ||
| Ecto Elixir data mapping and query toolkit | — | ||
| Bun (Go ORM) SQL-first Go ORM | — |
Questions
Does GORM support migrations?
It has AutoMigrate and a Migrator interface, but AutoMigrate does not drop columns or keep versioned files; use Atlas, goose or golang-migrate for that.
Which databases does GORM support?
MySQL, PostgreSQL, SQLite, SQL Server, TiDB, Oracle Database and GaussDB are officially supported.
GORM vs sqlc: which should I use?
GORM is a runtime ORM with associations and hooks; sqlc generates type-safe Go from SQL you write, catching errors at build time.
Sources read for this page