Overview
Ent was inspired by an internal entity framework at Meta and created in 2019 by engineers on Facebook's Connectivity team; it is now developed and maintained by the Atlas team. You define each entity in a Go schema package with fields, edges (relations), indexes and hooks, then run go generate to produce a typed client, so queries like client.User.Query().Where(user.Name("a8m")).QueryCars().All(ctx) are checked by the compiler.
Edges make it natural to traverse graphs of related data, and the generated code can be customised with Go templates. Privacy policies and hooks let you enforce rules at the data layer.
For migrations Ent can auto-migrate in development, and for production its docs recommend versioned migrations generated with Atlas: atlas migrate diff compares the Ent schema with the migration directory and writes SQL files that Atlas, golang-migrate, Flyway or Liquibase can apply.
The trade-off is the build step: every schema change means running code generation and committing the generated package. In return, Ent's generated client removes whole classes of runtime errors that string-based Go ORMs allow, and its schema package documents the data model in one place.
Pricing and plans
| Plan | Price | What you get |
|---|---|---|
| Ent | $0 | Apache 2.0 licence |
What it does
- Schema as code
- Entities, fields, edges and indexes defined in Go; code generation produces the client.
- Typed query API
- 100% statically typed predicates, ordering and eager loading; no interface{} or string column names.
- Graph traversal
- Follow edges across entities in one fluent query, such as users to groups to admins.
- Atlas migrations
- Generate versioned SQL migration files from schema changes with atlas migrate diff.
- Extendable generation
- Customise or extend the generated code with Go templates.
- Hooks and privacy
- Mutation hooks and privacy rules applied to every query and mutation.
Strengths and limitations
Strengths
- Compile-time safety for queries through generated code
- Handles large, relation-heavy data models well
- Developed and sponsored by the Atlas team
- Solid migration story through Atlas
Limitations
- Code generation step after every schema change, and a large amount of generated code in the repository
- Not yet at v1; the project publishes a roadmap to v1
- Schema must be defined in Ent's Go DSL rather than plain SQL
- Complex SQL (window functions, CTEs) needs modifiers or raw SQL
Who it suits
Good for
- Go backends with many entities and relations
- Graph-shaped data such as social or permission graphs
- Teams that want typed queries without writing SQL
Look elsewhere if
- Teams that prefer writing SQL (sqlc or Bun)
- Small services where code generation is more overhead than it saves
Alternatives to Ent
| Tool | From | Free option | Stages |
|---|---|---|---|
| SQLAlchemy Python SQL toolkit and ORM | — | ||
| jOOQ Type-safe SQL builder for the JVM | €12/mo | Free tier | |
| Eloquent ORM Active Record ORM for Laravel | — | ||
| TypeORM Decorator-based TypeScript ORM | — | ||
| Doctrine ORM Data mapper ORM for PHP | — | ||
| Active Record (Rails) Active Record ORM for Ruby on Rails | — |
Questions
Who maintains Ent?
Ent started at Facebook and is now developed and maintained by the Atlas team.
How does Ent handle migrations?
It can auto-migrate, and its docs recommend versioned migrations generated with Atlas for production.
Ent vs GORM: what is the difference?
Ent generates a statically typed client from Go schema definitions; GORM works at run time with reflection and struct tags.
Sources read for this page