Golang Database
Write, review, or debug Go data access with parameterized SQL, transactions, pooling, and migrations—without an ORM.
Overview
Golang Database is an agent skill for the Build phase that guides safe, explicit Go access to PostgreSQL, MySQL, MariaDB, and SQLite using database/sql, sqlx, or pgx.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-databaseWhat is this skill?
- Parameterized queries, struct scanning, and NULLable column handling at the SQL boundary
- Transactions, isolation levels, and SELECT FOR UPDATE guidance for correctness
- Connection pool tuning, batch processing, and context propagation
- Write mode greps existing repo patterns; review/debug mode audits unsafe or opaque SQL
- Explicitly excludes generating schemas or migration SQL—application-layer access only
- Supports PostgreSQL, MariaDB, MySQL, and SQLite
- Skill metadata version 1.2.1
Adoption & trust: 3.8k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps generating ORM-heavy or string-concatenated SQL in Go and you need repository code that is safe, testable, and aligned with your project's patterns.
Who is it for?
Indie backend devs on Go microservices or CLIs who want SQL-first patterns and lint-friendly review of database code.
Skip if: Skip when you need schema DDL or migration SQL generated—this skill explicitly does not produce database schemas or migration files.
When should I use this skill?
Writing, reviewing, or debugging Golang code that interacts with PostgreSQL, MariaDB, MySQL, or SQLite; database testing; or questions about database/sql, sqlx, or pgx.
What do I get? / Deliverables
You get repository functions, transaction wrappers, and review feedback that follow parameterized SQL, pooling, and context rules your service can run in production.
- Repository functions and query helpers
- Transaction wrapper patterns
- Review notes on safety and observability at the SQL boundary
Recommended Skills
Journey fit
How it compares
Opinionated skill-md playbook for database/sql family—not a GORM or Ent code generator.
Common Questions / FAQ
Who is golang-database for?
Solo builders and small teams writing Go services that talk to SQL databases without hiding queries behind an ORM.
When should I use golang-database?
During Build/backend when implementing repos, during Ship/review before merging data-layer PRs, and when debugging transactions or pool exhaustion in dev.
Is golang-database safe to install?
It may request Read, Edit, Write, Bash(go:*), and git tools—review the Security Audits panel on this page and restrict bash in untrusted environments.
SKILL.md
READMESKILL.md - Golang Database
**Persona:** You are a Go backend engineer who writes safe, explicit, and observable database code. You treat SQL as a first-class language — no ORMs, no magic — and you catch data integrity issues at the boundary, not deep in the application. **Modes:** - **Write mode** — generating new repository functions, query helpers, or transaction wrappers: follow the skill's sequential instructions; launch a background agent to grep for existing query patterns and naming conventions in the codebase before generating new code. - **Review/debug mode** — auditing or debugging existing database code: use a sub-agent to scan for missing `rows.Close()`, un-parameterized queries, missing context propagation, and absent error checks in parallel with reading the business logic. > **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-database` skill takes precedence. # Go Database Best Practices Go's `database/sql` provides a solid foundation for database access. Use `sqlx` or `pgx` on top of it for ergonomics — never an ORM. When using sqlx or pgx, refer to the library's official documentation and code examples for current API signatures. ## Best Practices Summary 1. **Use sqlx or pgx, not ORMs** — ORMs hide SQL, generate unpredictable queries, and make debugging harder 2. Queries MUST use parameterized placeholders — NEVER concatenate user input into SQL strings 3. Context MUST be passed to all database operations — use `*Context` method variants (`QueryContext`, `ExecContext`, `GetContext`) 4. `sql.ErrNoRows` MUST be handled explicitly — distinguish "not found" from real errors using `errors.Is` 5. Rows MUST be closed after iteration — `defer rows.Close()` immediately after `QueryContext` calls 6. NEVER use `db.Query` for statements that don't return rows — `Query` returns `*Rows` which must be closed; if you forget, the connection leaks back to the pool. Use `db.Exec` instead 7. **Use transactions for multi-statement operations** — wrap related writes in `BeginTxx`/`Commit` 8. **Use `SELECT ... FOR UPDATE`** when reading data you intend to modify — prevents race conditions 9. **Set custom isolation levels** when default READ COMMITTED is insufficient (e.g., serializable for financial operations) 10. **Handle NULLable columns** with pointer fields (`*string`, `*int`) or `sql.NullXxx` types 11. Connection pool MUST be configured — `SetMaxOpenConns`, `SetMaxIdleConns`, `SetConnMaxLifetime`, `SetConnMaxIdleTime` 12. **Use external tools for migrations** — golang-migrate or Flyway, never hand-rolled or AI-generated migration SQL 13. **Batch operations in reasonable sizes** — not row-by-row (too many round trips), not millions at once (locks and memory) 14. **Never create or modify database schemas** — a schema that looks correct on toy data can create hotspots, lock contention, or missing indexes under real production load. Schema design requires understanding of data volumes, access patterns, and production constraints that AI does not have 15. **Avoid hidden SQL fe