Comparing KSQL with Other Tools

First and foremost, if performance is important for you, please also check our Benchmarks on the README file.

Why KSQL and not SQLX, PGX, or GORM?

Low-level tools:

If you have worked with the database/sql package, sqlx or even pgx you might have got the impression as I did that it feels awkward.

I did write a text explaining my concerns regarding these libraries, so if you want a more in-depth view please read it here

But here follows a short description of the issues I find when working with these libraries:

1. Too many error checks even for simple queries
2. Easy ways of writing errors, like breaking the order of the .Scan arguments, forgetting to call rows.Close(), calling defer rows.Close() before checking for errors, missing error checks, forgetting to call .Rollback() or .Commit() and so on.
3. There is a lot of code duplication in regards to attributes/column names, that need to be repeated on many different queries on the same struct.
4. No easy way to make common actions like inserting a record, making updates, partial updates, or deletes.

High-level tools:

Because of that some people feel tempted to use ORMs and in Go the most famous one is GORM.

However, ORMs are complicated tools that require the whole team to learn them, they are less stable and readable than pure SQL and will often allow or even encourage developers to write bad and inefficient queries or even bugs for lack of understanding of the tool.

To illustrate this it might be enough to say that a quick search on GORM's godoc shows it has in total 169 public functions.

Tools relying on Code Generation:

Finally, we have Code Generation tools like sqlc and sqlboiler, and if that's your thing you might prefer to use them.

However, there are also reasons not to:

1. It does add an extra step to your build process, not a big deal but it is something.
2. It's usually slightly more complicated to learn how to use a code generation tool than to just learn a new library.
3. It doesn't integrate directly with your own types so you often need to convert to and from the generated structs.
4. Sometimes the generated functions will not be as flexible as you need forcing you to make some tricks with SQL, that happens for example with sqlc for partial updates.

Finally it is important to note that contrary to most people's expectations the Benchmarks on the README file do not indicate sqlc or sqlboiler are any faster than KSQL, sqlx, pgx or the database/sql library. This also makes sense given the fact that the generated code also uses the database/sql library internally.

Some final notes

All these tools work, and they all have trade-offs. I am not saying KSQL is the only good solution.

But I did create KSQL because of my dissatisfaction with the existing tools.

KSQL does address the issue of being easy to learn, easy to read and easy to maintain which are often important requirements for any software team.