Sequel 5.107.0 Adds PostgreSQL Property Graph APIs

Sequel is a Ruby database toolkit whose 5.107.0 release adds a full PostgreSQL 19 property graph surface and a more useful SQLite query plan mode. The weekly activity is small by commit count, but relevant to engineers who keep graph queries and pipeline diagnostics inside the same dataset API.

The review window contains one commit. It changes three files, with 53 insertions and two deletions. The 5.107.0 version bump is packaging work: it turns the previous master section in the changelog into a dated release, adds the 5.107.0 release notes, and moves the minor value from 106 to 107 in the version file.

That narrow diff should not be mistaken for a trivial release. The release note collects two features that affect generated SQL and database operations. There is no reported speedup, bug fix, or default change in this activity. The useful question is whether either new API belongs in an existing migration or diagnostic path.

Sequel can now create and drop property graphs through database methods. The creation DSL describes vertex tables, edge tables, their source and destination, keys, labels, and exposed properties. It generates CREATE PROPERTY GRAPH rather than asking application code to assemble raw SQL.

The validation is useful. An edge without both a source and a destination raises a Sequel error before SQL generation. Multiple source or destination declarations also fail. Property lists can expose all columns, no columns, or an explicit set, so the migration can keep internal identifiers outside the graph interface.

The lifecycle goes beyond creation. alter_property_graph can add or remove vertex and edge tables, change labels and properties, and set ownership. Separate methods rename a graph, move it to another schema, list graphs, and drop them. Removal operations support CASCADE, but the default remains the safer restricted behavior.

There is one operational wrinkle. The alteration builder records several operations, then issues one DDL statement for each operation. Wrap a related set in an explicit database transaction when partial application would leave the graph definition inconsistent. Also gate these migrations on PostgreSQL 19 or later. The release does not claim compatibility with older servers.

The query side is exposed through DB.graph_table. A pattern starts with a vertex, then uses link, to, or from to add edges and vertices. Each element can carry a graph variable, a label restriction, and a where expression. A final columns call defines the relational result returned by GRAPH_TABLE.

This fits normal Sequel composition. The resulting object can be passed to DB.from, and it can participate in joins as a table expression. Filters and selected values still use Sequel expressions, which reduces the need to splice user values into graph SQL.

The builder returns frozen copies after each method call. Reusing a base pattern in several query paths therefore does not mutate shared state. It also rejects two incomplete forms when SQL is rendered: a graph table with no output columns, and a pattern whose last element is an edge. Those failures are preferable to sending malformed graph SQL during a pipeline run.

Property graphs do not remove relational planning concerns. The release includes no benchmark and makes no claim about traversal cost. Teams evaluating this API should compare generated SQL and plans on representative data before moving a production lookup from ordinary joins.

SQLite users get a smaller but immediately practical option. Dataset#explain(query_plan: true) now emits EXPLAIN QUERY PLAN instead of the default EXPLAIN. Both paths return a formatted string, but the new mode asks SQLite for its planner summary rather than the lower level virtual machine instruction stream.

For local ETL jobs and embedded stores, that summary is usually the faster route to spotting a table scan or confirming index use. Existing callers keep the prior behavior unless they pass the option, so this is an additive diagnostic control rather than a compatibility change. It does not make a query faster by itself. It makes the planner decision easier to inspect.

  • Test property graph migrations against PostgreSQL 19 itself. SQL generation in Ruby is only one side of the contract, and server errors still decide whether a graph definition is valid.

  • Put related alter_property_graph operations inside a transaction. Review every requested CASCADE, especially when labels or vertex tables feed downstream queries.

  • Treat SQLite plan text as diagnostic output, not a stable assertion format. Capture it during investigations, but use behavior and timing tests for durable pipeline checks.

Sequel 5.107.0 is a focused data layer release. Its value is not commit volume. It is the addition of graph DDL, graph query composition, and a clearer SQLite planning view without changing existing call paths by default.