Today we're releasing Safegres, an open-source tool that checks who can reach which rows in a Postgres database and catches security mistakes before they ship.
We built it because the way software gets made has changed. Agents and AI app builders now create databases, write the rules that protect them, and ship changes faster than any person can review. One missed setting can be copied into thousands of apps.
Two locks on every table
Postgres protects data with two locks. Grants decide whether someone can open a table at all. Row-level security (RLS) decides which rows inside it they can see, so a customer sees their own orders and nobody else's. Both have to be right. Leave either one open and private data can end up in front of strangers.
This keeps happening. Researchers have found tens of thousands of AI-built apps whose databases hand records to anyone who asks. These aren't clever attacks. They're misconfigurations, and misconfigurations can be checked automatically.
What Safegres does
Safegres connects to your database read-only and reports what each role can actually reach. It never changes anything.
- Two scores. 34 security checks and 11 performance checks, graded separately.
- Real access, not just settings. It follows permissions through roles, defaults, views and functions.
- Same answer every time. No AI judge. The same database always gets the same grade.
- Works with your stack. Ready-made settings for Supabase, PostgREST, Hasura, Graphile and Constructive, and it works on any Postgres.
Most importantly, it runs in CI. Every pull request gets checked, and Safegres flags only what that change introduces. Security stops depending on someone remembering to run an audit. And when coding agents can see the results, they tend to fix the findings on their own.
We ran it on ourselves first
Safegres has guarded our own platform since this summer. It joined our CI in late July, and since August 1 it has blocked any pull request that would lower our security or performance scores.
- The first audit found 2,053 problems, mostly missing indexes behind security rules, which make secure queries slow. About ten root-cause commits later, more than 2,700 individual findings are fixed and the accepted list is down 78%.
- One bug, a thousand findings. A single mistake in the code that writes our security rules made every rule re-check the user on every row. Fixing that one generator took that type of finding from 1,011 to 6.
- It caught more than slow queries. Some findings were the kind an audit grades critical. We fixed them, and tightened the defaults so new functions and tables start with higher scores.
Once the checks gate CI, the scores can only move in one direction. A change that would lower them never merges, so every fix raises the floor, and nothing slides back. Since August, most mistakes have been caught and fixed before they ever reached our history.
Built on nearly a decade of work
Safegres sits on top of our open-source Postgres parser, which turns SQL into something programs can read and check exactly as the database will run it. That parser is downloaded more than 9 million times a month, and across all of our open-source npm packages we have passed 275 million downloads.
It's also one piece of a larger toolkit: pgpm organizes Postgres code into packages, pgsql-test runs tests against a real database, and Safegres checks every change. Together they cover the whole development loop, as described on PostgreSQL.org.
Review the app, then review the data
Vercel just launched Security Review, which checks your application code on every push. We're glad to see it. But your data doesn't live in your app code. It lives in the database, and that's where the locks are. Review the code, then let Safegres review the data.
Safegres is open source under the MIT license. Learn more on the Safegres page, or find it on GitHub.
The fastest start is one line. Give your coding agent the Safegres skill and ask it to audit your database: