Choosing a database adapter

SQB ships one adapter package per supported database. An adapter bundles two things: a SerializerExtension (the "dialect" — teaches @sqb/builder that database's SQL syntax, e.g. LIMIT/OFFSET vs. FETCH/OFFSET, RETURNING support, identifier quoting) and an Adapter implementation (the actual connection/cursor logic on top of a driver). Installing the adapter package pulls in its matching -dialect package automatically via a side-effect import, and self-registers with SQB — there's nothing else to wire up.

Database	Package	Driver	Driver type
PostgreSQL	@sqb/postgres	PostgreJS	Pure JS
MySQL	@sqb/mysql	mysql2	Pure JS
MariaDB	@sqb/mariadb	mariadb (official)	Pure JS
Microsoft SQL Server	@sqb/mssql	mssql (tedious-based)	Pure JS
Oracle Database	@sqb/oracle	oracledb	Thin mode by default (pure JS); optional Thick mode links a native Oracle Client
SQLite (native)	@sqb/sqlite	node:sqlite / bun:sqlite	Native (built into the Node.js/Bun runtime)
SQLite (WebAssembly)	@sqb/sqljs	sql.js	WebAssembly

Guidance

• Targeting a server database? Pick the adapter matching that database — PostgreSQL, MySQL, MariaDB, SQL Server, or Oracle. All of them speak the same SqbClient/Repository API, so switching between them later is mostly a matter of swapping the adapter package and connection options.
• Embedded/local SQLite in a normal Node.js or Bun process? Use @sqb/sqlite — it needs no native build step because it relies on the runtime's own SQLite bindings (node:sqlite / bun:sqlite). This requires Node.js >= 22.5.
• SQLite in a browser, or any environment without native SQLite bindings? Use @sqb/sqljs, which runs SQLite compiled to WebAssembly via sql.js. It shares its dialect with @sqb/sqlite (both generate standard SQLite SQL), so query code written against one works against the other.
• Not sure yet, or writing a library that should support several databases? Start with just @sqb/builder and add a @sqb/connect + adapter pair when you're ready to run against a real database.

Migrator support

@sqb/migrator ships a migration adapter for every adapter package above (since v6.0.8), so versioned migrations work against PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, and SQLite (@sqb/sqlite and @sqb/sqljs alike). connection.dialect picks the migration adapter; for SQLite, connection.driver ('sqlite' or 'sqljs') tells the two SQLite adapters apart.

The adapters differ in a few dialect-driven ways — whether the bookkeeping schema is auto-created, whether a multi-statement .task.sql script needs / (Oracle) or GO (SQL Server) separators, and how concurrent runs are locked. See Running migrations for the details.