sqlx VS sqlc

> The sane middle ground is libraries that give you nicer ergonomics around SQL without hiding it (like Golangs sqlx https://github.com/jmoiron/sqlx). Engineers should be writing SQL, period.

The blog suggests that an ORM for OLAP would do exactly that

sqlx builds on Go’s database/sql and adds useful features like named queries, struct mapping, and scanning slices.

SQLx isn’t a migration tool per se, but it’s a powerful library for working with SQL in Go. You can build a custom migration system using SQLx to execute migration scripts, giving you ultimate flexibility. This approach is best for teams who want full control over their migration logic.

4. Infrastructure Layer — internal/infra/ This layer implements database logic using go-jet and sqlx. It satisfies the interfaces defined in the domain layer.

### When to Use Viper Use Viper for **applications with complex configurations**, like microservices or CLI tools. For simple scripts, environment variables alone might suffice. ## Comparing the Libraries Here’s a quick table to help you decide which library fits your needs. | Library | Use Case | Key Feature | Performance | Learning Curve | |---------|----------|-------------|-------------|----------------| | Gin | Web APIs | Routing | High | Low | | Testify | Testing | Assertions | N/A | Low | | Zap | Logging | Structured | High | Medium | | GORM | Databases| ORM | Medium | Medium | | Viper | Config | Flexibility | N/A | Low | ## Tips for Getting Started - **Start Small**: Try one library at a time in a side project. - **Read Docs**: Each library has excellent documentation (linked above). - **Join Communities**: Check GitHub issues or Go forums for tips. - **Experiment**: Use the example code as a base and tweak it. ## What’s Next? These libraries are just the tip of the iceberg. Once you’re comfortable, explore others like [Cobra](https://github.com/spf13/cobra) for CLI tools or [sqlx](https://github.com/jmoiron/sqlx) for lightweight database access. The Go ecosystem is vast, and combining these tools can help you build robust, scalable applications. Pick one library, try the example, and see how it fits your workflow. Happy coding!

Go offers quick database interactions that result in fast performance. It provides both native database drivers and sqlx for simplified querying. As you have seen in this article, you have used native database driver, SQL just by importing a package straight from GitHub. Similarly, you can use sqlx to have reduced boilerplate and more built-in features like struct mapping.

sqlx for the database driver.

We've always used https://github.com/jmoiron/sqlx which is just the standard package + mapping to/from structs.

You can use this https://github.com/jmoiron/sqlx

SQLC is a modern marvel. It's not an ORM or a library; it's a code generator. You write raw SQL queries in .sql files, and sqlc generates fully type-safe, idiomatic Go code that you can call in your application.

I've been using the modernc driver for a few years in https://github.com/bbkane/enventory . It's worked perfectly with no drama. Combined with https://sqlc.dev/, I've been very happy writing (small) database applications in Go.

Speaking of Go, if you want compile-time type checking like what SQLx offers, the Go ecosystem has an option that is arguably even better at it:

https://sqlc.dev/

It has the advantage that it implements the parsing and type checking logic in pure Go, allowing it to import your migrations and infer the schema for type checking. With SQLx you need to have your database engine running at compile time during the proc macro execution with the schema already available. This makes SQLx kind of a non-starter for me, though I understand why nobody wants to do what sqlc does (it involves a lot of duplication that essentially reimplements database features.)

What would you use if ORM is to be avoided?

Perhaps something like https://github.com/sqlc-dev/sqlc ?

Next, let's write sql queries for retrieving our users & their permissions. Here we will use sqlc for type-safe code generation from our sql queries, and pgx as its backend

sqlc (https://sqlc.dev/) is amazing, but I needed to use it in several unsupported languages. So instead of creating a plugin for each of those languages, I created a generic one, which is based on go templates.

I really wanted to like sqlc, but it had some major limitations and minor annoyances last time I tried it a few months ago. You might want to go through its list of issues[1] before adopting it.

Things like no support for dynamic queries[2], one-to-many relationships[3], embedded CTEs[4], composite types[5], etc.

It might work fine if you only have simple needs, but if you ever want to do something slightly sophisticated, you'll have to fallback to the manual approach. It's partly understandable, though. It cannot realistically support every feature of every DBMS, and it's explicitly not an ORM. But I still decided to stick to the manual approach for everything, instead of wondering whether something is or isn't supported by sqlc.

[1]: https://github.com/sqlc-dev/sqlc/issues/

[2]: https://github.com/sqlc-dev/sqlc/issues/3414

[3]: https://github.com/sqlc-dev/sqlc/issues/3394

[4]: https://github.com/sqlc-dev/sqlc/issues/3128

[5]: https://github.com/sqlc-dev/sqlc/issues/2760