I tried it out and it worked really well for us – awesome tool! The spec-driven approach is a bit different then the usual back-and-forth with agents, and if you invest properly in writing specs it pays of.

From an investors point it's very unattractive to invest in a early-stage startup where half of the shares are in the hands of a person not working there anymore.

We found that for extracting tables, OpenAIs LLMs aren't great. What is working well for us is Docling (https://github.com/DS4SD/docling/)

Haven't seen Docling before, it looks great! Thanks for sharing.

agreed, extracting tables in pdfs using any of the available openAI models has been a waste of prompting time here too.

About the "as complex as you need": RLS can get slow very quickly for aggregate queries, and is hard to debug (since query planner doesn't work smoothly with RLS).

We have a dashboard that displays aggregated stats for our admin users, and we hit serious performance issues with ~600 users with our first implementation. This repo helped us: https://github.com/GaryAustin1/RLS-Performance

Thank you, that was really helpful and actionable: ex. I had stopped writing filters on queries recently if my RLS had it "built-in", easy to see now it's better for performance, and since it's better for safety anyway, why not do it?

Some additional feedback: In my opinion testing RLS is a problem.

Additionally, I find it hard to keep a good overview over the rules. E.g., in a multi-tenant application one needs to secure every table with a restrictive rule, and it's easy to make a rule permissive, since that is the default & it's not indicated in the Studio UI.

When generating migrations with 'supabase db diff' views are being recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before, leaving your database exposed. Easy to miss, even when you're aware of that.

RLS is just so full of footguns that I find it hard to justify using it in a production system.

(But otherwise I love Supabase! Great job.)

we have a lot of work to do for migrations and testing, especially RLS.

for this Launch Week we focused on generating policies (more on that in tomorrows launch week). This is hard for a lot of our audience who aren't familiar with SQL.

In the next few months we'll work on simulating a policy - being able to choose a specific user and see what data would be returned for that user.

We also have `supabase test db`, in case you missed it. It wraps pgTAP and pgProve so that you can write database tests.

> recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before

we use migra for diff'ing. Thanks for raising this - we'll file a bug report asap.

Great, thank you for the reply! The simulation a policy sounds exciting. Looking forward to the news.

follow up on the "security invoker" - we've filed a bug report here which you can follow: https://github.com/djrobstep/schemainspect/issues/86

Great news! Question to the Supabase team: How does Login with Azure (Social login) and SSO (Azure) differ? From my superficial understanding, implementing Login with Azure is enough for logging-in users with Azure AD accounts (and linking their accounts to existing ones).

Would that not be a huge security risk? You could access the SSO credentials of your users that way.

I found this explanation very helpful: https://hakibenita.com/python-dependency-injection (if you program in Python)

Great job! What are the implications on resizing regarding storage egress & download size? Can I expect both to be smaller when resizing an image?

Yes! If you resize your images correctly, your users use lesser data to load assets from Storage. A side benefit is you will be paying us lesser in egress fees.

Actually, that is perfectly normal in many tax systems, e.g. in Germany. Afaik the tax law doesn't care where the money comes from – it could be from a completely illegal activity, and you still own taxes on gains.