@yawlabs/postgres-mcp 0.9.0 → 0.9.1

package/CHANGELOG.md

@@ -7,6 +7,44 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.9.1] - 2026-08-07
+
+### Fixed
+
+- **Corrected the runtime startup figures published in 0.9.0.** They were wrong
+  in both magnitude and direction, and the README used them to advise opting
+  out of the faster runtime.
+
+  The 0.9.0 numbers (Node ~650-900ms, oam ~980-1290ms, launcher-to-oam ~1.8s)
+  were measured against cold, freshly-built binaries. On Windows a binary that
+  is not in the on-access scanner's cache is rescanned on every exec, while
+  `node` resolved from PATH was cached long ago -- so the comparison measured
+  the scanner and put the entire penalty on the binary under test.
+
+  Re-measured on the same hardware with every binary warmed first, mean of 12
+  runs, `postgres-mcp version` (full module init):
+
+  | path | startup |
+  |---|---|
+  | standalone binary (`oam compile`) | 298ms |
+  | `oam run dist/index.js` | 306ms |
+  | `node dist/index.js` | 358ms |
+  | launcher -> Node (in-process) | 370ms |
+  | launcher -> oam (spawn) | 409ms |
+
+  oam starts faster than Node. What the launcher costs is the spawn: reaching
+  oam means Node has already booted, and that ~100ms hop outweighs oam's ~52ms
+  advantage, so the two land within ~40ms of each other through the npm `bin`.
+  `POSTGRES_MCP_RUNTIME=node` remains available but is now a marginal
+  difference, not the meaningful one 0.9.0 described.
+
+  No behavior changed -- `auto` (prefer oam) was and remains the default, and
+  it was the right default for the wrong stated reason. README, CHANGELOG, and
+  the launcher's header comment are corrected; the launcher comment also
+  records the measurement trap so the mistake is not repeated.
+
+## [0.9.0] - 2026-08-07
+
 ### Added
 
 - The `postgres-mcp` command is now a runtime launcher (`bin/postgres-mcp.mjs`)
@@ -31,11 +69,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   a one-time cost per MCP session rather than per tool call, but it is a real
   regression against plain Node -- `POSTGRES_MCP_RUNTIME=node` opts out.
 
-> **Version note:** the "Changed (breaking)" entries below alter the shape of
-> tool output and the CLI's exit behavior. Under SemVer-for-0.x that makes the
-> next release a MINOR bump -- `0.8.0`, not `0.7.1`. `release.sh` performs the
-> actual bump (`npm version`) and syncs `server.json`, so nothing is pre-bumped
-> here; pass `0.8.0` when cutting the release.
+  > **These figures are wrong. See 0.9.1.** They were measured against cold,
+  > freshly-built binaries and reflect the Windows on-access virus scanner, not
+  > either runtime. oam is in fact faster than Node here. Left in place rather
+  > than rewritten so the correction has something to point at.
+
+## [0.8.0] - 2026-08-07
 
 ### Changed (breaking)
 
@@ -130,6 +169,32 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   (PG17), and with only 17/18 in the matrix the pre-1.11 branch was never
   selected.
 
+## [0.7.0] - 2026-07-21
+
+Backfilled from `git log v0.6.20..v0.7.0` -- this release shipped without a
+CHANGELOG entry. Summarized from commit subjects rather than re-derived from
+the diff, so it is less detailed than the entries around it.
+
+### Added
+
+- `pg_table_bloat`: `approx` and `exact` methods via `pgstattuple` (#19).
+- `pg_top_queries`: `io_read_time_ms` / `io_write_time_ms` on
+  `pg_stat_statements` >= 1.10 (#16).
+- Cross-platform single-binary release pipeline (Scoop + Homebrew), released
+  as 0.6.21.
+
+### Fixed
+
+- `pg_list_tables`: cast `reltuples` to `float8` so `estimated_rows` is a
+  number rather than a string (#17).
+- 10 confirmed findings from a review of `f7b7cb3..a736200` (#21).
+
+### Removed
+
+- GitHub Actions workflows and the dependabot config (#24). This is why the
+  repo has no `.github/` directory and why `release.sh` is the only release
+  path; several stale comments referring to CI survived until 0.8.0.
+
 ## [0.6.20] - 2026-06-04
 
 ### Fixed

package/README.md

@@ -213,7 +213,21 @@ The published `postgres-mcp` command is a small launcher that prefers the [oam](
 
 **If you do have oam,** the server runs under it. Verified equivalent on both runtimes: all 21 tools register, queries return identical rows and `dataTypeName` values, and the error paths match. oam supplies every `node:` builtin the driver needs, including `net`, `tls`, `crypto`, and `dns` (SCRAM auth and the extended query protocol both work).
 
-**Cost, stated plainly.** Taking the oam path means Node has already booted, so you pay both startups. Measured on windows-arm64 against the 1.4 MB bundle: Node alone ~650-900ms, oam alone ~980-1290ms, launcher-to-oam ~1.8s. This is a **one-time cost per MCP session**, not per tool call -- hosts spawn the server once and hold it open -- but if you care about launch latency, set `POSTGRES_MCP_RUNTIME=node`.
+**Startup cost, measured.** windows-arm64, 1.4 MB bundle, `postgres-mcp version` (full module init), every binary warmed first, mean of 12 runs:
+
+| path | startup |
+|---|---|
+| standalone binary (`oam compile`) | 298ms |
+| `oam run dist/index.js` | 306ms |
+| `node dist/index.js` | 358ms |
+| launcher -> Node (in-process) | 370ms |
+| launcher -> oam (spawn) | 409ms |
+
+oam starts **faster** than Node here. What the launcher costs is the *spawn*: reaching oam means Node has already booted, and that hop (~100ms) is larger than oam's ~52ms advantage. So through the npm `bin`, the two land within ~40ms of each other, and `POSTGRES_MCP_RUNTIME=node` is a marginal win rather than a meaningful one.
+
+Either way it is a **one-time cost per MCP session**, not per tool call -- hosts spawn the server once and hold it open. If startup genuinely matters, the standalone binary avoids the launcher entirely and is the fastest option.
+
+> Earlier releases of this README reported ~650-900ms for Node and ~980-1290ms for oam, and advised opting out of oam on that basis. Those figures were measured against cold, freshly-built binaries and reflected the Windows on-access virus scanner rather than either runtime. They were wrong in both magnitude and direction. Corrected in 0.9.1.
 
 ```jsonc
 {

package/bin/postgres-mcp.mjs

@@ -15,12 +15,23 @@
  * resolving a few paths (a handful of `existsSync` calls, no subprocess).
  *
  * WHAT THE OAM PATH COSTS
- * Taking the oam path means node has already booted, so the total is node's
- * startup plus oam's. Measured on windows-arm64 against the 1.4 MB bundle:
- * node alone ~650-900ms, oam alone ~980-1290ms, so the oam path lands near
- * ~1.8s. This is a ONE-TIME cost per MCP session, not per tool call -- hosts
- * spawn the server once and keep it -- but it is a real regression against
- * plain node and the reason `POSTGRES_MCP_RUNTIME=node` exists.
+ * The spawn, not the runtime. windows-arm64, 1.4 MB bundle, warmed binaries,
+ * mean of 12 runs: oam run 306ms, node 358ms -- oam is the FASTER of the two.
+ * But reaching oam from here means node has already booted, and that hop
+ * (~100ms) outweighs oam's ~52ms advantage: launcher -> node 370ms,
+ * launcher -> oam 409ms. So the two land within ~40ms through the npm bin.
+ * A one-time cost per MCP session either way, not per tool call.
+ *
+ * The `oam compile` standalone binary sidesteps this entirely (298ms, no
+ * launcher, no spawn) and is the right answer if startup actually matters.
+ *
+ * DO NOT re-measure this by timing a freshly built binary. On Windows a
+ * binary that is not in the on-access scanner's cache gets rescanned on every
+ * exec, while `node` from PATH was cached long ago -- the comparison then
+ * measures the scanner and dumps the whole penalty on the new binary. That
+ * mistake produced the numbers published in 0.9.0 (node ~650-900ms, oam
+ * ~980-1290ms), which were wrong in both magnitude and direction. Warm every
+ * candidate first, or stage it out of the build directory.
  *
  * SELECTION
  *   POSTGRES_MCP_RUNTIME=oam    require oam; fail loudly if it is missing

package/dist/index.js

@@ -37796,7 +37796,7 @@ function compareVersions(a, b) {
 }
 
 // src/index.ts
-var version2 = true ? "0.9.0" : await readPackageVersion();
+var version2 = true ? "0.9.1" : await readPackageVersion();
 var subcommand = process.argv[2];
 if (subcommand === "version" || subcommand === "--version") {
   console.log(version2);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yawlabs/postgres-mcp",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "mcpName": "io.github.YawLabs/postgres-mcp",
   "description": "PostgreSQL MCP server - query, schema introspection, explain, and health checks for AI assistants",
   "license": "MIT",