Port the test suite to pytest, complete by 1.0-alpha4

[jdatcmd]

We have a solid test suite but it uses bash and we have more than once run into problems with stray psql processes, bad shell escaping among others. Do we think it is now time to move to https://docs.pytest.org/en/stable/ ?

This will allow us to test over socket versus testing over client. It will also allow us to more easily parse the results of a test as it will return as arrays, tuples and dictionaries.

Thoughts?

[OffgridwithJD]

Position: not a port. The three problems you name are three different problems, and a port fixes one of them well, one of them partly, and one of them not at all.

I have unusually direct evidence for this, because I generated most of these failures myself
in the last day. Numbers below are from main at d007ec1, measured rather than estimated.

The corpus, so the cost is in units rather than adjectives

suites in SUITES	121
shell lines under test/	22,730
assertion call sites (check and its four typed variants, plus diff_query)	2,037
lib.sh + portlib.sh	748
suites doing process work (pg_ctl, kill, trap, mkfifo, runuser)	24
suites that only run SQL and compare	100

A full port re-lands 2,037 assertions to gain zero new coverage, and has to keep two
harnesses green on five majors and two architectures for the duration.

Splitting the three problems

Stray psql processes: a port helps here least, and it is what you named first

Two of these bit me today. Neither is a language problem:

• pkill -f "GROUP BY UserID" matched my own ssh command line and killed the connection.
• Killing a background psql left the backend inside pg_sleep() still holding its
  transaction and its locks, so a removal proof reported the same result with and without
  the fix.

The fix in both cases is pg_terminate_backend, which is SQL and is identical in either
language. And a pytest fixture finalizer does not run on SIGKILL any more than trap ... EXIT does, so the worst leaks, the ones where a runner is killed, are unimproved.

What a port genuinely removes is the mkfifo plus backgrounded-session machinery in the
handful of concurrency suites. Real, but small, and it is the minority of this class.

Shell escaping: a port wins this decisively, and it is the strongest argument you have

This one I will not argue with. Today alone: nested quoting through ssh corrupted a
postgresql.conf; you appended a suite name after a bash array's closing paren on #420,
which is valid shell, passes bash -n, and fails at run time with command not found. In
Python the first does not exist and the second is a NameError at import.

Typed results: partly already fixed, and the unfixed half is not a language problem

Two sub-classes, and they behave differently.

Empty compared with empty printing PASS is #418. We closed it in bash this week with
check_num, check_ratio and check_text, each self-tested. Worth knowing that
assert got == want in pytest reopens it: pytest ships no vacuity guard, so the
discipline has to be rebuilt there too.

Substring matching is the one that actually cost us, and Python does not fix it.
grep 'ColumnarScan' also matches PgColumnarScan, which is why two rename checks on #429
would have passed without asserting anything. "ColumnarScan" in plan is exactly as wrong.
It also cost me two published ClickBench rows attributing a result to a grouped node
that never engaged.

That one is fixable today, in bash, without changing anything:

$ psql -At -c "EXPLAIN (FORMAT JSON, COSTS OFF) SELECT count(*) FROM t WHERE i > 5"
Aggregate            | -
   Custom Scan       | ColumnarScan      <- "Custom Plan Provider", a typed field

Exact equality on Custom Plan Provider cannot match a superstring. jq does it, and
test/ already carries six Python files (ste_check.py, parquet_corpus.py,
mutate_guard.py and three others) so there is precedent for either.

What the bash harness has earned

748 lines of lib.sh and portlib.sh, and very little of it is plumbing. It is guards,
each written after something was paid for once: the cluster-identity check that exists
because pg_ctl -w only proves something answers on the port, the port band kept below
the ephemeral floor, the QUERY_ERROR.$seq sentinel so two failing queries never compare
equal, the positive-marker plan check because an absence test passes for exactly the case
worth catching.

A conftest either re-earns those or re-suffers them. The in-tree evidence that the
discipline does not transfer for free is that check_text landed on 2026-08-05 and is used
at 13 sites against 36 md5(string_agg(...)) oracles. A 23-site sweep in the language we
already have is still open. I would not bet on a 2,037-site rebuild in a new one.

What I would do instead, in order, all small and reversible

1. EXPLAIN (FORMAT JSON) for every plan assertion. Kills the substring class outright,
   in either language, and it is the class that has actually produced wrong published
   numbers. Days, not months.
2. Make the leak audit a post-condition of run_all_versions.sh and fail the run when
   stray postmasters or build directories survive. That attacks your first complaint
   directly and does not depend on the language question at all.
3. Pilot one port and run both for a month. column_projection.sh or
   analyze_stats.sh: assertion-heavy, no process work, already bitten by the classes above.
   Keep the bash version running beside it. If the pytest one catches something the bash one
   misses, that is the evidence this decision should turn on, and we will have it cheaply.

What would change my mind

If the pilot catches a real defect the bash suite missed. If the escaping class keeps
costing us after the ssh and runuser boundaries are removed. Or if someone wants
per-test parallelism and fixture reuse, which is a genuine pytest strength I have not
counted here because nobody has asked for it.

One thing I should say plainly

I am the one who produced most of the defects above, this week, and three of them were the
same shape. That is evidence for your position as much as an argument against it. What it
persuades me of is that the discipline matters more than the language, because I reached
for a string comparison where I needed a typed one in bash and would have in Python too,
and the thing that caught it every time was a premise check I had written for a different
reason.

[jdatcmd]

Everything you say is accurate but you are missing one argument: the future .

How does it not make sense to port/migrate to a standard testing framework like pytest for future work? It will lower the barrier of entry for future collaborators? Will increase portability of the tests (our tests will not run on FreeBSD for example), and will allow an entire community (pytest) to build/test/improve against?

[OffgridwithJD]

You are right about the destination, and I measured the portability argument rather than

concede it politely. It is stronger than you put it.

My answer was entirely backward-looking: 36 defects, which classes a port fixes. You are
arguing forward, and my evidence had nothing to say about that. Two of your three points
hold, one is weaker than the other two, and one of them changes what I think the pilot
should be judged on.

Portability: not "won't run on FreeBSD", but "depends on Linux in most files"

Counted on main:

construct	uses	files	why it does not port
runuser	24	14	util-linux. FreeBSD has su, different flags
timeout	44	14	GNU coreutils, not in FreeBSD base
date +%s%N	29	8	BSD date has no %N
mktemp -d /tmp/...	13	13	different template semantics
pkill	8	4	exists, flags differ
/proc/	6	2	no procfs by default
stat -c	4	3	BSD is stat -f
nproc, sed -i	9	5	GNU only, and sed -i needs '' on BSD

And 133 of 133 suites require bash rather than sh.

So it is not a shell-versus-Python question at the margin. runuser alone is in 14 files,
and it is load-bearing: it is how every suite becomes the postgres user. That is not a
port, it is a rewrite of the harness's central mechanism, and doing that rewrite in bash
buys nothing that doing it in Python would not.

I had not counted this. It is the best argument in the thread and it was not in my answer.

Barrier to entry: agreed, and I under-weighted it by looking only at defects

748 lines of lib.sh and portlib.sh, of which 320 are comments. That is the right
ratio for a file whose value is its accumulated lessons, and it is exactly wrong for a
newcomer: the knowledge is in prose that a contributor has no reason to read before they
have already been bitten.

A PostgreSQL hacker turning up knows pytest. Nobody knows pgc_setup, diff_query,
check_ratio, PGC_SKIP_BUILD, or why the port band sits below the ephemeral floor. I
treated the harness's accumulated knowledge purely as an asset to protect. It is also a
tax, and I only counted one side of it.

The community argument is the weakest of the three

pytest's ecosystem is built for testing Python applications. The hard parts here get no
help from it: initdb and pg_ctl orchestration, running as postgres, crash injection,
sanitizer runs, five majors on two architectures. pytest-postgresql assumes it owns the
cluster, which is the opposite of our situation.

The real ecosystem win is narrower and worth naming: pytest-xdist for per-test
parallelism, and fixtures with proper scoping so a cluster is stood up once per module
rather than once per suite. That is a genuine speedup we cannot get in bash without
building it.

What actually changes in my position

I argued cost and sequencing. That argument stands: 121 suites, 22,730 lines, 2,037
assertion call sites, and a long period with two harnesses green on five majors. Nothing
you have said makes a big-bang port cheaper.

But I had the pilot's success criterion wrong, and that is the substantive update. I
said judge it on whether the pytest version catches a defect the bash version missed. By
your argument that is not the payoff and it may never happen, since both harnesses would
be testing the same properties. The right criteria are the ones you named:

1. Can the guards be rebuilt? Take column_projection.sh or analyze_stats.sh to
   pytest and see whether the cluster-identity check, the port band, the empty-measurement
   refusal and the QUERY_ERROR sentinel survive the move as fixtures. If they do, the
   548 lines of non-comment harness are reproducible and the port is bounded work.
2. Does it run on FreeBSD? That is the claim with no in-tree evidence either way, and
   the pilot is the cheapest way to get some. If a ported suite runs on FreeBSD and a bash
   one does not, that is the whole argument settled with one data point.

Those are better experiments than mine, and they answer your question rather than my
question.

So, concretely

I withdraw "not a port" as a position on the destination. I would still not start with a
sweep, and I would still do EXPLAIN (FORMAT JSON) and the leak audit first, because both
are days of work that pay off in either world and neither is wasted if the port happens.

If you want to sequence it as port-by-attrition, new suites in pytest and old ones
migrating when touched, I would support that today. The thing I would want written down
before the first one lands is which of the 36 guards each fixture is responsible for
preserving, because that list is the part that took two years to learn and the part a
rewrite loses silently.

[jdatcmd]

The reason I am not a fan of explain (format json) is that means we have to rewrite all the tests anyway to process them, yes?

So if we have to rewrite the tests to be able to handle the json format (which I am a favor of the json format or YAML), why not keep our existing tests as they are to be able to validate new pytest suite tests that have JSON or YAML?

[OffgridwithJD]

Two things: my FORMAT JSON recommendation was the wrong size, and your number is 12

rather than all.

The substring class does not need JSON

I over-engineered that. EXPLAIN's text format already delimits the node name in
parentheses, so the full form cannot be a substring of anything:

grep 'ColumnarScan'                    matches PgColumnarScan      <- the bug
grep 'Custom Scan (PgColumnarScan)'    cannot match anything else  <- the fix

That is what #429 already converted the two dangerous checks to, and it costs nothing: no
parsing, no dependency. jq appears 0 times in ci.yml today, and adding it would
repeat the lesson from #418 exactly, where a missing bc made a check return the empty
string and pass.

So withdraw that recommendation. The cheap fix is a discipline, "always match the full
delimited node name", not a format change.

The number is 12, not all

	suites
total	133
run EXPLAIN at all	37
assert on a node NAME, the substring class	12
assert on a Columnar ... property line	40

Property lines are already exact: Columnar Projected Columns has no superstring in the
plan. Only the node-name matches were ever at risk, and eight of them are already in the
delimited form.

But your sequencing argument survives, and it is the better half of your point

Twelve files still have to be opened. And you are right that opening them twice is the
waste: once to fix a grep, again to port. If those files are going to move, the moment to
move them is when someone is already in them.

So I would fold the two together rather than do the JSON step at all:

The twelve plan-asserting suites are the pilot cohort. They are the most
assertion-heavy and the least process-heavy, they are the ones where typed access actually
reads better than a grep, and they are already scheduled to be touched. If porting them
proves the guards survive as fixtures and that they run on FreeBSD, that is your evidence
and it cost nothing extra. If it does not, we have twelve files with exact grep matches and
have lost nothing.

That is closer to your position than mine was, and it comes out of your argument rather
than a concession to it. The leak audit I would still do independently, since it is
language-neutral and attacks the stray-process complaint you led with.

The one thing I would still write down before the first file moves is which of the
harness's guards each fixture inherits. Not as a process gate, just so the list exists
somewhere other than in lib.sh's comments, because that is the part a rewrite loses
without anyone noticing.

[OffgridwithJD]

Sequencing decision from the owner, recorded on the alpha2 coordination issue (#469): this is the last item considered before alpha2 — deferred in order, not dropped.

The reason that helps: porting mid-queue would invalidate the test evidence attached to every in-flight PR. Taking it last means #444, #446, #468 and the rest are already evidenced against the bash suite, and the port starts from a settled tree.

I am recording concrete harness failures as they occur so the decision has evidence rather than impressions. Today produced two that are genuinely about bash — sudo -E silently dropping an exported variable so a run measured the flag being absent rather than failing, and an scp landing a file while the wrong branch was checked out so a supposedly-RED run exercised a tree without the feature in it. It also produced three void measurement runs that a Python harness would have failed at identically (an over-compressible fixture, aggregates answerable from metadata, a parallelism confound), and I would not count those toward the case.

[OffgridwithJD]

The deferral condition has expired, and here is the evidence I promised

Two things bring this back: alpha2 has shipped (v1.0-alpha2 tagged,
default_version = '1.0-alpha2'), and this was deferred as "the last item considered
before alpha2 -- deferred in order, not dropped". So the sequencing decision is due to be
re-made, and it is yours to make.

I said above I would record concrete harness failures as they occur so this had evidence
rather than impressions. Paying that, measured rather than recalled.

The specific bash trap that bit us no longer exists in the tree

The failure I recorded was psql <deliberately failing> | grep -q ... && echo yes || echo no:
under set -o pipefail the pipeline takes psql's non-zero status even though grep matched,
so the check silently answers "no". Counting it today across all 227 suites:

shape	count
boolean psql | grep -q (exit status load-bearing)	0
psql | grep -c (count captured, status discarded -- not the trap)	5 files
the two remaining matches	comments documenting the trap, in native_groupagg and parallel_copy

I checked this expecting to find survivors and found none. The class was fixed, written
down in-tree where the next person meets it, and the tree has been kept clean of it since.
That is the bash suite's own immune response working, and it is evidence against the
premise that this keeps recurring.

Most of the shell failures since the deferral are outside a port's blast radius

This is the part that changed my view of the argument's shape. A pytest port replaces
test/*.sh. It does not replace .github/workflows/*.yml or the ad-hoc glue we drive the
box with. Sorting what actually went wrong since 2026-08-07 by where it lived:

failure	where it lived	would a pytest port have prevented it?
set -uo pipefail does not cancel GitHub's bash -e {0}, so an rc branch was dead code (#742)	.github/workflows/nightly.yml	no
nested quoting through incus exec measured the wrong SQL and reported a clean 3x for a shape it never ran	ad-hoc glue	no
incus file push piped into head truncated three source files to zero, surfacing later as undefined symbol	ad-hoc glue	no
sudo -E silently dropping an exported var, so a run measured the flag absent (your note above)	glue/ops	no
scp landing a file on the wrong checked-out branch, so a "RED" run had no feature in it (your note above)	glue/ops	no
the psql | grep -q pipefail trap	test/*.sh	yes
a C-style /* */ block parsing as globs and running at runtime	shell generally	yes, Python raises SyntaxError

Two of seven are inside the surface a port would replace, and one of those two is already
extinct. The rest are CI YAML and operator glue, which stay bash whatever test/ is
written in.

What a port would cost, counted

suite files	227
lines in test/*.sh	39,940
harness (lib.sh, portlib.sh)	1,122
runners (run_all_versions, run_coverage, run_san)	1,243
selftest layer	24 files, 1,263 lines
suites that shell out to process/binary/cluster tooling (perf, gdb, initdb, runuser, sudo, systemctl)	43

Those 43 do not become Python; they become Python wrapping the same shell, which is where
sudo -E and friends live.

The thing that has changed since August, and it cuts against a port

The harness has grown a selftest layer that pins harness-defect classes, and it is
demonstrably working. #742 alone added three checks that derive their expectations from
other files rather than restating them: every PGC_RUN_UPGRADE-gated suite must be
excluded from the coverage runner, every socket-connecting suite must set
unix_socket_directories, every nightly job must be named in docs/testing.md.
harness_selftest is 126 checks. One of those new checks caught its own too-loose
first version through its removal proof, which is the behaviour you want from a harness
that polices itself.

A port has to reimplement that layer or lose it, and it is the part of the bash suite
carrying the most hard-won knowledge.

Where I land

Not a wholesale port, on this evidence. But the cheaper move is available and follows the
mechanism this repo just established: a selftest check that forbids the boolean
psql | grep -q class outright. It is at 0 today, so the check is a ratchet rather than
a cleanup -- it keeps a fixed class fixed, which is precisely what 220/230/240 do for
theirs. That is an afternoon, not a quarter, and it buys the one benefit a port would
actually have delivered in test/.

Two honest caveats. My record is a biased sample: I write down what I learn from, not a
census, so the table above under-counts failures nobody bothered to record. And none of
this touches your "future" argument, which was never about defect counts -- a standard
framework is easier for a newcomer to read and contributes to a hiring pool, and no
measurement I can run refutes that. What the numbers do say is that the defect-rate case
for porting is weaker now than when this was filed, and that the port's addressable surface
is a minority of where our shell failures actually happen.

[jdatcmd]

Answering with what the tree actually is, since the decision turns on size and on what the
suites are made of rather than on which language is nicer.

What exists today

220 registered suites (230 .sh files; the 10 unregistered are infrastructure or
    deliberately opt-in, and selftest 040 carries the allowlist that gates exactly that)
  3,060 top-level checks   (2,701 check, 270 check_num, 79 check_text, 6 check_ratio,
                            5 check_timing, plus the structural ones)
 43,494 lines of bash under test/
     26 harness selftests, 153 checks, whose whole job is to catch a suite that
        looks like coverage and is not
     12 python files already in test/, doing the jobs where python is better

I checked the "10 unregistered" number rather than reporting it, because a suite nobody runs
is the failure this repo already had once (#257, native_scale). pg_upgrade is invoked from
run_all_versions.sh:843, extension_upgrade from the nightly, native_scale is opt-in by
design, and the rest are lib, portlib, the runners and the builders. No hole.

The two problems named here are real, and neither is fixed by pytest

Stray psql processes. Real, and I hit the class again today: a pkill -f <pattern> matched
the incus exec that carried the pattern in its own command line, three times in one session.
But that is a lifecycle bug living in pgc_setup/pgc_teardown and in how suites spawn
helpers. Pytest gives you subprocess and fixtures, which make it easier to get right; it
does not make it right, and a fixture that leaks a cluster leaks it in either language.

Shell escaping. Also real, and I hit it today: data LIKE '%$1%' cannot carry a pattern
containing a single quote, so a matcher for op[text]:'UPDATE' silently matched nothing and
reported a clean zero. Note how that was caught -- not by a type system, but by a premise
asserting the same matcher could find something else. Pytest would have removed that
particular trap. It would not have supplied the premise, and the premise is the part that
generalises.

The cost, stated honestly

3,060 checks is not a port, it is a rewrite, and the value of this suite is the claims, not
the code. Each of those checks is sharp because someone knew what would make it red. A
mechanical translation carries the assertion and drops the reason, and every one of them
returns to "unproven until re-verified". During the transition you either run two harnesses
or accept a coverage gap, on a tree where the gap is the exact thing the selftests exist to
prevent.

What the 26 selftests say about the language

This is the part I found most decisive, so I classified them rather than asserting a split.

Would not exist in python (bash artifacts, roughly a third):
echo | grep -q answering "not found" under pipefail (080); a suite assigning a bash special
variable (210); comm requiring one collation and not checking (070); the port walk wrapping
(180); the C-vs-alphabetical sort order the suite list is kept in (060).

Would exist unchanged in any language (the rest):
check "" "" printing PASS, so an absent measurement looks like a pass (100); the sanitizer
subset silently not covering a suite (130); a verdict asserting something the run did not
establish (150); an ordered comparison not using the ordered oracle (260); the nightly
enumeration going stale (240); a suite connecting by a socket whose path depends on how
PostgreSQL was built (230); a cluster that will not start being reported as a product
failure (140).

So a port buys about a third of that meta-suite and has to reimplement the other two thirds
before it is as safe as what it replaced.

What I would do instead

1. Fix the two named problems where they live. Process lifecycle is a lib.sh change and
   a selftest that fails when a suite leaks. Escaping is a rule -- pass patterns through
   dollar quoting or a file, never string interpolation into SQL -- and that is a selftest of
   the same shape as 080.
2. Keep using python where it already earns its place. ste_check.py is python because
   parsing prose is a parsing job. Nobody had to port the suite to get that.
3. If a specific class of test genuinely needs it -- concurrency, protocol-level work,
   anything wanting real data structures -- allow it in python and dispatch by extension in
   the runner. That is a much smaller commitment than a port, and it fails cheaply: if nobody
   writes the second one, nothing was lost.

Recommendation: do not port. Not because bash is good, but because the asset here is 3,060
verified claims and a meta-suite that keeps them honest, and a rewrite puts both back into
doubt to buy a third of one of them.

If you want the decision made on evidence rather than on my reading, the measurement is: over
the last six months, how many red CI runs were attributable to the harness language rather
than to the product. I can pull that from the log if it is worth an hour.

[jdatcmd]

Decision: yes, port, and the goal is a complete port by 1.0-alpha4, target 2026-09-15.

Today made the case better than the original question did. Below is what the port buys, what it does not buy, and the one thing that will decide whether it is worth doing.

Your two reasons, with today's evidence

Real connections instead of shelling to psql. Every assertion in this suite is a string parsed out of psql stdout, and that parsing has produced wrong ANSWERS, not just noise:

• A plan sweep piped EXPLAIN through head -1 without filtering psql's SET echo. Every cell matched SET, fell through the case to the *) arm, and the grid reported 25 serial, 0 Gather. The truth was 20 and 5, and the five were the finding. One step from publishing "parallel plans are gone from the tree".
• Deny arms grep for permission denied. That string is also produced by a login FATAL, a missing function (42883), a bad argument (22023) and a transaction-block refusal (25001). The house rule "assert SQLSTATE, not error text" exists because of this, and it is enforced by discipline alone.
• printf ... | grep -q closes the pipe early and reports a present match as absent. There is a selftest part (080) that exists solely to forbid that shape, and it had to be widened once when bench/ turned out to hold six more.

With a driver, a count is an int, a row is a tuple, and psycopg.errors.InsufficientPrivilege.sqlstate is '42501' because the server said so. The three failures above stop being possible rather than stop being likely.

Stray processes and escaping. Cluster ownership becomes a session-scoped fixture with teardown that runs on failure paths too, instead of pgc_teardown called by hand from every exit.

What else pytest gives us, which is the part I would actually build the port around

• xfail(strict=True) is a vacuity detector we do not currently have. A test marked "known to fail" that starts passing fails the run. That is exactly the shape that bit us this week: an arm that stays green after the fix it names is reverted. Today nothing notices; under strict xfail the harness notices.
• parametrize turns "N arms of one shape" into N reported cases. The worst finding of the week was five arms asserting the same invariant where only one could ever redden. In a wall of PASS lines that is invisible; as test_x[case3] FAILED beside four passes it is obvious.
• Stable, addressable test IDs. test_pushdown.py::test_skip[bigint-quoted] is a thing a mutation harness can run and get an exit code from. Right now proving "this specific check went red" means grepping a check NAME out of text, which is how a reverted guard once reported plain green while the check count silently fell from 190 to 186.
• Machine-readable results. --junitxml or a JSON report means the matrix can assert registered == passed + failed + skipped + xfailed automatically. Today 237 suites are registered and the last CI legs ran 228 and 231; nothing reconciles the difference or requires a reason per skip.
• Skip reasons are structural. pytest.skip(reason=...) and importorskip carry the reason into the report. Our pgc_skip already does the right thing — a missing dependency FAILS unless deliberately waived — and this preserves that while making it visible per test rather than per suite.
• Assertion introspection. assert got == want prints both sides and the diff. Every one of our 3,762 call sites hand-writes got [x] want [y].
• Plugins that map onto problems we actually have: pytest-timeout (a hung suite becomes a failure instead of a stuck runner), pytest-xdist (parallel across majors, with per-worker ports), pytest-randomly (order dependence surfaces — several of our suites share a cluster), and hypothesis (we already keep a separate C property-test harness in test/pbt/ and four fuzz_* suites; those fold in).

What it does not buy, and this matters more than the list above

pytest would not have caught any of the four things that went wrong this week. Not the checks that could not fail, not the guard whose documented escape did not exist, not the 103 non-executable scripts (the matrix runs bash test/x.sh, which never reads the execute bit), not the stale counts in prose. A better reporting format cannot tell you that a green assertion is hollow. Only mutation can.

So the port must carry the audit's verdicts with it. Porting a vacuous check produces a vacuous pytest test, with better formatting. An audit of all 268 assertion-bearing files is running now, and every finding it produces is being proved by running the mutation rather than reasoned about. That output is the input to this port.

Risk on the date, stated plainly

237 registered suites, 3,762 assertion call sites, and two weeks to 1.0-alpha4. I would run both harnesses side by side for the whole window rather than cut over, and gate each ported suite on asserting the same things as the shell one it replaces — because a suite ported wrong loses coverage silently, which is the exact failure mode we are already fighting. It also needs psycopg in every CI image and in the dev containers.

If the date has to give, my recommendation is to hold the date for the mechanism — driver, fixtures, IDs, reporting, and the highest-value suites — and let the long tail of ports land in beta 1 as fixes, since the release plan permits fixes after beta 1 and this is test tooling rather than product.