prisma-kysely keeps Kysely types in step with a Prisma schema

Two tools that each refuse half the problem

prisma-kysely exists because of a gap between two libraries that are individually good. Prisma owns the schema language and the migration flow, and its client gives you typed queries. What the Prisma Client will not give you is plain SQL with type safety, and when a query needs a multi-table join, the choice is between the simplified query API and a raw string where the compiler stops helping.

Kysely goes the other way. It is a query builder where the SQL you write is still SQL, and the type system knows the shape of your tables, so autocompletion works on column names and joins. What it does not do is define schema or run migrations, and the project describes it as not opinionated on that side. The common workaround, as the documentation puts it, is to use something like Prisma to define the structure and then use kysely-codegen to introspect the database after the migration has run.

That workaround has an obvious weakness. Introspection reads what the database currently looks like, so the types drift behind the schema file until something regenerates them, and the two sources of truth are the schema and the live database. prisma-kysely removes the second source. The generator reads schema.prisma and emits Kysely types, so the types move when the schema moves.

A Prisma provider that writes TypeScript

The integration is a Prisma generator, not a separate command. The package exposes a binary named prisma-kysely and its main export points at the generator entry point, so Prisma itself resolves and runs it the same way it runs its own client generator. That is the whole architecture: schema.prisma declares a generator block with provider = "prisma-kysely", the Prisma CLI invokes it during generate or migrate, and the generator writes a TypeScript file of Kysely types to a path you name.

The package is TypeScript, published to npm as prisma-kysely under the MIT license, and built with bunup into ESM output. Its own dependencies tell you how it works: @prisma/generator-helper and @prisma/internals give it the Prisma side of the contract, @mrleebo/prisma-ast parses the schema, zod validates, and typescript is present for the emit step. The repository also carries a .changeset directory and a CHANGELOG.md, so releases are cut with changesets.

The output is a normal Kysely type file, the kind you would otherwise have written by hand. The generated types follow the Kysely documentation's naming conventions, and with exportWrappedTypes enabled the wrapped helpers such as Selectable<Model> are exported alongside the plain row types.

Installing the generator and pointing it at a directory

The install is one package manager command, since the package has to be resolvable from the Prisma CLI at generate time:

bun add prisma-kysely

Next you replace, or augment, the default client generator in schema.prisma with a generator block that names this provider:

generator kysely {
    provider = "prisma-kysely"

    // Optionally provide a destination directory for the generated file
    // and a filename of your choice
    output = "../src/db"
    fileName = "types.ts"
    // Optionally generate runtime enums to a separate file
    enumFileName = "enums.ts"
    // Optionally add content at the start of generated files (imports, pragmas, comments, etc.)
    banner = "import type { Decimal } from 'decimal.js';"
}

Only the provider line is mandatory. The output directory, the file name, the separate enum file and the banner are optional, and the documentation marks output and enumFileName as optional in the same way. Once the block is in place, run prisma migrate dev or prisma generate and the types appear, ready to hand to a Kysely instance.

The banner is where custom scalar types get their imports

Custom scalar types are the reason the banner option exists. A Prisma schema can map a column to a type the generator does not know, and the generated file then references something like Decimal, Big or moment without importing it, which does not compile. The banner puts content at the start of the generated file, so the imports are there before the types.

For a single import, a one-line string is enough. For several, the documentation points at Prisma's triple-quoted string syntax:

generator kysely {
    provider = "prisma-kysely"
    output = "../src/db"
    fileName = "types.ts"

    // Add custom imports for libraries you need in generated types
    banner = """
import type { Decimal } from 'decimal.js';
import { Big } from 'big.js';
import * as moment from 'moment';
import { v4 as uuid } from 'uuid';
import type { SomeType } from './custom-types';
"""
}

The generated file then opens with those imports, followed by the Kysely import and the rest of the types:

import type { Decimal } from "decimal.js";
import { Big } from "big.js";
import * as moment from "moment";
import { v4 as uuid } from "uuid";
import type { SomeType } from "./custom-types";

import type { ColumnType } from "kysely";
// ... rest of generated types

Note the relative import in that last line, ./custom-types. It resolves against the generated file's own location, so the banner and the output directory have to agree with where your hand-written types actually live.

Config keys that reshape the generated file

The configuration table is where the interesting behaviour hides. fileName defaults to types.ts, and importExtension controls what is appended to the imports the generator writes: ".js" or ".ts" for module resolution that matches your build, and an empty string to append nothing, which is the default.

camelCase defaults to false and exists to match Kysely's CamelCasePlugin, so if your query code selects aliased camel-cased columns, turning it on keeps the generated type names aligned with what the plugin produces at runtime. exportWrappedTypes controls whether the wrapped Kysely helpers such as Selectable<Model> are exported as well, following the naming in the Kysely documentation.

enumFileName sends runtime enums to their own file instead of keeping them alongside the row types. That option cannot be combined with groupBySchema, so a schema that groups models by Prisma schema name has to keep its enums in the main file. The table also lists further keys beyond the ones reproduced here, so a full audit of the available switches means reading the current configuration reference rather than assuming this list is complete.

What the generator does not do for you

The boundary is easy to misjudge because the package sits between two mature tools. prisma-kysely generates types and nothing else. It does not create tables, it does not run migrations, and it does not introspect a live database, which means a schema change that you apply by hand to the database, outside Prisma, will not be reflected in the generated types. The schema file is the only input it reads.

It is also a Prisma plugin in practice, not only in name. The generator block lives inside schema.prisma, so the package inherits Prisma's version constraints, its CLI, and its environment. A project that has decided to remove Prisma from the stack cannot use it, and a project that wants a Kysely types file without a Prisma schema has to look elsewhere. The documentation does not describe a standalone mode for reading a schema file directly.

The generated output is also code you do not hand-edit. Nothing in the documentation describes a merge or a partial-override path, and the enumFileName and groupBySchema conflict is a good example of how the option set is shaped around a single generator pass. If your team has a convention of checked-in generated files, expect the diff to be machine-written and expect to regenerate rather than patch it.

Why not introspect the database after migrating

The alternative the documentation names is kysely-codegen, pointed at a database that Prisma has already migrated. The difference in approach is the timing and the source of truth. Introspection runs after the migration and reads the live database, so it can pick up columns, types and constraints that exist in the database even if the schema file and the database have drifted apart. That is a genuine advantage when the database was not created by Prisma or has been changed by hand.

Generation from the schema is the opposite. It runs inside prisma generate, before or alongside anything touches the database, and it reflects what the schema says rather than what the server happens to hold. The types are available before the migration is applied, they match the schema by construction, and there is no separate command to remember to run. The cost is that anything outside schema.prisma is invisible to the generator, including a hand-edited column or a type created by another migration tool.

For a team where the schema file is authoritative, the schema-driven route removes a step and a drift. For a team whose database is authoritative, the introspection route describes reality more faithfully. The documentation's framing is that keeping Kysely types in sync with Prisma schemas is the goal, and the package exists to make that as convenient as generating the Prisma client.

Licence, releases and the upgrade surface

prisma-kysely is MIT licensed, with the LICENSE file in the repository root, so it can be used in closed source applications without distribution obligations beyond keeping the notice. The package is published to npm as prisma-kysely, and the project repository is valtyr/prisma-kysely with the default branch main.

Release activity is visible in the version list. v3.1.1 landed on 2026-05-24, and v3.2.0 and v3.2.1 were both published on 2026-08-16, twenty minutes apart, which reads as a fix following a feature. The last push was on 2026-10-01, and the project is not archived, so the tree matches current upstream practice rather than a frozen copy.

The upgrade surface for a consumer is narrow in code and wider in files. A new major version can change the shape of the generated file, and the generated file is imported by your query code, so a major bump can ripple into type errors across every module that touches the database. Because the generator writes into a directory you choose, the practical habit is to regenerate into a fresh directory, diff the result against the committed version, and read that diff before accepting it.

Editorial conclusion

prisma-kysely fits teams that have already committed to Prisma for schema and migrations but want raw SQL through Kysely, especially on Postgres or Cloudflare D1. It does not fit projects that want to drop Prisma, and it cannot replace a migration tool of its own. Verify first that the generator block in schema.prisma names the output path you want, that the banner covers every custom scalar type in your schema, and that the camelCase and exportWrappedTypes settings match the Kysely plugins your query code already uses.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. valtyr/prisma-kysely on GitHub