· ReadyStack
Worked example
Real numbers from this tool, line by line.
Six lines in one sample SQL file break a PostgreSQL 14 to 17 upgrade, and backend teams on Amazon Aurora PostgreSQL 14 or RDS for PostgreSQL 14 have until 28 February 2027 to find lines like them before AWS starts billing Extended Support.
The dates come from the AWS release calendars. For PostgreSQL 14 on both Aurora and RDS, standard support ends on 28 February 2027. Extended Support year 1 pricing starts on 1 March 2027, year 3 pricing on 1 March 2029, and Extended Support itself ends on 28 February 2030. In US East (Ohio) the charge is $0.100 per vCPU-hour in years 1 and 2 and $0.200 in year 3. One 8-vCPU instance running 8,760 hours a year works out at 8 x $0.100 x 8,760 = $7,008 a year, before you pay for the instance.
So the upgrade is the cheaper path. The trouble is that the upgrade checks look at the wrong place. pg_upgrade --check and the Aurora pre-upgrade check read the catalog of the running cluster. They do not read the backup scripts, monitoring views, ALTER SYSTEM files and migrations that live in your Git repository. A function body that calls pg_start_backup() upgrades without a complaint and then fails the first time the nightly job runs.
Here is the sample file that ships with the extension, and what PostgreSQL 14 Upgrade Lint says about it:
SELECT pg_start_backup('nightly', true); -- renamed in 15: pg_backup_start() SELECT pg_stop_backup(); -- renamed in 15: pg_backup_stop() CREATE EXTENSION IF NOT EXISTS adminpack; -- removed in 17 ... LANGUAGE plpythonu; -- removed in 15: plpython3u SELECT checkpoints_timed ... FROM pg_stat_bgwriter; -- moved in 17: pg_stat_checkpointer ALTER SYSTEM SET vacuum_defer_cleanup_age = 10000; -- removed in 16
Each of the six is a line that was fine on 14. Three were removed or renamed in PostgreSQL 15, one in 16 and two in 17. The fixed version of the same file, also bundled, returns zero findings.
The extension carries 21 rules, all taken from the "Migration to Version 15", "16" and "17" sections of the PostgreSQL release notes. They cover the backup functions that lost exclusive mode, Python 2 languages, server variables such as stats_temp_directory, promote_trigger_file, old_snapshot_threshold and db_user_namespace, the adminpack extension, the pg_stat_statements columns blk_read_time and blk_write_time that became shared_blk_read_time and shared_blk_write_time, the checkpoint columns that left pg_stat_bgwriter, and the ICU locale columns colliculocale and daticulocale. Lines inside -- comments and # config comments are skipped, so a note about what you already removed does not count against you.
Why not ask a chatbot? Most public examples of backup scripts and monitoring queries were written for PostgreSQL 14 and earlier, and assistants still produce pg_start_backup() and checkpoints_timed. A rule list read from the release notes does not drift.
The free part is complete on its own. Open any .sql, .conf or .tf file in VS Code, or paste it into the web page, and every blocker appears with its line number, the version that removed it and the line to write instead. No key, no account, nothing uploaded.
The next job is the upgrade ticket itself: a list of every blocker across every migration folder. That is the paid part, a one-time licence that scans the whole workspace at once and exports one report as Markdown and CSV.
Start with the file you trust least, usually the backup script or the Grafana query nobody has touched since 2021.
15 seconds — what it actually does
Questions people ask
What does PostgreSQL 14 Upgrade Lint check?
It reads .sql, .conf and .tf files line by line and flags 21 functions, server variables, languages and catalog columns that PostgreSQL 15, 16 or 17 removed or renamed, such as pg_start_backup(), plpythonu, vacuum_defer_cleanup_age, adminpack and the checkpoint columns of pg_stat_bgwriter. Every finding names the version that removed it and the replacement to write instead.
Who is PostgreSQL 14 Upgrade Lint for?
Backend developers, DBAs and platform teams running Amazon Aurora PostgreSQL 14 or RDS for PostgreSQL 14 who must move to 16 or 17 before standard support ends on 28 February 2027. It also fits anyone upgrading a self-managed PostgreSQL 14 cluster who keeps backup scripts, monitoring queries and migrations in a Git repository.
Why not rely on pg_upgrade --check or a chatbot?
pg_upgrade --check and the Aurora pre-upgrade check read the catalog of the running cluster, not the .sql files, monitoring queries and ALTER SYSTEM scripts in your repository. A function body that calls pg_start_backup() still upgrades and then fails at run time. Chatbots trained on PostgreSQL 14 era examples still suggest the removed names.
What is free and what does the $29 licence add?
Free, with no key: lint the open .sql, .conf or .tf file in VS Code or paste it into the web page, and get every blocker with its line number and fix. The $29 one-time licence scans every migration in the workspace at once and exports one upgrade-blocker report as Markdown and CSV for the upgrade ticket.
What does staying on PostgreSQL 14 cost on AWS?
From 1 March 2027 AWS bills Extended Support for Aurora and RDS PostgreSQL 14 at $0.100 per vCPU-hour in US East (Ohio), rising to $0.200 from 1 March 2029. One 8-vCPU instance running 8,760 hours a year costs 8 x $0.100 x 8,760 = $7,008 a year on top of the instance price.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. PostgreSQL 14 Upgrade Lint (Aurora/RDS 2027) checks the file you open against 21 rules from a rule set dated 2026-09-27, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.