Stop using entgo...please
Tags: go, database, programming, postgres
Published: 2024-01-08 03:24:04

If you found this article, than you are probably similar to how I was a few months ago. I started a project in Go that required a SQL backend and I wanted to use any tool that would help me build this backend quickly. I stumbled upon [entgo](https://entgo.io/) (an ORM for Go) and decided to give it a try.

Initially it was easy to setup and get started. The code generation seemed to work well and in no time I was using the database in my application. Everything was going well, but I ran into a few issues I could not over look:

- Auto Migration Failures
- "Magical" Queries
- Code Bloat

#### Auto Migration Failures
The [auto migration feature](https://entgo.io/docs/migrate/#auto-migration) of module seems to have issues processing fields with `date/time` values. After I spent hours debugging I reached out to their community to see if anyone had this issue. I received no response in their Discord (does not seem very active) and I only received one response on a [Github issue I posted](https://github.com/ent/ent/issues/3790) on the topic (after over a month of the issue being posted).

#### "Magical" Queries
During load testing on my application I began noticing performance issues from the database. When I began using the `Debug()` mode for the entgo client I observed overly complex queries, even for simple cases (i.e. simple `SELECT`s, no `JOIN`s. Some of these issues may be resolved by modifying the [code generation](https://entgo.io/docs/code-gen#code-generation-options) options of the library but that seems like quite a bit of additional effort for an issue that should not exist.

#### Code Bloat
The included `ent` code generation tool could use some optimization, reviewing many of the files reveals many included functions and complex logic that (as I understand it) adds little value unless advanced features of the library are being used (GraphQL integration, Custom Hooks, etc). 

## What to use instead?
I just told you all of the reasons why not to use entgo, but what should you use? Honestly, raw SQL or really a raw SQL schema and raw queries with [sqlc](https://docs.sqlc.dev/en/stable/index.html) for Go code generation. That may sound counter intuitive, but hear me out. `sqlc` is not an ORM, you still write your database schema, perform your migrations, and write your own queries. `sqlc` handles the generation of Go interfaces to perform those queries in a type-safe fashion within your application. This has a few advantages over `entgo` (or any ORM for that matter):
- No "Magic" Queries
- No Auto Migration System Failures
- Minimal Code Generation

#### No "Magic" Queries
You write all of the queries yourself, so you can easily make them as efficient as your SQL knowledge allows

#### No Auto Migration System Failures
You perform the database migrations yourself before `sqlc` is ever called, it cannot cause migration errors if it does not perform migrations.

#### Minimal Code Generation
`sqlc` generates 3 (minimal) files total as part of its tooling, regardless of the database schema or number/complexity of queries.

For all of these reasons above I am officially making the switch from using `entgo` to `sqlc`. If there is interest I can write about that migration in more detail, let me know what you think about that in the comments.

I hope you read this and have considered that an ORM like `entgo` might not actually be the faster/easier approach to adding SQL queries to your application and that sometimes a simpler approach can be just as good, if not better.