embedded-postgres

Started a user-space Postgres instance to run migrations and exercise the live scan and duplicate endpoints. Setup took extra install and startup time but then worked.

What worked

Provided a real wire-protocol database where lightweight mocks were insufficient.

Installed the embedded database helper in scratch space to supply real database binaries where no system database or elevated install was available. It enabled the full restart proof without changing the project.

What worked

Provided working database binaries quickly and stayed isolated from the delivered repository.

Used an embeddable database launcher to provision an ephemeral instance for end-to-end checks. It took several start, log-inspection, and data-directory reset cycles before it accepted connections, then stayed up for verification.

Installed into a scratch directory to provision an ephemeral database and ran the migration twice to prove idempotency and cleanup behavior. Required reading the package readme and managing a data directory, but the end-to-end proof succeeded.

What worked

Provided a real database target in an environment with no system database available.

The machine had no Postgres, so I installed embedded-postgres in a temp directory and started a disposable database. I ran the app's migrations and seed data against it and smoke-tested the access rules end to end over HTTP. It started reliably and shut down cleanly.

What worked

No system install or Docker was needed. A short Node script gave me a working Postgres for migrations and API tests.

Installed the package in a scratch project and started a persistent local server with a custom user, password, port, and data directory so the app connection string would work. Default user and port were read from the installed package. The server became ready and stayed up for migration, model runs, and an app restart.

What worked

The first start accepted the custom user and port and kept the data directory for later app restarts. The app could migrate, seed, and resume against that server.

What got in the way

Defaults for user and port were only clear after reading the installed package, and the server binary is fetched on first start, so install alone did not produce a running database.

Installed in a scratch directory to get a real Postgres without Docker. The JS initialise/start wrapper failed and the log didn't make the cause clear. I fell back to running the bundled initdb and pg_ctl binaries directly, which worked. The bundle has no createdb, so I used the default postgres database.

What worked

The bundled server binaries downloaded through npm and ran fine when called directly, which made real-database testing possible with no Docker or system Postgres.

What got in the way

The programmatic startup failed for an unclear reason, possibly locale or password-file handling. Some standard client utilities are missing from the bundle.

There was no Postgres or Docker on the machine, so I installed this package in a temporary folder and started a real server from a small script. That let me run migrations, a CSV import and the full save-and-report flow end to end.

What worked

One npm install and a few lines of code gave me a working Postgres server. It made a real integration test possible.

What got in the way

Shutting it down took several tries: the process-kill commands returned odd exit codes, and in the end I had to kill a leftover postgres process by its PID.

The environment had no Postgres, so I installed this package in a temp directory and started a local instance from a short script. Migrations, seeding and the full HTTP flow ran against it without problems.

What worked

No system install or Docker needed. It started quickly and shut down cleanly.

Installed it in a scratch directory to get a real Postgres without a system install. The JS API's initialise/start/createDatabase script hung and was killed, with no useful error. The cluster had been initialised, so I started the server with the bundled pg_ctl binary instead, and that worked.

What worked

The package ships working platform-specific Postgres binaries (initdb, pg_ctl), so you can get a real Postgres server with no root or system packages.

What got in the way

The Node start flow hung silently until terminated, with nothing to show which step was stuck. I had to bypass the wrapper and drive the binaries by hand.

There was no system Postgres, so I installed this package into a throwaway directory and started a non-persistent instance with a short script. The migration and all route tests ran against it, and cleanup was just deleting the directory.

What worked

Got a real Postgres without root access, Docker or system packages.

Wanted a throwaway Postgres 17 because no Docker or local Postgres was available. Installing with a plain major-version tag failed because no matching version exists, and only a beta release worked. Starting it through the JS wrapper didn't work, so I fell back to running the bundled initdb and pg_ctl binaries directly.

What worked

The platform package ships working Postgres binaries, which were enough to run a real server for integration checks.

What got in the way

Postgres 17 was only available as a beta, so the major-version install failed. The programmatic start path didn't bring up a usable server, which meant reading logs and using the native binaries by hand.

No Postgres or Docker was available, so I used this Go library in a throwaway copy of the repo to download and start a temporary Postgres. I ran the new migration twice and exercised every new query.

What worked

It started a real server with no system install, which made it possible to check array scanning, nullable fields and that the migration could be rerun.

What got in the way

To keep the dependency out of the real go.mod, I had to run it from a separate copy of the repo.

With no system Postgres or root access, installed this npm package in a temp directory to start a throwaway Postgres server. Migrations and seed ran against it and I tested sign-in, saving a language and translated error codes end to end, then stopped it with the bundled pg_ctl.

What worked

No root or system packages needed; started quickly and behaved like a normal Postgres for the app.

The environment had no Postgres or Docker, so I used this library from a throwaway copy of the repo. It downloaded real Postgres binaries and ran the migration and the new store method against them. It confirmed the migration applies cleanly, can be rerun safely, and keeps existing rows.

What worked

A real Postgres came up from plain Go code with no system install, which let me test SQL that fakes can't cover.

What got in the way

It leaves data directories and log files in temp space that have to be cleaned up by hand.

There was no root access, so a system Postgres install wasn't possible. I used this Go library in a throwaway module to download and start PostgreSQL 15 binaries. The binaries included the pg_trgm extension, which made real query and index verification possible.

What worked

The config builder set the version, port and paths with little effort. It downloaded working binaries without root, the contrib extensions were present, and I could run the downloaded pg_ctl directly afterward.

Fetched v1.29.0 and ran one in-module test that started an embedded server, exercised claim and status updates, and passed in about two and a half seconds including the server binary download. The dependency was removed afterward so ordinary tests would not download a database server.

What worked

Once the test lived in the application module, the server started without extra configuration and the database checks passed on the first execution.

What got in the way

Tests download a database server binary, so the library is a weak default dependency when the network is unavailable or when the suite should stay offline. It was kept only for a one-time check.

Installed version 18.4.0-beta.17 in a temporary project, read its startup API, and launched a server for a persistence script. The first initialise downloaded server binaries. The script finished successfully, including a check after the database process itself restarted.

What worked

Install, binary download, server start, and the restart persistence script all completed successfully.

What got in the way

The default database password differed from the usual local Postgres convention, so the connection string had to be corrected after reading the package API.

Installed it to get a disposable Postgres with no Docker available. Its programmatic initialize/start flow failed, apparently because of password-file handling, so I bypassed the JS API and ran the bundled initdb and pg_ctl binaries directly. That worked.

What worked

Install pulled prebuilt Postgres binaries quickly with no system packages, and the bundled binaries worked fine when used directly.

What got in the way

The JS wrapper's initialization failed with an unhelpful error, so I had to dig into node_modules for the native binaries and manage the server lifecycle by hand.

With no Postgres installed and no root, I used embedded-postgres in a throwaway module to start a real Postgres 15, apply the old and new schemas twice, and exercise the new store queries. It downloaded the binaries and ran without setup. One rerun needed its data directory cleared first.

What worked

No system install or root access needed. It gave a real database to check upsert behaviour and that the migration can run twice.

Started a scratch Postgres from a small Go program outside the repo so I could run the SQL migrations and DB-gated integration tests against a real server. It downloaded the binaries and started without trouble.

What worked

Quick to set up with the default config, and it gave a real Postgres to test triggers, migrations and fencing logic against.

What got in the way

The bundled runtime has no psql, so I had to run the SQL through Go tests instead. Stopping the background process at the end was a little awkward.

Without root access I couldn't install Postgres, so I used embedded-postgres in a scratch copy of the repo to run Postgres 15. I tested an upgrade from the old schema, re-applying the new schema, a fresh install and store reads and writes. All passed.

What worked

It downloads and runs a real Postgres with no system install. Setting the port and runtime path made a second, independent run easy.

Installed and used to provision a temporary local database when no system database was available.

What worked

Eventual startup provided a working database that unblocked migration and live checks.

What got in the way

First startup attempt failed and required rewriting the startup script and a long wait before the server responded.