SQL compatibility checks

Minnow keeps SQL support in machine-readable files that drive both the PostgreSQL compatibility page and the test suite. A documented example cannot pass in the docs while failing in the engine.

SQL checks

• Every supported read example runs through both query executors. Their rows and output-column metadata are compared even when the result is empty.
• PostgreSQL-compatible reads are compared with PGlite. SQLite provides a second comparison where its syntax and behavior match.
• PostgreSQL-compatible writes replay a seeded mutation script against both SQLite and PGlite, comparing statement outcomes, affected-row counts, RETURNING, trigger effects, and the final table after every statement.
• Compatible DDL must execute in Minnow and parse in PostgreSQL.
• Every excluded form must fail with its documented error.
• Forms neither external engine can represent have explicit expected-result checks instead of a silent oracle exemption.
• Every SQL fence in the SELECT, DML, DDL, full-text, transaction, and schema guides executes exactly as published against its required schema.
• SQLLogicTest adds thousands of database-neutral queries for joins, expressions, ordering, NULL behavior, and result checking — in Node, and again inside Chromium, Firefox, and WebKit over real IndexedDB and OPFS.
• A seeded interaction-plan simulator drives DDL, DML, transactions, indexes, concurrent rounds, faults, reopens, and maintenance across several connections against a shadow model, in Node over every store and across real browser tabs.

Each matrix entry describes one checked form. It does not promise every PostgreSQL variation. Differences such as exact decimals and JSON values returning strings are named in the compatibility page and its JSON profile.

Database checks

SQL results are one part of database correctness. Separate suites cover:

• concurrent writes, crashes, compaction, and garbage collection;
• stored block and snapshot compatibility;
• storage faults and quota failures;
• IndexedDB, OPFS, workers, and package entry points in Chromium, Firefox, and WebKit;
• every packed library installed in an isolated TypeScript/Vite consumer and run in Chromium;
• memory and storage convergence;
• seeded performance regression checks.

The browser benchmarks check every answer before measuring it. They run on the visitor's machine and do not use published result captures.

Run the checks

npm test
npm run test:sql:standard
npm run test:sql:full
npm run test:simulator:full
npm run simulate:interactions
npm run benchmark:gate
npm run soak:memory
npm run test:browser
npm run test:consumer
npm run check:release

Use Testing and benchmarks for the purpose and scope of every command. The v1 support policy turns those checks into the API, browser, stored-data, and performance contract for a stable release.