The implementation desk · Proposed packs
Bring rehearsal evidence
to the change review.
Preparing a PostgreSQL change? The proposed $49 pack brings a reproducible rehearsal, observed results and editable review documents together for one decision. One payment per pack, with no recurring billing.
One change, one review pack.
Each planned pack would name the change it covers, the versions tested and its limits before purchase. It would include the rehearsal source, recorded results, inspection queries and a decision card your team can edit.
Start with the free index and pooling samples below. Tell us which upcoming change needs a pack of its own. The first paid-only pack has not been selected. The free briefs, planner and published labs stay free.
Packs would provide material for your team’s review. They would not include a review of your production system, on-call support or a guarantee that your change will succeed.
Start with existing tools and free examples.
Your migration tooling may already cover the task you need to review:
- Squawk provides PostgreSQL migration lint rules, including a check for concurrent index creation.
- Strong Migrations checks Rails migrations for potentially dangerous operations and explains alternative migration steps.
- Atlas migration linting analyzes changes using a development database. Its documentation lists this command as a Pro feature from version 0.38.
For a pooling change, these free examples may already answer your question:
A Postline pack would need to add a specific failure rehearsal and review artifact you still lack. If your existing tools and the free samples answer your question, use them. Tell us which remaining question needs a reproducible experiment.
These descriptions follow the linked documentation and authors’ reports, reviewed on 8 October 2026. We have not benchmarked these tools or independently rerun the linked examples.
Help choose the first paid pack.
You can suggest a task without requesting emails. If you work on PostgreSQL, a short reply to these questions would help:
- What change are you planning, and which part is still uncertain?
- What do your current tools and the free samples already cover? What evidence is missing?
- Would you pay $49 once for a pack addressing that gap: yes, no, or not sure? Why?
Leave a comment on either Mataroa issue. No account is needed; name and email are optional. Approved comments are public, so leave out credentials and private production details.
Another PostgreSQL change? Either thread is fine.
Register interest. Pay nothing today.
Sales are not open. Request a confirmation invitation for the free brief and pack updates when email delivery resumes. This saves an unconfirmed request; it does not reserve a pack, start a paid subscription or authorize a charge.
Follow the brief
Email delivery is paused. RSS works now, and you can save a request for a confirmation invitation.
Try the free connection-budget planner and download your worksheet ↗
Inspect the free launch samples
Proposed price: $49 per pack, paid once. A focused set of editable review documents and a reproducible rehearsal for one PostgreSQL change. This launch sample remains free. Sales are not open; an invitation request starts no subscription and authorizes no charge.
Run the failure rehearsal
Inspect the full script and all 12 recorded SQL steps in your browser. No download or account is required to review the evidence.
Download the concurrent-index lab: a Python script, setup instructions and actual PostgreSQL 18.6 observations. It creates a disposable local cluster with synthetic data, demonstrates a failed unique concurrent build and a skipped retry, verifies cleanup, then runs a separate successful nonunique build.
The recorded failure left both index flags false. IF NOT EXISTS returned successfully without fixing them. Use that result to review what your migration runner checks after a command completes. This is a local functional test, not evidence of production performance or a universal cleanup rule. The script requires PostgreSQL 18 binaries and never connects to your existing database.
Inspect cancellation before choosing recovery
Read the separate cancellation rehearsal, or download its script and observations. It records 28 steps across three controlled wait stages. Outcomes differ: no index, invalid/not-ready, and invalid/ready. The last still rejected duplicate writes; a fresh unique rebuild was then verified.
Use the evidence to add phase, exact object state and remaining sessions to your change-review card. The two index labs are free samples. They exercise synthetic local data and do not certify a production change.
Inspect session settings before choosing transaction pooling
Read the 27-step pooling rehearsal, or download the complete source and observations. Two persistent clients shared one PostgreSQL 18.6 backend through PgBouncer 1.26.0. Search paths stayed distinct; an untracked session timeout crossed between clients. After resetting it, transaction-local timeouts reverted at commit and rollback.
Use this free sample to identify the exact setting, version and transaction boundary your application depends on. It records setting values in a disposable local experiment; it does not certify your workload or measure performance.
Migration decision card
- Service and PostgreSQL version:
- Change owner / observer:
- Query or requirement this change serves:
- Existing indexes and constraints reviewed:
- Connection path and transaction wrapper checked:
- Rehearsal dataset and observed duration:
- Approved lock wait and total execution budgets:
- Service metric, stop threshold and observation window:
- Exact index/constraint state inspection:
- Failure cleanup decision and approving owner:
- Post-change query plan and latency evidence:
- Follow-up date:
Connection budget worksheet
For direct traffic: sum(peak simultaneous process count × per-process maximum pool size), plus jobs, tools and headroom. Include rollout overlap. For PgBouncer traffic: sum server-side pools over user/database pairs and pooler instances, including reserve capacity, plus direct connections. Separately budget accepted clients and waits.
Go / revise / stop review
Download the free pooling review worksheet to record connection paths, version-specific dependencies and rehearsal evidence alongside the budget. It is editable without an account and contains no pre-filled claim that a workload passed.
1. Does every consumer fit within the role's usable database slots after headroom? 2. Does the rehearsal include the deployment transition, not only steady state? 3. What fails first at saturation? Is the error visible to an operator? 4. Can session-dependent features survive the selected pool mode? 5. What evidence would change the selected limits?
These templates structure a team's own review; they do not assert that a production change is safe. See issues 001 and 002 for source-linked technical context.
Read the source-linked briefs ↗