a row was written an hour after the nightly backup was taken, then deleted, then recovered to a chosen second on the live server. it existed in no backup file, so what brought it back was the continuously archived write-ahead log — which is the only way to know the archiving works. the repository is still on the same machine as the databases, and off-site copies are the next job.

192 mb of memory, half a cpu, 256 processes, no swap — read from the kernel's own cgroup files on the live host rather than from the config that asked for them. the untrusted language handlers are deleted from the image, not merely switched off.

list, create and delete databases, take a branch, fetch a connection string and rotate one, from a terminal. it refuses to print a secret to a screen unless you ask it to, so a connection string can be piped into a file without ever appearing in your scrollback.

rotating a credential changes the password, resyncs the pooler, cuts every live session and tells you how many it cut. the test that proves it is not that the new password works — it is that postgresql refuses the old one.

a full backup at 02:00 utc, continuous write-ahead-log archiving in between, and an hourly check that the archiving is still happening.

a live scheduler was being reported as inactive, which is the worst direction for a monitoring bug to fail in: everything is fine and the dashboard says otherwise, so the next real alert is the one nobody believes.

create, list and delete databases and take branches over http, carrying exactly the same permission checks, plan limits and audit rows the dashboard does. a key confined to one database is refused every management call, and the destructive half needs a human to switch it on in the dashboard first — no key can enable itself.

name a moment, and go back to it later. going back branches the database and rewinds the copy, so the original is never written over. it refuses outright if the shape of your tables changed in between rather than restoring something that no longer fits.

a statement meant to hand ownership of the copy to the new role was reaching the parent as well. found by a test that checked the parent afterwards, which is the check people forget to write.

five bugs in one line: a request that should have queued work was doing it in-band, so a slow model server became a slow dashboard.

the sign-up form encouraged a passphrase longer than the maximum the server accepts, so following the advice on screen produced an error. a rule enforced in two places had drifted into two different rules.

"we are not metering right now" became something the health endpoint reports rather than something a document remembers. a switch that is off and silent is a switch nobody notices for a month.

every insert, update and delete is recorded row by row with who did it and when, in a schema of its own inside your database. undo one change, a range, or a whole table — and when a row has been changed again since, undo refuses rather than guessing. an undo that quietly overwrites somebody else's work is worse than no undo at all.

a real independent copy of a database, measured rather than estimated, and provably nobody else's — the test checks that the copy cannot be reached by another tenant, not merely that it exists.

changes pushed to your application as they happen against a budget of 200 milliseconds, and nothing anywhere is polling.

a postgresql container to itself, with the branch path proven separately — the dedicated copy goes through the whole data directory rather than the shared-cluster trick, so the parent never drops a connection.

storage measured to six decimal places against a hand-computed integral, a retried collector that is a no-op, a forced restart that does not double-count, and a rebuilt cluster charged nothing. two obvious shortcuts were tried first and shown to be measurably wrong.

signature checked before anything is parsed, and idempotent on the provider's event id — proven with a concurrent, uncommitted, conflicting transaction rather than by calling it twice in a row.

the marketing site ported and put through a truth pass, removing every claim the platform could not demonstrate. several of those claims have since been earned back and put in front of you again.

provisioning, the dashboard page and the api behind it. a real postgresql 18 database with pgvector already installed, its own owning role, and connect rights taken away from everybody else in the cluster.

keys that can be tied to a single database and marked read-only; one statement posted over plain http with rows back, speaking neon's protocol so their client works unmodified; and a private s3-compatible bucket beside every database.

one endpoint your application connects to, and a database nobody is using holds no connections at all.

every query answered 503. the postgres driver derives its tls settings from the connection string, and that derived value silently wins over the pinned certificate passed beside it — so the certificate was never consulted. the fix pins one certificate as the only acceptable one and raises an error if it is missing, rather than falling back to an unverified connection.

the storage proxy was rewriting the host header, and an s3 signature covers the host header. an hour of "the credentials are definitely right".

email and password with a strength rule the server enforces, one-time codes by email, password reset, and verification-aware sign-up.

every sign-in records where it came from and emails you about it.

the deployment stack, and a health endpoint that reports a real problem instead of always answering yes.