Bun

Bun is a lightweight, SQL-first ORM for Go that embraces raw SQL instead of hiding it behind a heavy abstraction layer. It builds on the standard library’s database/sql package, letting developers compose SELECT, INSERT, UPDATE, DELETE, and CTE queries with a fluent Go API that reads like SQL while remaining fully type-safe at compile time.

Beyond query building, Bun ships struct-tag-driven relationships (has-one, has-many, belongs-to, many-to-many), a versioned migration system with automatic schema diffing, fixtures for test data, soft deletes, and first-class OpenTelemetry instrumentation. Dialect packages abstract the differences between PostgreSQL, MySQL/MariaDB, SQLite, MSSQL, and Oracle, so the same query-building code can target multiple databases through pluggable dialect and driver packages.

What You Get

• A chainable query builder (NewSelect, NewInsert, NewUpdate, NewDelete, NewMerge) that composes readable SQL including CTEs, window functions, and bulk operations
• Struct-tag-based model mapping with support for has-one, has-many, belongs-to, and many-to-many relationships loaded via .Relation()
• Flexible result scanning into structs, maps, scalars, or individual variables from the same query builder
• A schema migration toolkit (migrate package) with versioned Go migrations and automatic schema diffing between model definitions and the live database
• Pluggable dialects and pure-Go drivers (pgdriver, sqliteshim) for PostgreSQL, MySQL/MariaDB, SQLite, MSSQL, and Oracle without requiring cgo for the common cases
• Built-in observability hooks including query debug logging (bundebug) and OpenTelemetry tracing (bunotel)

Common Use Cases

• Building backend services that need type-safe SQL access without the code-generation step required by some Go ORMs
• Applications targeting multiple SQL databases (e.g. SQLite in development, PostgreSQL in production) through the same model and query code
• Projects that need versioned schema migrations alongside application code, driven by Go functions rather than raw SQL files
• Services instrumented with OpenTelemetry that want database query spans and metrics out of the box
• Teams migrating away from raw database/sql boilerplate who still want full control over the generated SQL

Under The Hood

Architecture Bun is layered around a central DB type (db.go) that wraps a *sql.DB and a schema.Dialect implementation, dispatching to per-operation query builders (query_select.go, query_insert.go, query_update.go, query_delete.go, query_merge.go, query_table_create.go, and others) that all build on a shared baseQuery (query_base.go). Struct-to-table mapping lives in the schema package (schema/table.go, schema/field.go, schema/relation.go), which uses reflection and bun:"..." struct tags to derive columns, primary keys, and relationships, then feeds that metadata back into the query builders via model_table_*.go files. A Dialect interface (schema/dialect.go) abstracts SQL generation differences per database, implemented separately under dialect/pgdialect, dialect/mysqldialect, dialect/sqlitedialect, dialect/mssqldialect, and dialect/oracledialect, while dialect/feature flags let query builders adapt behavior (e.g. RETURNING support, CTE materialization) per dialect at runtime. A hook system (hook.go) lets user code register Before/After callbacks around each query type, and the separate migrate package layers versioned migrations and schema diffing on top of the same DB and schema abstractions, keeping the migration engine decoupled from query building.

Tech Stack Bun is a pure Go module (go.mod) targeting recent Go toolchains, built directly on the standard library’s database/sql rather than a custom connection layer. Direct dependencies are deliberately minimal: github.com/jinzhu/inflection for pluralization in default table/column naming, github.com/puzpuzpuz/xsync/v3 for concurrent maps used in the schema cache, github.com/rs/zerolog for structured logging in extras, github.com/vmihailenco/msgpack/v5 for binary encoding support, and github.com/tmthrgd/go-hex for fast hex encoding; stretchr/testify covers assertions in tests. Database-specific connectivity is split into separate driver/pgdriver (a pure-Go PostgreSQL wire-protocol driver avoiding cgo and lib/pq) and driver/sqliteshim packages, while MySQL, MSSQL, and Oracle connectivity rely on standard third-party database/sql drivers referenced from the dialect packages. Optional extra/ submodules add OpenTelemetry (bunotel), New Relic (bunrelic), zerolog/slog logging adapters, and JSON/bignum helpers as separate Go modules so consumers only pull in what they use.

Code Quality The project has an extensive test suite spanning unit tests colocated with source files (e.g. query_select_clone_test.go, schema/table_test.go, schema/appendjson_test.go) and an integration suite under internal/dbtest that spins up real PostgreSQL, MySQL, MariaDB, and MSSQL instances via Docker Compose to exercise the ORM against live databases. CI (.github/workflows/build.yml) runs this matrix across multiple Go versions with real database services rather than mocks, plus a dedicated golangci-lint.yml workflow and commit-message linting. Error handling favors explicit returned errors over panics in the query-execution path, exported types and functions carry doc comments (visible throughout bun.go and db.go), and regression tests reference specific historical issue numbers (e.g. the Clone-state test tied to issue #1388), indicating an active bug-fix-with-regression-test discipline.

API Design The public API leans into method chaining that mirrors SQL vocabulary directly (NewSelect().Model().Where().Relation().Scan()), which keeps the learning curve low for developers already comfortable with SQL while still returning compile-time-checked Go values. Getting started requires only go get plus a dialect import and a driver, and the README-documented quick-start runs in a handful of lines against an in-memory SQLite database. Twenty-four runnable examples under example/ cover relationships, migrations, fixtures, multi-tenancy, and OpenTelemetry, and canonical documentation lives on a dedicated docs site (bun.uptrace.dev) maintained in a separate bun-docs repository, supplementing the in-repo README and package-level doc comments.