CLI Reference

add db

Add a named database connection to a module, with its own pool and connector.
go tool gpsystem add db <module> <name> [--connector pgx|bun]

Every module already has one default connection (cfg.DB / pool), chosen for the whole project at new project --db. add db adds another, independent one to a single module: its own DB_<NAME>_* config, its own pgx pool (optionally wrapped with dbx/bunx), its own closer, and <Name>DB / <Name>Transactor fields on the module's Dependencies.

go tool gpsystem add db news analytics --connector bun
FlagMeaning
--connectorpgx or bun for this connection (default: the project's own --db choice)

The connector is a property of the connection, not the project: a module can have a pgx-native default connection and a bun-backed analytics connection side by side, or vice versa. This is a hard boundary, not a style choice; see Transactions: a pgx-native dbx/pg executor and a dbx/bunx one cannot share a single transaction, so a connection's connector cannot change per call.

What it generates

internal/platform/config/config.go
DBAnalytics dbx.Config `envPrefix:"DB_ANALYTICS_"`
cmd/news/main.go
analyticsPool := pg.MustNewPool(ctx, cfg.DBAnalytics)
analyticsBun := bunx.Open(analyticsPool)   // only for --connector bun
internal/modules/news/register.go
type Dependencies struct {
    DB                  *pg.DB
    Transactor          dbx.Transactor
    AnalyticsDB         *bun.DB
    AnalyticsTransactor dbx.Transactor
    // gpsystem:dependencies
}

A closer is registered next to the pool's (analytics-pgxpool, and analytics-bun when the connector is bun, since the bun closer is registered after the pool's, so graceful shutdown's LIFO order closes the bun handle before its underlying pool). When cmd/worker/main.go already exists, the same pool/deps/closer wiring is added there too, so listeners and jobs see the connection through the same Dependencies struct.

.env.example gets a DB_ANALYTICS_* block pointing at the same local Postgres as the default connection. Repoint it to a different instance for local development. DB_ANALYTICS_USER, DB_ANALYTICS_PASSWORD and DB_ANALYTICS_NAME are required: the process fails at startup, not on the first query, if they are unset; see the configuration reference.

cmd/migrate only ever targets the project's default connection. A named connection's schema is not managed by the generated migration runner.

Binding the module repository to it

By itself, add db only makes the connection available on Dependencies; it does not touch the module's repository. Bind the module's shared repository/ skeleton to it with add surface --db (or, when retrofitting, add core --db):

go tool gpsystem add surface news reports --db analytics
# -> internal/modules/news/repository/analytics/doc.go

Without --db the module keeps the flat repository/ directory bound to the default connection; nothing changes for projects that never call add db.

Older projects

add db preflights cmd/<module>/main.go for the gpsystem:pools and gpsystem:closers anchors before writing anything. Projects generated before this feature lack them; the command fails with the exact two comment lines to add by hand (see a freshly generated project for placement); run it again once they're in place.

Copyright © 2026