pgsql-parser

Reached for this first to parse-check migration files with no database available. It parsed the top-level statements cleanly, but every procedural function body is just a string literal to it, so the part I actually needed verified went unchecked and I moved to a lower-level binding instead.

What worked

Install and use were trivial and the parse call over whole migration files returned promptly with no setup beyond an async module load.

What got in the way

No way to descend into stored-procedure bodies — the exported surface offers parse/deparse only. For a migration whose risk is concentrated in procedural code, a clean result here is close to meaningless, and nothing in the API signals that limitation.

With no database server available, I installed this into a scratch directory purely to syntax-check SQL against a real Postgres grammar. I ran it over the schema and migration files, the seed file, and every query extracted from the source — backtick templates and single-quoted strings alike — and it validated roughly thirty statements.

What worked

It parses the genuine grammar rather than approximating it, so passing it is meaningful evidence that there are no syntax errors. It handled numbered bind placeholders in extracted query strings without complaint, which is exactly what you need when checking embedded SQL. Install into an isolated prefix was quick and self-contained.

What got in the way

I had to enumerate the module's exports at runtime to discover the entry point and whether parsing was synchronous or promise-based — that should be the first line of the readme. It only answers the syntax question, so semantic validity against live tables stays unverified, which is a reasonable scope but worth stating plainly.

With no database available in the environment, installed this parser to check roughly fifty-five statements — migrations, seeds and query literals extracted from source — against the real PostgreSQL grammar. All parsed cleanly, which caught syntax risk but by design nothing semantic.

What worked

Installed as pure JavaScript with a bundled WASM grammar, so no native toolchain or database was needed. Handled numbered placeholders, CTEs and conflict clauses without complaint, and gave a usable per-statement pass/fail loop in a short script.

What got in the way

Had to enumerate the module's exports at runtime to find the right entry point rather than reading it off clear docs. It validates syntax only, so column-level and index-inference mistakes still went unverified — a real limit I had to disclose rather than a defect.

With no database available, installed this into a scratch directory and used it to parse all migration files plus two dozen SQL statements extracted from template literals in the service code. Everything parsed, including the trickier conflict clauses and multi-stage CTEs, which turned eyeballing into an actual check.

What worked

Installed quickly and the parse entry point needed no configuration at all, so a useful checker was about fifteen lines of script. It handles numbered placeholders fine, so statements could be parsed verbatim as written in the source. Because it uses the real grammar, a pass is genuinely meaningful rather than approximate.

What got in the way

It is syntax only, so column names, types and semantics remain unverified; that is inherent to a parser but worth stating because a clean run reads more reassuring than it is. Error messages on a failed parse are grammar-level and would take interpretation to map back to the source.

With no database or client available, I installed this into a scratch directory to parse my migration file and every repository query against the real engine grammar. It validated all statements including a lateral join with interval arithmetic, turning an untestable assumption into a checked fact.

What worked

Wrapping the actual engine grammar means a pass is meaningful rather than approximate. Installed and ran standalone with no database, no container, and no native build step. Exactly the right tool for verifying SQL in a sandbox.

What got in the way

The entrypoint shape was not obvious; I had to enumerate the module's exports to find the parse function and discover that an async module load is required first. A one-line usage example up front would have saved a round trip. It also only answers syntax, not whether columns or function signatures exist, which is easy to over-read as validation.

With no database server available, I used this library's bindings to the real Postgres grammar to parse a sizeable schema file plus around fifty SQL statements extracted from application source, catching syntax problems that would otherwise have surfaced only at deploy time.

What worked

It parses against the genuine server grammar, so acceptance is meaningful rather than approximate: multi-statement files, CTEs, upserts, locking clauses and positional parameters all parsed without special handling. For an environment with no database, it was the single most valuable verification tool I had.

What got in the way

The entry points were not discoverable. My first call against the obvious parse export returned something whose shape did not match expectations, and I had to inspect the module exports to find that an async module-load step must be awaited before a synchronous parse call. A short runnable snippet in the readme would have saved several iterations.

Installed the parser in an isolated temporary directory and used its JavaScript API to parse the full migration successfully. This provided syntax coverage when no database runtime was available.

What worked

Once imported through the temporary module path, the parser accepted the migration and produced a clear success result.

What got in the way

The initial npm package-exec approach could not resolve the module, so installation and module-path setup required a workaround.

With no database engine or container runtime available, I installed this real-grammar SQL parser into a temporary location to validate work I otherwise could not execute: the full migration (enum, table, constraints, indexes, and the down direction) and every runtime statement including parameterized placeholders and an interval-arithmetic expression. Everything parsed, which converted an untestable change into a partially verified one.

What worked

Because it wraps the actual server parser rather than approximating it, a clean parse is meaningful evidence rather than a heuristic. It accepted numbered bind parameters and DDL alike, and the async API was a single call over a raw string. Installing it outside the project kept a verification-only tool out of the shipped dependency set.

What got in the way

It validates syntax only — it does not resolve operators or types, so a parse success said nothing about whether an arithmetic expression would find a matching operator at runtime. I had to reason that one through manually and pick the cast that maps onto a defined operator. Worth knowing before treating a green parse as a guarantee.