Generate type-safe Go for any Postgres query. If Postgres can run the query, pggen can generate code for it. (by jschaf)

Pggen Alternatives

Similar projects and alternatives to pggen

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better pggen alternative or higher similarity.

Suggest an alternative to pggen

Reviews and mentions

Posts with mentions or reviews of pggen. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-11-26.
  • Exiting the Vietnam of Programming: Our Journey in Dropping the ORM (In Golang)
    7 projects | | 26 Nov 2021
    > Do you write out 120 "INSERT" statements, 120 "UPDATE" statements, 120 "DELETE" statements as raw strings

    Yes. For example:

    > that is also using an ORM

    ORM as a term covers a wide swathe of usage. In the smallest definition, an ORM converts DB tuples to Go structs. In common usage, most folks use ORM to mean a generic query builder plus the type conversion from tuples to structs. For other usages, I prefer the Patterns of Enterprise Application Architecture terms [1] like data-mapper, active record, and table-data gateway.


    7 projects | | 26 Nov 2021
    Having written a non-ORM Go-Postgres tool [1] similar to sqlc, I'm a big fan of this article, especially their acknowledgment that using SQL moves the eng culture towards data-centric engineering. Some thoughts:

    - Application code should not rely on database table structure (like the ActiveRecord pattern). Modeling the database as a bunch of queries is a better bet since you can change the underlying table structure but keep the same query semantics to allow for database refactoring.

    - Database code and queries should be defined in SQL. I'm not a fan of defining the database in another programming language that generates DDL for you since it's another layer of abstraction that usually leaks heavily.

    - One of the main drawbacks of writing queries in plain SQL is that dynamic queries are more difficult to write. I haven't found that to be too much of a problem since you can use multiple queries or push some of the dynamic parts into a SQL predicate. Some things are easier with an ORM, like dynamic ordering or dynamic group-by clauses.


    Similar comment from a few months ago comparing Go approaches to SQL:

  • Back to basics: Writing an application using Go and PostgreSQL
    15 projects | | 22 Nov 2021
    You might like pggen (I’m the author) which only supports Postgres and pgx.

    pggen occupies the same design space as sqlc but the implementations are quite different. Sqlc figures out the query types using type inference in Go which is nice because you don’t need Postgres at build time. Pggen asks Postgres what the query types are which is nice because it works with any extensions and arbitrarily complex queries.

  • How We Went All In on sqlc/pgx for Postgres + Go
    3 projects | | 9 Sep 2021
    Any reason to use sqlc over pggen ? If you use Postgres, it seems like the superior option.
  • We Went All in on Sqlc/Pgx for Postgres and Go
    31 projects | | 8 Sep 2021
    I agree whole-heartedly that writing SQL feels right. Broadly speaking, you can take the following approaches to mapping database queries to Go code:

    - Write SQL queries, parse the SQL, generate Go from the queries (sqlc, pggen).

    - Write SQL schema files, parse the SQL schema, generate active records based on the tables (gorm)

    - Write Go structs, generate SQL schema from the structs, and use a custom query DSL (proteus).

    - Write custom query language (YAML or other), generate SQL schema, queries, and Go query interface (xo).

    - Skip generated code and use a non-type-safe query builder (squirrel, goqu).

    I prefer writing SQL queries so that app logic doesn't depend on the the database table structure.

    I started off with sqlc but ran into limitations with more complex queries. It's quite difficult to infer what a SQL query will output even with a proper parse tree. sqlc also didn't work with generated code.

    I wrote pggen with the idea that you can just execute the query and have Postgres tell you what the output types and names will be. Here's the original design doc [1] that outlines the motivations. By comparison, sqlc starts from the parse tree, and has the complex task of computing the control flow graph for nullability and type outputs.


    Disclaimer: author of pggen (, inspired by sqlc

    31 projects | | 8 Sep 2021
  • What are your favorite packages to use?
    55 projects | | 15 Aug 2021
    Agree with your choices, except go-json which I never tried. pggen is fantastic. Love that library. The underlying driver, pgx, is also really well written.
  • I don't want to learn your garbage query language
    9 projects | | 10 Mar 2021
    You might like the approach I took with pggen[1] which was inspired by sqlc[2]. You write a SQL query in regular SQL and the tool generates a type-safe Go querier struct with a method for each query.

    The primary benefit of pggen and sqlc is that you don't need a different query model; it's just SQL and the tools automate the mapping between database rows and Go structs.



  • What is the best way to use PostgreSQL with Go?
    4 projects | | 8 Feb 2021
    I created pggen a few weeks ago to create my preferred method of database interaction: I write real SQL queries and I use generated, type-safe Go interfaces to the queries.


Basic pggen repo stats
19 days ago

jschaf/pggen is an open source project licensed under MIT License which is an OSI approved license.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
Find remote Go jobs at our new job board There are 8 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.