Slonik

A battle-tested Node.js PostgreSQL client with strict types, detailed logging and assertions.

Principles

• Promotes writing raw SQL.
• Discourages ad-hoc dynamic generation of SQL.

Read: Stop using Knex.js

Features

• Runtime validation.
• Assertions and type safety.
• Safe connection handling.
• Safe transaction handling.
• Safe value interpolation.
• Transaction nesting.
• Transaction events.
• Transaction retrying.
• Query retrying.
• Detailed logging.
• Asynchronous stack trace resolution.
• Middlewares.
• Mapped errors.
• ESLint plugin.

Contents

• Slonik
  • Sponsors
  • Principles
  • Features
  • Contents
  • About Slonik
    • Battle-Tested
    • Origin of the name
    • Repeating code patterns and type safety
    • Protecting against unsafe connection handling
    • Protecting against unsafe transaction handling
    • Protecting against unsafe value interpolation
  • Documentation
  • Usage
    • Connection URI
    • Create connection
    • End connection pool
    • Describing the current state of the connection pool
    • API
    • Default configuration
    • Checking out a client from the connection pool
    • Events
  • How are they different?
    • pg vs slonik

About Slonik

Battle-Tested

Slonik began as a collection of utilities designed for working with node-postgres. It continues to use node-postgres driver as it provides a robust foundation for interacting with PostgreSQL. However, what once was a collection of utilities has since grown into a framework that abstracts repeating code patterns, protects against unsafe connection handling and value interpolation, and provides a rich debugging experience.

Slonik has been battle-tested with large data volumes and queries ranging from simple CRUD operations to data-warehousing needs.

Origin of the name

"Słonik" is a Polish diminutive of "słoń," meaning “little elephant” or “baby elephant.” The word "słoń" itself comes from Proto-Slavic *slonъ, which was likely borrowed from a Germanic language and may ultimately trace back to Latin.

Repeating code patterns and type safety

Among the primary reasons for developing Slonik, was the motivation to reduce the repeating code patterns and add a level of type safety. This is primarily achieved through the methods such as one, many, etc. But what is the issue? It is best illustrated with an example.

Suppose the requirement is to write a method that retrieves a resource ID given values defining (what we assume to be) a unique constraint. If we did not have the aforementioned helper methods available, then it would need to be written as:

import { sql, type DatabaseConnection } from "slonik";

type DatabaseRecordIdType = number;

const getFooIdByBar = async (
  connection: DatabaseConnection,
  bar: string,
): Promise<DatabaseRecordIdType> => {
  const fooResult = await connection.query(sql.typeAlias("id")`
    SELECT id
    FROM foo
    WHERE bar = ${bar}
  `);

  if (fooResult.rowCount === 0) {
    throw new Error("Resource not found.");
  }

  if (fooResult.rowCount > 1) {
    throw new Error("Data integrity constraint violation.");
  }

  return fooResult[0].id;
};

oneFirst method abstracts all of the above logic into:

const getFooIdByBar = (
  connection: DatabaseConnection,
  bar: string,
): Promise<DatabaseRecordIdType> => {
  return connection.oneFirst(sql.typeAlias("id")`
    SELECT id
    FROM foo
    WHERE bar = ${bar}
  `);
};

oneFirst throws:

• NotFoundError if query returns no rows
• DataIntegrityError if query returns multiple rows
• DataIntegrityError if query returns multiple columns

In the absence of helper methods, the overhead of repeating code becomes particularly visible when writing routines where multiple queries depend on the proceeding query results. Using methods with inbuilt assertions ensures that in case of an error, the error points to the source of the problem. In contrast, unless assertions for all possible outcomes are typed out as in the previous example, the unexpected result of the query will be fed to the next operation. If you are lucky, the next operation will simply break; if you are unlucky, you are risking data corruption and hard-to-locate bugs.

Furthermore, using methods that guarantee the shape of the results allows us to leverage static type checking and catch some of the errors even before executing the code, e.g.

const fooId = await connection.many(sql.typeAlias("id")`
  SELECT id
  FROM foo
  WHERE bar = ${bar}
`);

await connection.query(sql.typeAlias("void")`
  DELETE FROM baz
  WHERE foo_id = ${fooId}
`);

Static type check of the above example will produce a warning as the fooId is guaranteed to be an array and binding of the last query is expecting a primitive value.

Protecting against unsafe connection handling

Slonik only allows to check out a connection for the duration of the promise routine supplied to the pool#connect() method.

The primary reason for implementing only this connection pooling method is because the alternative is inherently unsafe, e.g.

// This is not valid Slonik API

const main = async () => {
  const connection = await pool.connect();

  await connection.query(sql.typeAlias("foo")`SELECT foo()`);

  await connection.release();
};

In this example, if SELECT foo() produces an error, then connection is never released, i.e. the connection hangs indefinitely.

A fix to the above is to ensure that connection#release() is always called, i.e.

// This is not valid Slonik API

const main = async () => {
  const connection = await pool.connect();

  let lastExecutionResult;

  try {
    lastExecutionResult = await connection.query(sql.typeAlias("foo")`SELECT foo()`);
  } finally {
    await connection.release(