pyramation

Hey HN, Dan here, founder of Constructive.

Been building open-source Postgres tools for a decade now, and one things keeps popping up... it's way too easy to build insecure databases.

We built safegres to address this (and more to come) — it's an open-source, read-only Postgres auditor that inspects the system catalogs and uses PostgreSQL's own grammar to analyze policies and functions as ASTs rather than relying on regex.

It gives you two independent grades: security and performance. It also runs in CI, so you can improve your development loop. We found that agents that can see your CI will just pick this up and start improving your code w/o too much instruction.

I'd love feedback from anyone who's worked with complex RLS policies, multi-tenant Postgres, or agent-generated schemas. Especially interested in edge cases we're missing or places where our analysis might be wrong.

Thanks for taking a look!

thanks for sharing! author of pgpm here, we are super excited about pushing e2e and integration testing in the postgres community, a big part of the modular postgres workflows in addition to the modules/packages.

We'll be continuing to improve and work on the developer experience for postgres and building applications, thanks again!

thank you! let us know if you need help setting it up!

appreciate it! let us know if you and your team have any feedback, cheers!!!

thank you! much appreciated ;) hope it helps you guys ship secure supabase projects!

thank you! Appreciate that.

Always want to make the glide path and ensure folks can run the software replicably on their machines!

happy to help if you run into any issues :)

and fwiw, my opinion comes from attempting to upgrade packages that I've depended on that all of a sudden add the module: true, which essentially requires that ALL packages must upgrade — which is 99% of the time not possible because all the other deps are usually CJS.

this is also similar to the non-incremental way TS rolled out in the early days, also causing knee-jerk reactions to TypeScript. However over time, devs found ways to incrementally type JS to TS, and so we've all mostly evolved by now.

If ESM could do similar, allowing for incremental evolution, then it would solve all of the problems. I don't see why cjs and esm cannot co-exist

ES modules are cancer. I'm fine w the syntax — in fact, I love the syntax.

But if you use "module: true" in your package.json, you are splitting the npm ecosystem into two groups, and it's not moving us forward.

An article about ASTs in postgres, featuring a postgres AST deparser written in pure pgsql