SQLBoiler: a database-first Go ORM generated from your schema

The problem SQLBoiler solves for teams with an existing schema

Most Go ORMs are code-first. You describe your tables as Go structs, and the library derives the SQL. SQLBoiler inverts that. The README states it is a "database-first" ORM as opposed to "code-first" (like gorm/gorp), and that you must first create your database schema, using something like sql-migrate or another migration tool for that part of the database's life-cycle.

The intended audience is a team that already has a database and does not want the ORM to own its definition. The README describes the origin directly: while attempting to migrate a legacy Rails database, the authors found the Go database/sql package repetitive and long-winded after ActiveRecord, and found that most available packages were code-first, reflect-based, and had a weak story around relationships between models.

So the generated code is not a runtime reflection layer. It is Go source produced from your tables, with structs that match your column types and functions for the queries. If your schema is the source of truth and your migrations run outside Go, this is the shape you want. If you expect the ORM to create tables for you, it is the wrong tool by design.

How generation works: schema in, typed models out

The repository layout makes the pipeline visible. main.go and boil/ hold the command, boilingcore/ contains the generation core, drivers/ holds the per-database implementations, templates/ holds the text templates that are rendered into Go files, and queries/ holds the SQL used to read schema metadata. The generated output lands in a models package, and the README notes that the generated models package is type safe, so there is no chance of random panics from passing the wrong type and no need for interface{}.

Generation is driven by a configuration file and a driver. The README lists supported databases through topics and drivers for postgres, mysql, mssql and sqlite3, and go.mod requires the matching client libraries: github.com/lib/pq, github.com/go-sql-driver/mysql, github.com/microsoft/go-mssqldb and modernc.org/sqlite. The generated code talks to your database through boil.Executor, described in the README as a simple interface compatible with sql.DB and sqlx.DB.

The trade-off here is real. Because the models are generated from the live schema, the schema must be reachable at generation time, and the generated code must be regenerated whenever the schema changes. The README frames this as an easy workflow, with models that can always be regenerated. That is true, but it also means generation is a build step you own, not something the library does at runtime.

Installing SQLBoiler and generating your first models

The README's getting started section covers download, configuration and initial generation. The README's download section is where the install path is described; the repository is a Go module, so the tool is fetched with the Go toolchain. The README does not print an install command in the excerpt available here, so check the Download section for the exact form before you run anything.

What the README does make clear is that SQLBoiler itself does not know how to read a Postgres catalog; the driver does. The supported database list means you install the driver that matches your database, for example the psql driver for Postgres. If you skip this, generation has no way to inspect the schema.

Configuration lives in sqlboiler.toml. The README documents configuration as a step before initial generation. The excerpt available here does not show the keys, so consult the Configuration section for the exact names rather than guessing them.

Generation is then invoked with the driver name as its argument, for example sqlboiler psql. The argument must match the driver you installed and the section you configured. What you should see is a models directory containing Go files: structs for your tables, constants for column names, and query functions. From that point on, the README's regeneration guidance applies: rerun the same command after a schema change, and the models are rewritten.

Where SQLBoiler stops: maintenance mode and missing features

The README opens with a Maintenance Mode section, and it is blunt. The package generally does not accept new features. It does accept bug fixes and version compatibility changes provided by the community. Maintainers usually do not resolve reported issues, and community members are encouraged to help each other with reported issues.

That is the single most important constraint for an adoption decision. A bug you hit in generated query code may sit unresolved, and a feature you need will not be added upstream. The README also states that v1, v2 and v3 are no longer maintained, that v3 is the last GOPATH-compatible version, and that v4 is the only maintained version and does not work with GOPATH projects.

There is also a functional boundary the README names outright: a Missing Features list exists in the table of contents, which tells you the project deliberately does not cover everything a full ORM might. The README does not document rollback behavior for generation in the excerpt available, so if you configure generation to wipe the output directory, understand that it removes existing files before writing, and keep the models package in version control so a bad regeneration is recoverable.

The last push to the repository was on 2026-07-12, and the most recent release listed is v4.19.5 from 2025-06-27. Bug fixes and compatibility changes are still landing, but the maintenance-mode text governs what you should expect.

SQLBoiler compared with sqlc and with Bob

The README names two alternatives itself, and the difference in approach matters more than any feature table.

sqlc is described in the README as a command line tool that generates type-safe code from SQL, and explicitly as not an ORM, though for many use cases it can be a good alternative. The distinction is where the source of truth sits. SQLBoiler reads your schema and generates a model layer with relationships, hooks, and query builders. sqlc reads the SQL statements you write and generates Go functions for those statements. If you want to hand-write the queries and get typed wrappers, sqlc matches that. If you want generated model structs and relationship loading without writing each query, SQLBoiler matches that.

Bob is described in the README as very similar to SQLBoiler, directly inspired by it, and created by a maintainer of SQLBoiler, with a comparison page at bob.stephenafamo.com/vs/sqlboiler/. The README recommends Bob for anyone looking for an actively maintained alternative. That is the maintainers' own recommendation, and it is the clearest signal in the document about where new work is going.

A third comparison worth naming is the code-first camp the README calls out by example, gorm. There the schema is derived from Go structs. With SQLBoiler you migrate first and generate second. Teams that dislike maintaining a separate migration tool will feel that cost immediately.

Licence and the cost of staying on v4

The repository's LICENSE file is BSD, and the README carries a BSD badge that links to it. The repository metadata reports the licence as NOASSERTION, which means an automated classifier could not match the file to a known SPDX identifier. Read the LICENSE file itself before you rely on it; this is a description of what the repository contains, not legal advice.

Upgrade cost is the practical concern. v4 has no real breaking changes from v3 other than Go modules, according to the README, and v4 is the only maintained version. So the version decision is settled: v4 or nothing. Within v4, the release history shows patch releases such as v4.19.3, v4.19.4 and v4.19.5 clustered in June 2025, which is consistent with the maintenance-mode description of compatibility fixes rather than feature work.

The recurring cost is regeneration. Every schema change means rerunning the generator with your driver name, reviewing the diff in the generated models package, and fixing any code that depended on a changed column. Because generation reads the live schema, your build pipeline needs database access or a schema snapshot to produce models reproducibly. The README does not document an offline schema dump workflow in the excerpt available, so plan for connectivity at generation time.

Editorial conclusion

Adopt SQLBoiler when you already own the schema and want typed Go models generated from it, and when you can live with a project that is in maintenance mode and generally does not accept new features. Do not adopt it for a greenfield schema you intend to define in Go, or if you need a maintainer to resolve your reported issues. Before committing, verify the driver entry for your database in sqlboiler.toml, confirm the generated models compile against your Go version, and check whether the missing feature you need is listed under Missing Features in the README.

Frequently asked questions

Official sources

1. aarondl/sqlboiler on GitHub
2. Issues
3. README
4. Releases