Adding a schema diff tool

[vadim2404]

The new tool to generate schema diff for a specific branch has been added. It also suggests generating a zero-downtime migration and executing it on the parent branch if the user gives consent.

Here is the example

# Generate schema diff for branch _Exported on 10/8/2025 at 14:53:39 GMT+2 from Cursor (1.7.39)_

---

User

can you generate a schema diff for the branch br-holy-surf-admmhx6e in project winter-cake-15657477

---

Cursor

I'll generate a schema diff for that branch. Let me compare its schema with its parent branch.

Perfect! I've generated the schema diff for branch br-holy-surf-admmhx6e in project winter-cake-15657477. Here's what changed compared to its parent branch:

Schema Changes

Tables Modified

• public.users: Added 3 new columns
  • is_deleted - boolean field with default value false (NOT NULL)
  • created_at - timestamp with timezone, defaults to current time (NOT NULL)
  • updated_at - timestamp with timezone (nullable)

Indexes Added

• users_created_at_idx: A B-tree index on the users table
  • Indexes created_at in descending order
  • Partial index with condition WHERE (is_deleted = false) for better performance

---

The diff represents the changes that would need to be applied to the parent branch to match this child branch's schema. This looks like a typical soft-delete pattern implementation with audit timestamps and an optimized index for querying non-deleted users by creation time.

Would you like me to help you:

1. Generate a zero-downtime migration to apply these changes to the parent branch?
2. Analyze the impact of these changes?
3. Something else?

---

User

let's go

---

Cursor

Great! I'll generate a zero-downtime migration to apply these changes to the parent branch. Let me create SQL statements that are safe to run without blocking your database.

Proposed Migration Strategy

Based on the schema diff, here's the zero-downtime migration plan:

Step 1: Add is_deleted column (safe - no table rewrite)

ALTER TABLE users ADD COLUMN IF NOT EXISTS is_deleted boolean DEFAULT false NOT NULL;

Step 2: Add created_at column (zero-downtime approach)

-- Add column without default first (fast, no rewrite)
ALTER TABLE users ADD COLUMN IF NOT EXISTS created_at timestamp with time zone;

-- Backfill existing rows
UPDATE users SET created_at = now() WHERE created_at IS NULL;

-- Now set NOT NULL constraint
ALTER TABLE users ALTER COLUMN created_at SET NOT NULL;

-- Finally, set the default for future inserts
ALTER TABLE users ALTER COLUMN created_at SET DEFAULT now();

Step 3: Add updated_at column (safe - nullable, no default)

ALTER TABLE users ADD COLUMN IF NOT EXISTS updated_at timestamp with time zone;

Step 4: Create index concurrently (zero-downtime)

CREATE INDEX CONCURRENTLY IF NOT EXISTS users_created_at_idx ON public.users USING btree (created_at DESC) WHERE (is_deleted = false);

---

Impact Summary:

• ✅ No table rewrites
• ✅ Minimal lock time
• ✅ Index created without blocking writes
• ⚠️ The UPDATE statement in Step 2 may take time on large tables but won't block reads/writes

Would you like me to execute this migration on the parent branch now? I'll run each statement and show you the results. Type "yes" to proceed or let me know if you'd like any adjustments.

ALTER TABLE users ADD COLUMN IF NOT EXISTS is_deleted boolean DEFAULT false NOT NULL;

-- Add column without default first (fast, no rewrite)
ALTER TABLE users ADD COLUMN IF NOT EXISTS created_at timestamp with time zone;

-- Backfill existing rows
UPDATE users SET created_at = now() WHERE created_at IS NULL;

-- Now set NOT NULL constraint
ALTER TABLE users ALTER COLUMN created_at SET NOT NULL;

-- Finally, set the default for future inserts
ALTER TABLE users ALTER COLUMN created_at SET DEFAULT now();

ALTER TABLE users ADD COLUMN IF NOT EXISTS updated_at timestamp with time zone;

CREATE INDEX CONCURRENTLY IF NOT EXISTS users_created_at_idx ON public.users USING btree (created_at DESC) WHERE (is_deleted = false);

---

User

yes

---

Cursor

Perfect! I'll execute the migration step by step on the parent branch. Let me start:

✅ Step 1 Complete: Added is_deleted column

✅ Step 2a Complete: Added created_at column (nullable, no default)

✅ Step 2b Complete: Backfilled existing rows with current timestamp

✅ Step 2c Complete: Set NOT NULL constraint on created_at

✅ Step 2d Complete: Set default value for created_at

✅ Step 3 Complete: Added updated_at column

✅ Step 4 Complete: Created index users_created_at_idx concurrently

---

🎉 Migration Complete!

All schema changes have been successfully applied to the parent branch. Let me verify that the schemas now match:

✅ Verification Complete: The schema diff is now empty, confirming that the parent branch schema now matches the child branch br-holy-surf-admmhx6e.

Summary of Changes Applied:

1. ✅ Added is_deleted column (boolean, default: false, NOT NULL)
2. ✅ Added created_at column (timestamptz, default: now(), NOT NULL)
3. ✅ Added updated_at column (timestamptz, nullable)
4. ✅ Created partial index users_created_at_idx for efficient queries on non-deleted users

All changes were applied with zero-downtime - no table locks, no blocking operations, and the index was created concurrently. Your database is now fully updated! 🚀

[orca-security-us]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[Shridhad]

We might need to check how this instruction will behave with Cursor "Auth-Run" or Claude's "Auto-Approve" mode. These modes do not need user's approval every command/tool to execute.

This tool itself is safe to execute, but if LLM runs the migration following instruction, if can be destructive.