ent/ent: A Schema-as-Code Entity Framework for Go

What problem ent solves, and who it is aimed at

Most Go database layers force a choice: write SQL by hand and lose type safety, or use a runtime ORM that resolves columns through reflection and string tags. ent takes a third route. You describe your schema as Go objects, and a code generator emits a typed client for that schema. Queries are then ordinary Go method chains that the compiler checks.

The README frames the target directly: "Simple, yet powerful entity framework for Go, that makes it easy to build and maintain applications with large data-models." The emphasis on large data models is the honest part. If your application has three tables and a handful of queries, the generation step is overhead you will not earn back. If you have dozens of entities with edges between them, hand-maintained scanning code becomes the thing that breaks silently when a column is renamed.

The project was inspired by an entity framework used internally at Meta, and is now developed and maintained by the Atlas team. That lineage explains the design: schema as code, explicit API, and a generator that is itself extensible through Go templates.

How the code generation pipeline works

The mechanism is a two-part split. The entc generator reads schema definitions from your project and writes Go packages. The runtime library, imported as entgo.io/ent, is what your application calls at request time. The repository layout reflects this: entc/ holds the generator, dialect/ holds the per-database implementations, schema/ holds schema helpers, and privacy/ holds the policy layer used by the privacy examples.

Because the generated client is plain Go, there is no reflection on the query path and no runtime parsing of struct tags. The trade-off is that the generated code is part of your repository. Renaming a field means regenerating, and a stale generated tree is a compile error rather than a runtime surprise, which is the intended behaviour but also means your build must run the generator.

The README lists the storage drivers: MySQL, MariaDB, TiDB, PostgreSQL, CockroachDB, SQLite and Gremlin. That is a broad spread, including graph traversal via Gremlin alongside the relational dialects. The go.mod pins ariga.io/atlas, which is the schema migration engine from the same team, and the examples directory includes a migration example, so schema versioning is handled through Atlas rather than through a bespoke migration format.

Installing ent and generating a first client

The README gives a quick installation command. It installs the ent command line tool, which is what you use to scaffold and regenerate code.

go install entgo.io/ent/cmd/ent@latest

The README notes that for proper installation using Go modules you should visit the installation page at entgo.io, and it links a version compatibility page between entc and the ent runtime. That link is worth opening before you pin versions, because the generator and the runtime are separate modules and the compatibility page exists precisely because mismatches happen.

Once the binary is on your PATH, you create an entity. The README does not spell out the exact scaffold invocation, so check the code generation documentation at entgo.io for the current form rather than guessing at flags. What the repository does show is the shape of the result: a schema package containing Go files that declare fields and edges, and a generated package your code imports.

After scaffolding, generating the client is the step that produces the typed API. The generated package is what you import in your service, and the schema package is what the generator reads on each run. Keep both under version control so a reviewer can see what a schema change actually altered in the generated output.

Where ent is the wrong tool

The honest limitation is the generator itself. Any change to your schema requires a regeneration pass, and the generated code must be committed or produced in CI. Teams that treat their repository as source-only and their build as hermetic will need to decide where generation runs. If your CI cannot execute the ent binary with the same module versions as your local environment, you will get diffs that do not reproduce.

The second constraint is language. ent is a Go framework. If your service is in another language, nothing here applies, and the multi-driver support does not help you.

The third is the migration story. ent delegates schema changes to Atlas, a separate project with its own documentation and its own release cadence. The README does not document rollback behaviour, so if reversible migrations matter to you, that is a question for the Atlas documentation, not for ent's README.

Finally, the API is explicit by design. That means more code for simple reads than a query builder would need. A single-table lookup with no edges is not where ent pays off.

How ent differs from sqlc and GORM

The closest comparison is sqlc, which takes the opposite direction: you write SQL, and it generates typed Go functions from your queries. ent generates from a schema model, so the query is expressed as Go method chains rather than SQL text. With sqlc you keep full control of the SQL and review it directly; with ent you review the schema and trust the generator to emit the SQL. Neither is strictly better, but the review surface is different, and if your team's SQL expertise is the thing you want to preserve, sqlc keeps it in the loop.

GORM sits at the other end. It is a runtime ORM driven by struct tags and reflection, with no generation step. That means no generated files to commit and no build-time dependency on a code generator, at the cost of type errors that surface at runtime instead of compile time. ent's README makes the trade explicit with its "Statically Typed And Explicit API" line: the type safety is bought with code generation.

A smaller difference worth noting is extensibility. ent's generator is customizable through Go templates, and the examples directory includes an extensions example. That is a real advantage if you need custom generated helpers, and irrelevant if you do not.

Maintenance, licensing and what to check before adopting

The repository is not archived, and the last push was on 2026-09-04, which is recent relative to today. Release cadence is uneven: v0.14.6 landed on 2026-03-23, v0.14.0 on 2024-07-29, and v0.12.5 on 2023-11-13. There is no v1 yet; the README points to an issue describing the roadmap for a v1 release. If your organisation requires a stable major version before adoption, that is a policy question you should settle first, because the project is still on 0.x.

Licensing is Apache-2.0, per the LICENSE file and the README's license section. Apache-2.0 includes an explicit patent grant and permits commercial use and modification. This is a factual description of the licence text, not legal advice; if your legal team has specific obligations around attribution or notice files, they should read the LICENSE file directly.

The upgrade cost concentrates in two places: the generated code and the Atlas dependency. Because ariga.io/atlas is pinned in go.mod, a schema migration engine upgrade and an ent upgrade can arrive together. Read the entc and ent compatibility page before bumping either.

Editorial conclusion

Adopt ent if your Go service has a data model large enough that hand-written SQL and reflection-based scanning have become a maintenance problem, and your team accepts running code generation as part of the build. Do not adopt it if you want a runtime ORM with no generated files, or if your project is not written in Go. Before committing, verify the version compatibility page for entc and the ent runtime, confirm your database dialect is in the supported list, and check that the generated code can be regenerated in CI without network access to the module proxy.

Frequently asked questions

Official sources

1. ent/ent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases