Marcus Kohlberg for Encore

Posted on Jan 18 • Originally published at encore.dev

Go ORMs Compared

#go #orm #sql #programming

In this article, we're comparing commonly used Go ORMs to help you answer which one is suitable for your project.

But first, let's start with what an ORM is and when you might want to use one.

💡 What is an ORM? (TL;DR)

An ORM (Object-Relational Mapper) is a tool that simplifies interaction with databases.
In Go development, it basically maps Go structs to database tables, making it more intuitive to work with relational data.

For example, we might have this table in our database:

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    first_name VARCHAR(100),
    last_name VARCHAR(100),
);

And you want to use this SQL query:

-- Fetch all users with the last name "Smith"
SELECT * FROM users WHERE last_name = 'Smith';

Which using an ORM (GORM in the example below) can be written like this in your Go program:

// First we create a Go struct that maps to our users table
type User struct {
    ID        uint
    FirstName string
    LastName  string
}

// Using GORM, the equivalent query looks like this
var users []User
result := db.Where("last_name = ?", "Smith").Find(&users)

In this example, db is your GORM database connection.
The Where method adds a condition to the query, and Find executes the query, populating the users slice with the results.

This GORM query abstracts away the raw SQL, providing a more idiomatic Go way to interact with the database.
It's particularly useful for more complex queries and can significantly improve code readability and maintainability.

🙋‍♀️ When to use an ORM

Typically you'd use an ORM when you need to speed up database-related development, ensure type safety, and make code easier to read and maintain.
It's particularly handy for applications with complex data models or when you prefer not to deal with the boilerplate of raw SQL queries.

🙅‍♂️ When to avoid ORMs

It's wise to be cautious about using ORMs in performance-critical systems or where you need direct control over database interactions, as ORMs can add overhead and sometimes obscure what's happening at the database level.

🏁 Without further ado, let's take a look at the best Go ORMs.

GORM

GORM is a comprehensive ORM tool in Go, offering a code-first approach which allows defining database schemas using struct tags in Go. It's known for its developer-friendly nature, making it suitable for both beginners and experienced users. GORM supports a variety of SQL databases like MySQL, PostgreSQL, and SQLite. It's designed to be flexible, allowing developers to drop down to raw SQL when necessary. However, it's important to be cautious about its performance implications in large-scale applications.

Pros:

User-Friendly: Ideal for both beginners and experienced developers.
Flexibility: Allows using raw SQL for complex queries.
Database Support: Compatible with multiple SQL databases like MySQL, PostgreSQL, SQLite.
Active Community: Large user base and community support.

Cons:

Performance: May not be as efficient as some alternatives for large-scale applications.
Overhead: The abstraction layer can add complexity and overhead.

Try GORM

An easy path to try out GORM is by using Encore. It's a backend development platform for Go that automatically provisions and migrates PostgreSQL databases.
Learn more in the docs.

sqlc

sqlc is not strictly a conventional ORM. It offers a unique approach by generating Go code from SQL queries. This allows developers to write SQL, which sqlc then converts into type-safe Go code, reducing the boilerplate significantly. It ensures that your queries are syntactically correct and type-safe. sqlc is ideal for those who prefer writing SQL and are looking for an efficient way to integrate it into a Go application.

✨ We really like sqlc, so much so that we wrote a whole blog post about it.

Pros:

Type Safety: Generates type-safe Go code from SQL.
SQL-Centric: Ideal for those who prefer writing raw SQL.
Reduced Boilerplate: Automates much of the routine coding required for database interactions.

Cons:

Initial Setup: Can require more setup and configuration initially.

Try sqlc

Encore is designed to work well with sqlc and is a simple method of trying it out, as Encore will take care of provisioning your databases automatically.
Check out this hello-world example app using Encore and sqlc on GitHub.

ent

ent is a fairly recent ORM that uses a code-first approach where you define your schema in Go code. Ent is popular thanks to its ability to handle complex data models and relationships elegantly. It's statically typed, which can help catch errors at compile time. However, the learning curve might be steeper compared to more straightforward ORMs like GORM. It's a good fit for applications where complex data models and type safety are priorities.

Pros:

Type Safety: Statically typed, reducing runtime errors.
Complex Models: Efficient at handling complex data models and relationships.

Cons:

Long Compile Times: Generates a lot of code, leading to longer compile times.
Monolithic Approach: Can be challenging to integrate in microservices architecture due to its monolithic design.
Learning Curve: Might require more time to learn compared to more straightforward ORMs.

Try ent

Try out ent in a simple way by leveraging Encore's capability to automatically provision and migrate PostgreSQL databases.
Learn more in the docs.

SQLBoiler

SQLBoiler takes a database-first approach, generating Go code from your database schema. This means it creates highly optimized and custom-tailored code for your specific database schema. SQLBoiler is great for applications where the database schema is well-defined and changes infrequently. However, like sqlc, it requires regenerating the code when the database schema changes. It's well-suited for projects where performance is a key concern and the database design is stable.

Pros:

Performance: Generates highly optimized code for specific database schema.
Database-First Approach: Tailors the code to the existing database schema.
Custom Tailored ORM: The generated code is specific to your database, reducing unnecessary abstraction.

Cons:

Regeneration Requirement: Code must be regenerated with each schema change.
Complex Configuration: Setting up and configuring SQLBoiler can be more complex than some other ORMs.

Wrapping up

Each ORM has its strengths and ideal use cases. GORM and ent are more code-first and user-friendly, suitable for a broad range of applications.
sqlc and SQLBoiler, on the other hand, are more specialized, excelling in scenarios where direct SQL interaction or database-first design is preferred.
The choice largely depends on the specific needs and preferences of your project.