EdgeDB 1.0 Alpha 4 “Barnard’s Star”

Improved Usability of Server Instance Maintenance

One of the ways in which we’re setting EdgeDB apart from previous generation databases is the focus on usability of day-to-day tasks. One particularly gnarly topic is maintenance of server instances: installing a new version, upgrading existing databases to a new version, setting up an instance to run properly as a service daemon, accessing logs, and so on. It gets especially tricky when multiple operating systems provide their own unique ways to achieve those tasks. Even better if the user needs to keep a few versions running concurrently.

We looked at how efficient rustup is in ensuring the user has a fully functional up-to-date installation of the Rust toolchain, and got inspired: what if we can provide this experience for a database?

The end result is the new edgedb server group of commands that ships with the default EdgeDB CLI. Its design was planned and discussed as part of an RFC process which, as the rest of EdgeDB, is open. Check it out!

The most visible change related to edgedb server is that it is now the new recommended way to install EdgeDB servers on your operating system. See edgedb server install --help for details. The underlying installer will still use your operating system’s package manager but it provides instance configuration in ways that allow for running multiple EdgeDB versions concurrently on one machine. And with edgedb server upgrade you can easily bump the version on an existing installation without having to redo configuration or dump and restore data manually.

And how do you get the new CLI tool on your machine? We redesigned the Download page to be more inviting, providing a new cross-platform way to install EdgeDB with a single-liner in the terminal. And if you’re a macOS user, you might want to use our new Homebrew tap!

JavaScript Bindings Got More Powerful

We supercharged edgedb-js, our JavaScript client for EdgeDB, with an efficient connection pooling implementation. This allows users write faster applications with less code.

import {createPool} from 'edgedb';

// Initialize the pool; should be done when
// the nodejs app server starts:

const pool = await createPool({
  connectOptions: {
    user: "edgedb",
    host: "x.x.x.x",
  },
  minSize: 5,  // start with 5 connections
  maxSize: 50  // and grow the pool up to 50 connections
});

// Later you can easily make requests using this pool.
// If you don't need transactions:

await pool.query('SELECT 42');

// or get a proper Connection object in a variety of ways:

await pool.run(async (conn) => {
  conn.execute('START TRANSACTION');
  try {
    conn.query('SELECT business_logic(10 / $num)', {num: 42});
  } finally {
    conn.execute('ROLLBACK');
  }
});

// or:

const conn = await pool.acquire();
try {
  conn.query('SELECT datetime_current();');
} finally {
  await pool.release(conn);
}

We also thought hard about the API and decided that fetch*() function names don’t really sound very natural when you’re trying to insert or update data. We renamed them to query*() which is the obvious name in hindsight:

async function example(conn) {
  // Use `conn.query()` instead of `conn.fetchAll()`:
  await conn.query(`
    INSERT User {
      name := 'Alice'
    }
  `)
}

The change actually originated in our Python client and this is where the change was discussed.

DESCRIBE Is Worth a Thousand Greps

As part of the usability sprint we made DESCRIBE better. When describing objects, it will now list all matches for the specified name if available. This is particularly interesting in case of user functions masking user types or standard types/functions.

DESCRIBE ROLES and DESCRIBE SYSTEM CONFIG in turn allow you to quickly assess the respective areas of the database, and make dumping an entire server instance easier.

Stored Migrations Are Coming

The back-end implementation for the much improved workflow for migrations is mostly complete. The next step is providing a CLI for it, which we plan to release as part of Alpha 5.

We think this set of features will be an important foundation of successful EdgeDB adoption. You can read more about them in our open RFC document on the topic.

You Can Talk To Us Right On GitHub

GitHub is introducing a new feature called Discussions, a way to keep conversations happen close to the code which don’t really belong in Issues or Pull Requests.

We used to use Spectrum Chat for this purpose but as soon as we tried out Discussions, we knew this is a natural fit for us and our community. We’re an open product with a strong GitHub presence and you probably already have a GitHub account… so come talk to us!

Summary

Barnard’s Star is the first release under our new release cycle. Our ambition is to always deliver frontpage-worthy new features, but we also understand those never get built in one development sprint. At the same time, frequent milestones have many advantages both for us and our users.

With this in mind we’re proud to share Barnard’s Star with you, a release which is a step forward that tells a story. We hope you’ll enjoy the improvements we’ve made, and just as importantly, come along for the ride and witness how they’re built as they are being built.

As usual, the change log provides a detailed story of the changes in this release.

If you have any questions, feel free to join the conversation on GitHub Discussions, or ask in form of a bug report or a feature request.

If you’d like to learn more about our tech stack, we recently started a YouTube channel. At the moment we’re running a series introducing Python’s asyncio.

For future announcements, you can find us on Twitter.