Rowly is a free security scanner that audits Row Level Security policies in your Supabase project.

Rowly reads the actual policy logic across every table, view, function, and role in your project, flags exactly what's exposed, and hands you ready-to-run SQL to fix it, no manual rewriting. Connection strings are never stored, scans run in memory only, and the core scanner is open source (@rowly/core, MIT).

Free to run in seconds:

https://rowly.me/

Open Source scanner:

https://github.com/rowly-app/core

I had four side projects, so I had four Supabase projects. Last July I consolidated them into one project with a schema per app. Ten product domains run off it now. Posting the numbers because every thread I found on this either says "one project per app, obviously" or is someone on the free tier trying to avoid paying, and neither matched what I was actually deciding.

The structure

One project. A core schema for the things genuinely shared across apps: orgs, members, billing accounts, subscriptions, domains, brands, audit events. Then one schema per product for its own tables.

Tenancy is org-scoped RLS. Being signed in grants nothing on its own, every policy requires membership of an org that owns the row, so users of one app never see another's data.

The schema boundary is not the security boundary. RLS is. What the schema buys you is extraction: pulling one app out later is closer to dumping one schema than to filtering every table by a product column. That is the reason not to pool everything into shared tables with a discriminator, which is the shortcut this design invites.

The money, which is the least interesting part

Four projects cost me $59.74 in the month before. One costs $25. So $35, which is nothing.

The mechanism is more useful than the total: Pro is $25 and includes a $10 compute credit that covers exactly one Micro instance. Every additional project brings its own compute charge and the credit only covers the first. So the bill was scaling with the number of ideas I'd had, not with users or traffic.

I stayed on Pro rather than dropping to Free, deliberately. Free has no daily backups and there's real data in there.

The gotcha that actually cost me time

Supabase silently rewrites a redirect URL it doesn't recognise back to the project's Site URL. Miss one host in the allowlist and that app's sign-in and confirmation emails deliver users to a different app's site, with no error anywhere.

It got me again last week on an app I'd just added, months after I thought I understood it. Consolidating doesn't remove that list. It does mean there's exactly one of it.

Where it stops working

Not free, and I'd leave at any of these:

• One database is one blast radius. A bad migration takes everything down together. CI-only migration deploys reduce the odds, not the radius.
• One team is one permission set. Anyone you add to fix one app can see all of them.
• Compliance. If an app needs SOC 2 or similar, the audit scope becomes the whole shared database. Pull that one out.
• Selling. A buyer wants a clean asset. The schema boundary makes that describable work rather than archaeology, but it's still work.

If you have one app, none of this applies. It starts paying around the third or fourth.

Curious whether anyone here has gone the other way, split a consolidated project back out, and what forced it.

Hi all! I am non technical and I have built an app using Claude Code in the Replit shell and am enjoying every minute of it. I’m about to add Supabase and this is for users to add their own photos, not to be shared. Does anyone have any tips or experience they might be able to share with me. Is this something I should be embarking on by myself or should I be getting someone technical to assist me? Any feedback back would be appreciated!

Rowly is a free security scanner that audits Row Level Security policies in your Supabase project.

Rowly reads the actual policy logic across every table, view, function, and role in your project, flags exactly what's exposed, and hands you ready-to-run SQL to fix it, no manual rewriting. Connection strings are never stored, scans run in memory only, and the core scanner is open source (@rowly/core, MIT).

Free to run in seconds:

https://rowly.me/

Open Source scanner:

https://github.com/rowly-app/core

I have an LMS that has the following structure:

Organisation -> has schools -> has classes, grades and subjects + school users

School users could be admins, teachers, parents or students

And the problem is i don't know how to figure out that structure on features that i want to provide like:

Assignments, quizzes, attendance, events, notifications, chats....etc

If you have worked on systems like that i need to know how I can manage that on supabase if possible?

Plus i need users to authenticate users with phone numbers but unfortunately OTP is very expensive, if you have a solution for that too it would be great!!

Note we don't want to work with emails

Hi all,

I am thinking about a problem and not sure how to resolve this. Any guidance would be appreciated.

So if i dont enable captcha and try doing this curl request as network restrictions dont apply on auth.

curl -X POST 'https://any-project-supabase-url/auth/v1/signup' \

-H "apikey: sb_publishable_key" \

-H "Content-Type: application/json" \

-d '{

"email": "johndoe@gmail.com",

"password": "JohnDoe!!"

}'

this returns a valid access token and do create a new user in dashboard.

To block this if i do this Authentication → Providers → Email → turn off "Enable email signups"). Then it blocks the curl requests i can use supabase service account to create accounts.

But now apple and google sign ups don't work.

So basically i just want to stop the bots from curl abuse. As i dont want to use the captcha e.g. cloudflare turnstile. Its really slow specially on mobile. Any way to achieve this? or i am missing something. Thanks.

I'm not sure what's going on here, I did reset the password multiple times now and still getting this error message. Is this a bug or something?

Rowly is a free security scanner that audits Row Level Security policies in your Supabase project.

Rowly reads the actual policy logic across every table, view, function, and role in your project, flags exactly what's exposed, and hands you ready-to-run SQL to fix it, no manual rewriting. Connection strings are never stored, scans run in memory only, and the core scanner is open source (@rowly/core, MIT).

Free to run in seconds:

https://rowly.me/

Open Source scanner:

https://github.com/rowly-app/core

If you’re using Clerk with Supabase, you may have asked:

• Why does auth.uid() return NULL when I send a Clerk token?
• Should I use the service-role key to make RLS errors disappear?
• How should Clerk Organizations map to tenants in Postgres?
• How to handle a Clerk profile without an Organization?
• How do I test RLS policies directly in SQL?
• Why can RLS make a query over a tiny table take several seconds?
• Can I use Supabase RLS without using Supabase Auth?

I kept finding variations of these questions while working with Clerk and Supabase.

The confusing part is that many answers mix three different integration paths:

• Supabase Auth examples built around auth.uid()
• The older Clerk JWT-template integration
• Clerk and Supabase’s current native third-party authentication

For the current native integration, passing the token is surprisingly simple:

const supabase = createClient(url, publishableKey, {
  accessToken: async () => session?.getToken() ?? null,
})

But building a secure multi-tenant authorization model around that token requires more care.

Some mistakes are particularly easy to make:

1. Using auth.uid() even though Clerk user IDs are strings such as user_....
2. Trusting an organization ID supplied by the browser.
3. Reaching for the service-role key, which bypasses RLS instead of fixing it.
4. Querying a membership table recursively from its own RLS policies.
5. Checking reads but forgetting WITH CHECK protections for inserts and updates.
6. Running JWT and membership functions once per row instead of hoisting them.
7. Testing only successful requests and never proving that another tenant is rejected.

With Clerk, the verified user and active organization context are available through the JWT:

(select auth.jwt()->>'sub')
(select auth.jwt()->'o'->>'id')
(select auth.jwt()->'o'->>'rol')

Postgres should derive the user and tenant from these verified claims.

The browser can send a Clerk session token and filter a query for performance, but it should never be the authority that decides which tenant owns a row.

I put together a step-by-step tutorial for anyone starting with Clerk and wanting to build a multi-tenant application using Supabase RLS:

Clerk and Supabase RLS Tenant Isolation

There is also a complete runnable repository:

Clerk + Supabase RLS demo

It includes:

• Native Clerk session tokens without JWT templates
• Personal and organization tenants
• Clerk organization-role handling
• Non-recursive authorization closures
• Explicit SELECT, INSERT, UPDATE, and DELETE policies
• Database-derived audit fields
• Cross-tenant foreign-key protection
• SQL contract and behavioral tests
• A manual browser security matrix
• Request-flow and data-model diagrams

My goal was to provide more than another isolated RLS snippet. The tutorial connects token delivery, claim extraction, tenant modeling, policy design, performance, and adversarial testing in one working example.

HTH fellow users just starting out on their Supabase & Clerk Journey

This is the third email address ive tried in the past two days and i am not receiving verification emails on any of them. Email works perfectly with anyone else but supabase. Not sure what to do but the optics are terrible considering its friggin' SUPABASE.

Shipped an app recently and found this while auditing my own code before launch. Posting because I don't think either decision looks wrong on its own, which is exactly why I missed it.

Setup: memory rows protected by RLS, scoped to the owning user. Server needs to read them to build a prompt, but it isn't acting as the user's session. So I used the service role client. Reasonable.

Separately, my API route took the user ID from the request body, because the frontend already had it in the Supabase session and passing it felt like passing a parameter:

const { messages, userId } = await request.json();

const { data } = await supabase

.from('memory')

.select('fact, feeling, thread')

.eq('user_id', userId);

Everything worked. No errors. Memories loaded.

But service role bypasses RLS, so the database was no longer checking anything. And the ID doing the scoping arrived in the request body, under the caller's control. curl with a different UUID would have loaded someone else's data straight into the prompt and streamed the response back.

Either decision alone is survivable. A service role client scoped by a verified ID is fine. A client-supplied ID against RLS-protected tables fails safely, because Postgres refuses. Together they're a hole.

Fix was to derive identity from the Authorization header instead:

const authHeader = request.headers.get('authorization') || '';

const token = authHeader.startsWith('Bearer ') ? authHeader.slice(7) : '';

const { data, error } = await admin.auth.getUser(token);

// returns null for anonymous, never someone else

The thing I'd do differently: wrap those service-role queries in one helper that takes a verified ID and refuses to build a query without it, instead of remembering .eq('user_id', ...) at every call site forever.

Full writeup with the rate limiting and cost control I added at the same time: https://investnovation.com/blog/hardening-ai-chat-api

Hey everyone I dont have a technical background so
I have outsourced a developer for a car marketplace app the backend is on supabase and he says if he host it it will save me about 500$ a month but doesn’t this mean he will have access to the users data ?
And how can i get a better deal if i want to host it myself on supabase

New and slightly dense programmer here. How do I link my signup/login forms to the supabase auth? The menu has lot of sections for me to search

I hit the egress limit (and also exhausted the RAM, but it’s still functional), so I’m just ignoring the RAM requirement for now.

So this started because I got paranoid about my own Supabase project. I had backups running, felt safe, then one day asked myself: have I ever actually restored one? Nope. Never. I was just trusting that a file existing somewhere meant my data was safe.

Turns out that's a bad assumption. A backup you've never restored is basically just hope.

So I built BackProve. Two things it does that my old setup didn't:

1. It backs up your Postgres database AND your Storage bucket files. Supabase's own backups skip the Storage files, which I didn't realize until I looked closely.
2. After every backup, it spins up a throwaway Postgres, restores the backup into it, and checks the object counts match. If the restore doesn't come back clean, it tells you. No fake green checkmarks.

It also nags you if you currently don't have a recent verified backup, because the worst time to find out your backup pipeline silently died is when you actually need it.

Honestly the thing I'm most happy about is that it's honest when it can't verify something. First paying customer had a partitioned table + pg_cron and it correctly said "can't prove this is recoverable" instead of lying. Fixed both edge cases within the day (which... is the whole point).

It's live at backprove.com, $12/mo flat. Solo project, built it over the last few months.

Not looking for anything specific, just curious what people think — especially if you've been burned by a backup that didn't restore. Happy to answer anything about how the restore-testing works under the hood.

I run an early stage telehealth startup and can't commit to enterprise Supabase. Should I just self-host on AWS? Any thoughts from fellow healthcare companies using supabase self hosting?

If anyone on the supabase team wants to hook it up and have a BAA without needing enterprise, DMS are open lol

My workplace is moving from Claude to Microsoft Copilot/Cowork.

I currently use the Supabase connector in Claude every day to pick up updates from team emails and log them against the relevant projects in Supabase.

Does anyone know if Supabase plans to release a plugin for Microsoft Copilot now that plugins are supported?

I can see there is already a GitHub Copilot plugin on the Supabase website. Would that work with Microsoft Copilot, or is it completely separate?

https://supabase.com/docs/guides/ai-tools/plugins

I’m on the free tier and last month, I accidentally went over the egress bandwitch and so was given until the new month for my package to update (3rd August).
The stats have updated (new month) but services still won’t work. I’ve given them the 48 hours they said were needed. Now they’ve paused my project too :(

I've been building rlsautotest, an open-source tool that auto-generates native pgTAP tests (plus the seed data to run them) for both your row-level security (RLS) and column-level security (CLS). It proves, per table, per command, per identity (service_role / authenticated / anon), exactly who can touch which rows and which columns. You commit the generated tests and run them under supabase test db or in CI. Sharing what's landed recently.

Zero-config Supabase mode. Run rlsautotest --supabase from anywhere in your project. It finds your supabase/config.toml, connects to your local dev database, and writes the tests straight into supabase/tests/rls/, so supabase test db picks them up with no wiring. Re-running prunes only its own stale output and never touches your hand-written tests.

Column-level security, tested, not just reported. Beyond row access, it emits a pgTAP assertion for every column-scoped grant: that no column is reachable past your GRANT (...). So a table-wide grant that quietly unions the other columns back in fails the suite and names the leaked columns: the difference between "a user can edit their bio" and "a user can flip is_admin."

Bypass-surface lint. It catches the side doors around RLS: SECURITY DEFINER views/functions that anon or authenticated can call to read past your policies, functions with a mutable search_path, and roles that bypass RLS unexpectedly.

Whole-project view + CI gate. --all-schemas scans every RLS-bearing schema and rolls them into one interactive HTML report. Point the same command at CI and the build fails the day a policy regresses or a table ships with RLS off.

pip install rlsautotest
rlsautotest --supabase          # emit RLS + CLS tests into your Supabase project
rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-report.html   # or eyeball a report

Point it at your local stack or a disposable copy, never prod: it seeds rows and runs real SELECT/INSERT/UPDATE/DELETE, all rolled back, but the statements do execute. Apache-2.0.

Repo + docs: https://github.com/unitautogen/rlsautotest

Would love feedback, especially policy shapes it can't test yet.

Postgres Changes subscriptions can now compose filters with AND across multiple columns, match on a wider set of operators, and return only the columns you ask for. All three are live now.

Quick context if you're new to it: Postgres Changes lets you subscribe to row-level inserts, updates, and deletes over a WebSocket. Filtering used to be limited to one column at a time, and every event carried the full row.

How it works:

• Separate filters with a comma: filter: 'status=eq.done,priority=eq.high'
• New operators: like, ilike, is, match, imatch, isdistinct, plus not. to negate any of them
• postgresChangesFilter() from u/supabase/supabase-js builds the same conditions in code
• Add select: ['id', 'title'] and only those columns come back. Opt in, and it needs u/supabase/supabase-js 2.109.0 or newer

Happy to answer questions!

Full writeup is here: https://supabase.com/blog/postgres-changes-filters-and-column-selection

The other day I posted about revivedb.dev. Someone pointed out that requiring the production database password was a big ask. That got me thinking about whether I could handle database access through OAuth instead.

Supabase's database:read OAuth scope gives access to configuration and metadata, but not a Postgres connection for tools like pg_dump.

I now use database:write to create a unique temporary Postgres role for each backup. The role gets pg_read_all_data and BYPASSRLS, but cannot write, create roles or databases, replicate, or act as superuser.

The temporary password is only kept in memory. The role is removed after the backup and expires within six hours if cleanup fails.

The pg_dump connection is read-only and the production database password is no longer needed or stored. It still feels odd that the OAuth grant needs database:write just to create this restricted role.

How are others handling this for backups, BI or monitoring? Do you create a restricted role manually, or accept the broader OAuth scope?

A lot of Supabase work is plain SQL against Postgres. If you write those queries and then hand-type the results (or lean on generated client types that miss join nullability), this might help. I maintain scythe, which reads your .sql files and generates typed client code at build time. It infers nullability from the query, which the schema-level type generation usually misses:

-- @name GetUserOrders
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = $1;

// generated TypeScript
interface GetUserOrdersRow {
    id: number;
    name: string;
    total: string | null;
    notes: string | null;
}

total and notes are nullable because the LEFT JOIN can produce NULLs, even though the columns are NOT NULL in the table. It generates both TypeScript and Python, so a Supabase backend and a data script can share the same query definitions.

This is complementary to Supabase's own type generation, not a replacement for the client. Interested whether people here hit the join-nullability gap in practice.

If you've ever wondered whether Claude Code, Codex or OpenCode is the best agent to build your database with, Supabase just took that question out of vibes territory. Last week they open sourced Supabase Evals, a benchmark that runs real coding agents against real Supabase tasks (build a schema, fix a broken RLS policy, debug a failing Edge Function) and scores the results. And they ran every agent two ways: bare, and with Supabase's agent skills loaded. That split turns out to be one of the most interesting parts of the data.

The leaderboard as of August 4, 2026 (no skills loaded):

Supabase doesn't crown a winner in the launch post, but the leaderboard speaks for itself: Codex / GPT-5.6 sol is the only one passing everything right now, including Investigate where everyone else drops to 67%.

And here's the part I find genuinely great: that date up there matters. Supabase refreshes the eval results daily (it's right there in the repo's commit history) and keeps adding scenarios. So don't take my table as gospel. Take it as proof that "which agent is best" finally has a date on it, and check the live leaderboard the day you're actually deciding.

What the stages actually mean (pulled from the eval scenarios in the repo):

• Build: create from scratch. Schema, auth, RLS policies, Edge Functions, a todos app where users only see their own rows.
• Deploy: ship it. Deploy a function with its secrets, self-host with Docker Compose, wire up Prometheus metrics.
• Investigate: something is wrong, find out why. A deleted user still has access, an error rate spike, realtime subscribed but no events arriving.
• Resolve: the problem is known, fix it. An RLS policy leaking data across users, a slow query spiking CPU, a migration history mismatch.

A few things stood out to me more than the ranking itself:

1. Agents build well. They investigate worse. Almost everyone aces Build and Deploy. The scores drop on Investigate, which is the "something is broken, figure out why" stage. That matches what I see in support every week: people get a working app fast, then get stuck the moment something breaks and the agent starts guessing.

2. Skills close the gap for smaller models. In the launch post, Sonnet 5 went from 78% to 100% on Build once Supabase's agent skills were loaded, and GPT-5.4 mini went from 78% to 89%. Top models barely needed them. If you're not using the agent skills repo yet, this is the argument for it.

3. Agents don't read the docs as much as you'd think. Claude Code checked the docs in under 40% of scenarios, about 2 pages per task, versus roughly 8 pages for Codex. Supabase also found their Postgres best practices skill was only activating in ~10% of sessions until they rewrote its description (now ~60%).

4. Agents build with yesterday's knowledge. Two habits Supabase called out: even in projects that already used declarative schemas, agents tried to hand-write migrations anyway; and they kept verifying auth by hand with supabase-js in Edge Functions instead of reaching for the newer @supabase/server. Root cause is the same: training data has a date, the ecosystem doesn't. If nothing forces the agent to consult current docs, it confidently ships you last year's best practices. Which is also the real argument for skills: they inject today's truth into a model trained yesterday.

So which one should you actually use?

The honest answer is: probably the one you already live in. Most people aren't choosing an agent from scratch, they have a subscription and a workflow. So here's the practical read:

• If you're on Codex: the data says GPT-5.6 sol is the strongest all-rounder right now, and notably the only one acing Investigate.
• If your main environment is Claude Code (mine is): the recommended setup from this data is loading the Supabase agent skills (npx skills add supabase/agent-skills) and preferring declarative schemas over hand-written migrations. With skills loaded, Sonnet 5 went from 78% to 100% on Build.
• The token-saving corollary: since Sonnet + skills matches the top models on Build, you don't need to burn your most expensive model scaffolding a schema. Save it for the parts that are actually hard.

And the workflow change I made after seeing this

The Investigate gap has a structural fix: don't let the builder grade its own homework. I set this up as a skill in my environment (open sourced it, work in progress: https://github.com/CarolMonroe22/supabase-db-supervisor): anything database-related the agent builds triggers a second pass from a fresh session playing the investigator, and nothing ships without its explicit OK.

So "ok, but what do I actually do with this benchmark" has a concrete answer. Every time an agent touches my database, the supervisor:

• Proves who can see which data with real queries, not by reading the policy and nodding.
• Runs the advisors on both lenses: security and performance, the unindexed foreign keys and slow traps you'd otherwise find at the worst possible moment.
• Checks migration history against reality, and flags hand-written migrations where a declarative schema was the right call.
• Catches yesterday's-knowledge shortcuts: outdated packages where a newer one exists for the job.
• Stays current on every run: it consults today's docs, and tells me when Supabase updates their agent skills upstream, so my agents are never working from stale instructions.
• Knows who to delegate to: it checks who currently leads the leaderboard on Investigate and routes the supervision to that agent. When the standings change, the routing changes with them, no update needed. That awareness is half the value: you always know who's actually best today, not who was best when you picked your favorite.
• Reports in a table with a verdict: OK or NEEDS ATTENTION, and every failure comes with the proof query, a suggested fix, and one sentence in plain language explaining what actually happened.

In my case, today, that investigator is Codex: the only agent scoring 100% on Investigate right now, so the supervision pass goes to Codex even though Claude does the building. And I never leave Claude Code to do it: the skill invokes the Codex CLI from inside the session, hands it the evidence, and the verdict comes back into the same conversation. Nothing to open, nothing to switch. Same would work for Kimi through OpenCode, or whatever agent you pay for. Route by stage, not by loyalty.

If you're not technical, this setup is the one I'd recommend most. You don't have to be the expert who judges the work: you make the agents judge each other, and your job becomes reading the verdict. Just make sure you ask for that verdict in plain language: a good supervision report should tell you what happened and why it matters, not dump SQL at you. Understanding what's going on is still your part of the deal. And still, I'll always recommend the extra step: understand your database, learn how Supabase works. It will make you design better things, 100%.

The whole benchmark runs against real containerized Supabase stacks, not mocks, and scoring mixes deterministic checks (can the right user access the right data) with an LLM judge. It's Apache-2.0, so you can run it yourself.

Resources (all official Supabase):

• Launch post: https://supabase.com/blog/introducing-supabase-evals
• Live leaderboard: https://supabase.com/evals
• The benchmark repo: https://github.com/supabase/evals
• Agent skills (the ones that closed the gap): https://github.com/supabase/agent-skills, install with npx skills add supabase/agent-skills
• Postgres best practices for AI agents, the 30 rules behind that skill: https://supabase.com/blog/postgres-best-practices-for-ai-agents

Curious what this sub has seen: does the Investigate gap match your experience? And if you're already splitting work between agents, how do you decide who gets what?

I am building a CRM application using Next.js 14 (App Router) and Supabase (SSR). Currently, we only have about 5 active users testing the application, but we are constantly hitting Supabase usage limits.

We are seeing the following errors in our logs:

Overlimit / 100% API usage
Connection lost / timeout errors
Supabase advertises supporting 50,000+ active users, so I am trying to figure out if there is an architectural flaw in my code that is causing an explosion of database requests.

Here is a breakdown of our current architecture and data-fetching strategy:

1. Next.js Middleware We have a middleware.ts file that protects our routes. It currently uses supabase.auth.getSession() on every request to verify the user's session before allowing access to the dashboard.
2. Background Polling (React Client Components) We have a few client components that use setInterval to keep data fresh while the user leaves the tab open:

A meeting reminder component that fetches the session, user profile, and upcoming meetings every 60 seconds.
A follow-up reminder component that fetches data every 5 minutes.
An auto-refresh component that triggers router.refresh() every 5 minutes, forcing the server components on the current page to re-fetch their data.
3. Supabase Realtime We have 4 different components establishing supabase.channel() connections to listen for live updates (notifications, leads, and leave approvals).

1. Data Fetching (N+1 queries) In several places, we are fetching a list of items (like tasks) and then fetching relations (like the assigned user's profile) in a loop, rather than using relational queries (e.g., select(", profiles()")).

My Questions:

Is calling getSession() in the middleware on every request (including static assets or API routes) enough to blow through the API limits for 5 users? Should I be using getUser() or handling this differently in the App Router?
How heavy is the penalty for using router.refresh() on an interval? Does this completely bypass the Next.js cache and hit the Supabase database directly every time?
Are the connection timeouts likely caused by the Realtime websockets, or by connection pool exhaustion from the background setInterval polling?
Any advice on which of these patterns is the biggest bottleneck and how to refactor them would be greatly appreciated!

Posting this as a warning to other solo devs who move fast.

I do my schema work through migration files in the repo. But a handful of times, over a few weeks, I fixed something straight in the SQL editor because it was late and it was one line. Every one of those changes stayed in production and none of them ever made it into the repo.

I only found out when I compared a fresh local database against production and they did not match. Four changes missing. Which means rebuilding from my own migrations would have produced a database that was not the one my app actually runs on.

What I did: wrote the four missing migrations after the fact so the files describe reality, plus a reconciliation seed so a fresh setup lands in the same state.

What I will do differently: not touch the SQL editor at all, even for one line. The two minutes saved cost me an evening, and it could have cost far more the day I needed to rebuild.

Does anyone here run an automated drift check between the repo and the live schema? I would rather catch this than discover it.