Configuration

The factory takes a connection config and an optional options object:

new PrismaBunSQLite(config, options?)

Connection config

From a URL

new PrismaBunSQLite({
  url: 'file:./dev.db',
  readonly: false,
  create: true,
  strict: false,
})

The adapter opened this connection, so it closes it on dispose() and applies any configured PRAGMAs to it.

From an existing connection

import { Database } from 'bun:sqlite'

const database = new Database('./dev.db', { strict: true })
const adapter = new PrismaBunSQLite({ database })

Use this to share one connection with non-Prisma code, load an extension, or set flags the adapter does not expose.

Ownership matters here. A connection you supplied is yours: the adapter will not close it on dispose(), and will not apply PRAGMAs to it. Closing a handle the caller still holds — possibly sharing it with other code — is the kind of failure that is very hard to attribute later, so ownership is explicit rather than inferred at teardown.

Cached prepared statements are still finalised on dispose() in both cases, since those belong to the adapter regardless of who owns the connection.

Adapter options

new PrismaBunSQLite(
  { url: 'file:./dev.db' },
  {
    timestampFormat: 'iso8601',
    shadowDatabaseUrl: ':memory:',
    statementCacheSize: 100,
    pragmas: false,
  },
)

timestampFormat

How DateTime arguments are written. 'iso8601' (default) writes 2020-01-02T03:04:05.000+00:00; 'unixepoch-ms' writes epoch milliseconds. Match whatever your existing data uses.

shadowDatabaseUrl

The throwaway database used for migration diffing. Defaults to ':memory:', which is always empty and needs no cleanup.

The shadow connection is always opened writable and creatable, regardless of the readonly/create you passed in the main config — a diffing target the engine cannot write to is useless, and readonly against the default :memory: URL fails to open at all. strict is inherited.

statementCacheSize

Prepared statements retained per connection, keyed by SQL text. Defaults to 100; 0 disables caching entirely.

Fractional values are floored and negatives clamp to 0. Infinity means what it says — never evict — while NaN is treated as a misconfiguration and falls back to the default, since it would otherwise disable eviction silently.

This is the main performance difference from the official adapter, which calls prepare() on every single query and re-parses identical SQL every time. Prisma’s query compiler emits a small set of recurring SQL shapes, so hit rates are high in practice. Evicted statements are finalised, as are all remaining statements on dispose().

That guarantee applies only while caching is on. With statementCacheSize: 0 the adapter prepares a fresh statement per query and tracks none of them, so nothing is finalised deterministically — each statement is released by Bun’s garbage collector whenever it gets to it, and dispose() has nothing to clean up. This is the one mode where a statement can outlive the call that made it and keep SQLite resources held; prefer a small cache size over 0 if that matters to you.

pragmas

Off by default. Passing an object enables a set of defaults suited to application use:

{ pragmas: {} }
// journal_mode = WAL
// foreign_keys = ON
// busy_timeout = 5000

Each is overridable:

{
  pragmas: {
    journalMode: 'DELETE',
    foreignKeys: false,
    busyTimeout: 0,
  },
}

journalMode must be one of WAL, DELETE, TRUNCATE, PERSIST, MEMORY, or OFF (matched case-insensitively), and busyTimeout must be a non-negative integer number of milliseconds. Anything else makes connect() reject rather than apply a bad PRAGMA — these values are interpolated into SQL, so they are validated rather than trusted.

foreignKeys is the one most worth setting. SQLite ships with foreign key enforcement off, so without it the relations in your Prisma schema are not enforced by the database — deletes will not cascade and orphaned rows are accepted.

journalMode: 'WAL' has no effect on in-memory databases, which keep their own journal mode. It is meaningful for file databases, where it substantially improves concurrent read performance.

PRAGMAs are never applied to a caller-supplied Database.