Scion

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Our code goes through pull requests, previews, and review. Our database never did. The moment a pull request adds a column or drops a table, there is nowhere safe to run it against data that looks like production, so people test against a tiny seed, a shared staging that three branches are mutating at once, or production itself. The teams that feel this most run a production Postgres on Aurora and ship on Vercel: the frontend gets a clean preview for every branch and the database gets nothing. Scion gives the database the same thing, a real isolated preview per branch, and makes creating one feel as ordinary as a git branch.

What it does

Scion is a control plane for teams that run a production database on Amazon Aurora and deploy on Vercel. It connects to your Aurora cluster and gives every pull request its own isolated branch of it.

Production sits at the root, and a branch grows for every change. You can see how many branches are live, how much of the clone lineage is used, and what they cost.

Creating one is a single action: name it, add an optional migration, and click.

Scion clones your production cluster, anonymizes the personal data on the clone, and applies the migration. The branch has the shape and volume of production with every customer replaced by a stable pseudonym, and because the masking is deterministic and foreign key safe, joins still work.

Each branch has a live timeline, a connection string, and a lease that prunes it on its own when it expires.

When a branch carries a migration, Scion opens a deploy request with the real difference between the branch and production, column by column.

If the change drops data, it names what it deletes and counts the rows at risk on production before anyone approves. You apply it on merge, or roll it back.

Every branch is a real Amazon Aurora cluster, a copy-on-write clone that shares storage with production until something writes to it, so it costs almost nothing no matter how large production is.

The app that gets branched is a normal Next.js storefront that reads its database from an environment variable. On production it shows real customer data.

Scion wires the branch into a Vercel preview, so the same app runs against the isolated branch with the data anonymized, and the new Loyalty column the pull request added shows up while production does not have it.

The preview is a real Vercel deployment wired to its branch database, while production stays on main.

Scion connects directly to your own Aurora database. It also has a simulated mode, so you can try the whole flow and evaluate the app without provisioning real clusters.

Why Amazon Aurora

Scion is built on Aurora's copy-on-write cloning, the one capability that makes the whole product possible. A clone is a full, production sized PostgreSQL database that shares storage with production until something writes to it, so it pays only for the pages a branch changes and costs almost nothing no matter how large production is. That is what lets us give a real branch to every pull request instead of saving it for special occasions.

Aurora Serverless v2 carries the rest. Each branch scales its compute to zero when it is idle, so a whole fleet of short lived previews stays cheap, and because every branch is full Postgres it behaves exactly like production, with the same schema, the same queries, and the same data shapes, ready to connect to, mutate, and throw away. Scion runs its own control plane on Aurora PostgreSQL too, so the database is not a backend the product talks to. It is the product.

Why it is a monetizable B2B product

Scion sells to engineering teams that run a production database on Aurora and ship on Vercel, which is a concrete buyer: the platform or backend team that owns the database. The value lands on the first branch, and the cost maps cleanly to usage, because every branch is a real, short lived Aurora clone with a measurable lifetime. The natural pricing is per active branch hour, with seat based tiers for review and governance, the same shape as the preview and database tooling these teams already pay for. It is horizontal developer infrastructure with an obvious place in a stack that already has code review and frontend previews, but nothing for the database.

How we built it

Scion is one Next.js app that is both the dashboard and the control plane, on Vercel, with its own state in an Aurora PostgreSQL database modeled in Drizzle. A project is one production database, a golden is the cluster branches clone from, a branch tracks its clone, lease, and migration, a deploy request holds the diff and the up and down SQL, and a masking policy says which columns are personal data.

Provisioning real infrastructure is work that does not belong in a single request, so we built it as a resumable, idempotent state machine over a durable queue. Each run advances a branch as far as it can, issuing the clone, bringing up the instance, masking, migrating, and opening the deploy request, and the same flow runs whether it is triggered from the dashboard, a Vercel cron, or a GitHub webhook.

The diff is a real introspection of information_schema on both the clone and production, and the rows at risk are counted on production. Masking runs as deterministic, foreign key safe SQL on the clone. The clone is created with RestoreDBClusterToPointInTime using copy-on-write, on db.serverless with a minimum capacity of zero. The Vercel injection is preview scoped and keyed to the git branch, so it never touches production or development.

Challenges we ran into

Making provisioning reliable was the core engineering problem. Creating and tearing down real database infrastructure has to survive partial failures and the limits of a serverless platform, so we modeled the whole flow as an idempotent state machine over a durable queue, which made it safe to retry and easy to drive from a webhook, a cron, or the dashboard. Privacy had to be a property of the system rather than a feature, so masking is deterministic, foreign key safe, and runs only on the clone, and production is never modified by it. And Aurora allows fifteen clones per lineage, so we track depth per golden and roll a fresh root before it fills, which keeps that ceiling from ever becoming a wall.

Accomplishments that we are proud of

The whole path works against a live Aurora cluster: a branch is a copy-on-write clone, masking is real SQL on it, the diff is a real introspection, and approving a deploy request runs the DDL on production with a conflict check and a recompute that catches drift. The provisioning state machine, the lineage accounting, the lease cleanup, and the masking policy are wired end to end. And the product has a clear point of view: production at the root, branches growing from it, and a deploy request that reads like a pull request for your schema.

What we learned

Aurora copy-on-write cloning is not a detail the product uses, it is the product. It is the one thing that makes branching a production sized database affordable enough to do every time, and the rest of Scion turns that into a workflow a team can adopt. We also learned how much of a serverless data product is about working with the platform rather than against it: an idempotent worker over a queue gave us reliability that a single long call never could.

What's next for Scion

Automatic golden rotation so the fifteen clone ceiling never becomes a wall. Deeper GitHub integration so the deploy request and the branch connection show up on the pull request. Roles and required approvals on destructive changes. More than one production database per workspace. And usage based billing on active branch hours.

Built with

Next.js, React, TypeScript, Tailwind CSS, Drizzle ORM, postgres.js, PostgreSQL, Amazon Aurora PostgreSQL Serverless v2, AWS SDK for JavaScript v3, Amazon RDS, Vercel, GitHub webhooks, lucide

Built With

• amazon
• aurora
• next.js
• postgresql
• react
• tailwind
• typescript
• vercel