What happened
Reylo has released version 0.6.0. The release adds support for running Reylo queries through Slonik: .run(), .with(), and .try() can receive a Slonik pool, a connection obtained through pool.connect(), a transaction, or a savepoint. Reylo says those calls return the same values they do with its other drivers, regardless of the type parsers configured on the pool. The integration requires Slonik 49.12.0 or later because Reylo relies on Slonik's per-query type parsers. Pools using row-rewriting interceptors, specifically transformRow or transformRowAsync, are rejected before a query runs.
The new .try() API runs a query as .run() would, but resolves to either { value } or { error } when the database rejects the query. .trySync() provides the corresponding behavior for synchronous SQLite clients. For write statements, the release says error names are narrowed from catalog information to the constraints the statement can actually write through. In the example supplied with the release, a unique-violation error exposes a constraint typed as one of the relevant table constraints or undefined. This changes the application boundary: a predictable database failure can be handled as a returned branch rather than only as an exception path.
The release also ships npx reylo play, a local version of the Reylo playground served on 127.0.0.1 against the project's database. Editing a query updates its parameters, inferred return type, and errors as the user types. Reylo states that the playground does not run queries and does not write to .reylo/; --no-open prevents it from opening a browser.
Several changes can affect existing projects. PostgreSQL intervals now arrive as ISO 8601 duration strings, such as P1DT2H3M4S, rather than PostgreSQL-style text. pgvector vector and halfvec values now arrive as number[], and their parameters take one value. An hstore column becomes Record<string, string | null>. More reads now return Row | null rather than Row[]: this includes subqueries, common table expressions, views, and MySQL joins when a unique key establishes that at most one row can match. The release additionally reports inference improvements for extensions, JSON keys, correlated JSON, aggregates, self-joins, cache invalidation, and PostgreSQL and MySQL cardinality cases.
What the archive adds
This is a new release on a known Reylo story. The earlier Field Note, Reylo 0.3.0 released: import .sql files into TypeScript with types inferred from the live database, no ORM or codegen, covered the product's core proposition: importing SQL into TypeScript with live-database type inference. Version 0.6.0 extends that proposition into driver support, runtime error handling, and more precise inferred result shapes.
Trend signal
No supplied pattern genuinely fits this release closely enough to make a defensible trend claim.
Why it matters
Teams adopting Reylo should treat this as more than a convenience release. The new Row | null inference can expose assumptions in application code that previously treated a query as a collection even where a unique key constrained it to zero or one row. The interval, vector, and hstore changes likewise alter the values that cross from database to TypeScript.
For teams on Slonik, the release creates a supported path to retain their pool, transaction, and savepoint workflow while using Reylo's generated query interfaces. .try() is particularly useful where a uniqueness or constraint failure is expected business logic: it makes the failure branch visible in the returned value and provides constraint information constrained by the statement's write target. The value is not that database errors disappear; it is that callers can model selected failures deliberately while preserving the database as the authority that rejected the operation.
What happens next
- More application code will adopt explicit null handling for Reylo reads matched on unique keys. (3 months, 65%). Watch for: migrations or examples that replace array handling with a zero-or-one-row branch.
- Slonik users will test whether their existing pool interceptors are compatible with Reylo. (3 months, 55%). Watch for: reports involving
transformRowortransformRowAsyncrejection.
Limits and uncertainty
The release notes describe features and behavioral changes, not adoption, performance, or production reliability. They do not establish how many projects use Reylo or Slonik, whether the new playground is suitable for every development environment, or how teams should authorize access to a local database. The notes also say a Slonik pool with row-rewriting interceptors is refused, but do not provide a migration path for projects that depend on those interceptors. Finally, the release lists many inference fixes without independent examples demonstrating their behavior across different schemas or database configurations.
Skill to build now
Audit the query boundaries that upgrade to 0.6.0. In a small branch, identify Reylo calls whose SQL targets a unique key through a view, subquery, common table expression, or join; update callers to handle Row | null. Then test the concrete representations your application consumes: interval strings, pgvector arrays, and hstore objects. If unique-constraint failures are normal product flow, prototype one .try() branch and verify that the returned constraint name is sufficient for the user-facing decision.
Reader takeaway
Reylo 0.6.0 broadens the library's operational surface: it can run through Slonik, expose selected database failures as typed values, and provide a local inspection tool. The upgrade's practical cost is reviewing changed result representations and nullable single-row inference before treating it as a drop-in update.
Open question
Will Reylo provide migration guidance or compatibility options for applications that rely on Slonik row-rewriting interceptors or on the prior collection-shaped results?