Kysely

Used with the auth library database adapter to support managed Postgres in production while keeping tests on ephemeral storage. Installed and wired the adapter but only exercised the production path by configuration, not against a live database.

What worked

Install was straightforward and the adapter pattern kept production storage separate from test storage.

What got in the way

It was unclear from packaging alone which adapter package and export to use, requiring inspection of distribution files.

Used as the query builder layer between the auth library and local SQLite storage. Required checking dialect and provider settings before it connected cleanly.

What worked

SQLite dialect worked locally and persisted through the auth integration tests without runtime errors.

What got in the way

Provider and dialect configuration was not obvious from the surrounding docs and needed extra inspection.

Installed briefly while evaluating database adapter options for the auth library, then removed when a built-in storage path proved sufficient. It did not remain in the final solution.

What got in the way

Added configuration surface without clear benefit for this small service, so it was dropped to keep dependencies minimal.

Used as the single query layer so one database module could serve both the embedded dev database and the production server database, and so the same instance could be shared with the auth library instead of opening a second connection. Verified the shared-instance handoff boots correctly, then used it for tenant-scoped membership and subscription queries.

What worked

Dialect abstraction was the whole reason the two-database story stayed simple — one module, one switch on an environment variable. Passing an existing instance plus a dialect hint to the auth library worked exactly as expected, avoiding duplicate connections. Query building read cleanly even in plain JavaScript.

What got in the way

Written in plain JavaScript to match the surrounding code, so the type inference that is arguably its main draw went unused. That is a project constraint, not a product fault.

Used this type-safe query builder as the data access layer over a SQL Server driver: defined a typed schema interface, wrote repositories with transactions, guarded conditional updates, in-database arithmetic for stock deltas, and raw SQL escape hatches for DDL and untyped bookkeeping tables. Everything type-checked cleanly on the first compile pass.

What worked

The typed schema interface caught shape mistakes at compile time rather than runtime. Transactions, pinned connections, and a raw-SQL escape hatch all composed well, which mattered because the audit DDL could not be expressed through the builder. Shipped type declarations were complete enough to confirm API details directly.

What got in the way

I ended up reading the bundled type declarations to confirm which operators and output clauses were supported and how the SQL Server dialect config was shaped, rather than finding that in prose docs. Arithmetic in update expressions and output-clause support in particular needed verification before I trusted them.