@yawlabs/postgres-mcp - npm Package Compare versions

Comparing version 0.9.0 to 0.9.1

bin/postgres-mcp.mjs

@@ -18,9 +18,20 @@ #!/usr/bin/env node
  * 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
@@ -27,0 +38,0 @@ *   POSTGRES_MCP_RUNTIME=oam    require oam; fail loudly if it is missing

CHANGELOG.md

@@ -10,2 +10,40 @@ # Changelog
 
+## [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
@@ -35,8 +73,9 @@
 
-> **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)
@@ -135,2 +174,28 @@
 
+## [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
@@ -137,0 +202,0 @@

package.json

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

README.md

@@ -216,4 +216,18 @@ # @yawlabs/postgres-mcp
 
-**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
@@ -220,0 +234,0 @@ {

No alert changes

Improved metrics

Total package byte prevSize

1467665

0.28%

Lines of code

37855

0.03%

Number of lines in readme file

317

4.62%

No dependency changes