EdgeDB v6​

SQL write support​

You can now use SQL DML (insert, update, delete) when connecting to your EdgeDB instance via the PostgreSQL protocol. Our aim is to support most typical use cases from tools like SQL ORMs and SQL clients.

This allows more developers to use EdgeDB, leveraging our advanced data model, tooling, and high-performance connection management. Teams can migrate their existing SQL codebases to EdgeDB without rewriting their queries. Once adopted, you can gradually take advantage of EdgeQL’s powerful query capabilities.

Existing EdgeDB users who already use EdgeQL can benefit too. While some SQL features like window functions, recursive queries, and explicit locking are not yet supported, you can use these features in SQL today. We will continue to add support for more features in the future.

In-place upgrade​

We aim for this version to be the last requiring a full dump and restore process for major version upgrades. We understand that dump-and-restore is disruptive, so enabling in-place upgrades will make it easier for teams to upgrade more frequently.

Query performance observability​

We now store statistics about query performance. These statistics are available in sys::QueryStats objects.

select sys::QueryStats {
  query,
  queryType,
  tag,
  plans,
  total_plan_time,
  mean_plan_time,
  calls,
  total_exec_time,
  mean_exec_time,
} filter .branch.name = sys::get_current_branch();

More details to come in the reference documentation.

ext::postgis​

We’ve added support for the popular PostGIS extension for PostgreSQL. This extension adds support for geographic objects and spatial data types.

std::net​

We’ve introduced a new standard library module for sending network requests, initially supporting HTTP. This module schedules asynchronous requests and allows you to poll for responses.

ext::auth​

We’ve introduced several new features to our authentication extension:

• You can now configure generic OpenID Connect providers.

• If using an OAuth provider that returns an id_token (like an OpenID Connect compatible provider), you will now receive that validated token in your callback. This simplifies using some of that data for your own User or Profile objects, saving a roundtrip to the identity provider.

• As an alternative (or in addition) to configuring SMTP for sending emails, you can now configure a webhook for various authentication lifecycle events. Use these webhooks to send custom emails, update analytics, or trigger other workflows.

• Previously, a missing PKCE session during email verification was treated as an error. Now, we support verifying end-user emails from a different device than the one used to start the sign-up or sign-in process. To enable verification without PKCE, direct the end-user to attempt a login after verifying their email, which will initiate a new flow.

  Previously, the application couldn’t identify which identity was being created during sign-up until email verification was successful. When verification occurred on the same device, it concluded with an auth token, allowing the creation of a new User based on that token’s identity. With the new process, where users are directed to sign in after email verification, there’s no clear distinction between a regular sign-in (which shouldn’t create a new User) and an interrupted sign-up (which should create a new User). To address this, we now return an identity_id in the sign-up response, enabling you to create a User type before the email is verified.

• We now configure a development-only SMTP provider for instances hosted on our Cloud. This SMTP proxy is heavily rate limited, and requires a fixed sender email address. It is intended to be used for development and testing purposes. Once you’re ready to start sending real emails, you can configure your own SMTP provider. We hope this will make it easier to get started with a simple email-based authentication flow during early development.

Breaking changes

• We have moved our SMTP configuration into a new top-level Config::SMTPProvider configuration object. During the upgrade process, your existing SMTP configuration will be migrated to this new object. If you have any scripts that configure SMTP directly, update them to use the new object.

ext::ai​

• We’ve updated the built-in list of models from our first-party LLM providers to match the latest offerings from OpenAI, Anthropic, and Mistral.

• We now pass LLM configuration query parameters through to the downstream provider.

Simpler scoping rules​

We’ve simplified the scoping rules for queries. See our RFC 1027 outlining the changes.

The RFC highlights two main reasons for removing path factoring: the need to simplify and enhance the language, and concerns about implementation. Path factoring is complex and makes it hard to quickly understand a query’s behavior. It also undermines several key design principles of EdgeQL. Although EdgeQL is intended to be read from top to bottom, path factoring allows later parts of a query to change its meaning significantly.

By default in 6.0, we will generate new schemas that opt-in to the new scoping rules. Existing schemas will continue to use the old rules and emit warnings when queries that trigger the old behavior are encountered at query time.

Bug fixes​