Branching, Commits, and Pull Requests — For Your Database Schema

Version control transformed software engineering. Before Git, coordinating code changes across a team meant emailing patches, maintaining "final_v2_ FINAL" folders, and praying nobody overwrote your work. Database schemas never got that same upgrade — until now.

Why databases need version control

Your application code lives in Git. Your infrastructure is defined in Terraform. Your API contracts are versioned in OpenAPI specs. But your database schema? It's either a migration folder that only tells you how the schema changed (not why), or an ORM file that shows the current state with no history at all.

This gap creates real problems. A developer renames a column on their local branch. Another developer adds a foreign key to that same column on a different branch. Neither knows about the other's change until migrations collide in CI — or worse, in production.

How draft auto-save works under the hood

One of our design principles is zero data loss. In Git mode, every edit you make on the canvas is auto-saved to a draft within two seconds. But we go further: if you close your browser tab or navigate away, a beforeunload handler fires a beacon request to persist your latest changes. When you come back, your draft is exactly where you left it.

// Auto-save: writes to draftSchema JSON field
async function saveDraft(branchId, schemaData) {
  await prisma.branch.update({
    where: { id: branchId },
    data: { draftSchema: schemaData },
  });
}

// Commit: promotes draft to permanent storage
async function commitChanges(branchId, message) {
  const branch = await prisma.branch.findUnique({
    where: { id: branchId },
  });

  await prisma.$transaction([
    // Write draft to actual schema tables
    ...buildSchemaWriteOps(branch.draftSchema),
    // Create immutable commit snapshot
    prisma.commit.create({
      data: {
        branchId,
        message,
        schemaSnapshot: branch.draftSchema,
      },
    }),
    // Clear the draft
    prisma.branch.update({
      where: { id: branchId },
      data: { draftSchema: null },
    }),
  ]);
}

Conflict detection that actually works

When you open a pull request, PicaDeck compares the source and target branches at the entity level. We don't just check "did both branches touch this file" — we check whether the same table, column, relationship, or enum type was modified in both branches.

If a conflict is detected, the merge is blocked until it's resolved. You get three resolution strategies: accept the source branch's version, keep the target branch's version, or manually resolve each conflict individually.

"The conflict detection caught a breaking change that would have slipped through our migration workflow. Two engineers had modified the same foreign key constraint on different branches — PicaDeck flagged it before the merge."

Safe rollbacks with revert

Mistakes happen. A merged pull request introduced a problematic schema change, or a commit needs to be undone. PicaDeck supports reverting both individual commits and entire pull requests. Because every commit stores a full schema snapshot, reverting doesn't involve computing an inverse diff — it restores the exact previous state, atomically, in a single transaction.

Free tier vs. Git mode

Not every project needs full version control. PicaDeck's free tier uses a direct auto-save mode: changes write straight to the database tables with no draft layer. It's simple and instant. When you're ready for branching, commits, and pull requests, upgrading to a paid plan enables Git mode with a single toggle.

We designed this as a progressive upgrade path. Start fast, add rigor when your team and schema grow.