Git-Native Source Fabric

FilesProvenanceGitDeploys

Roadmap Planned · not yet usable

What it is

The Git-Native Source Fabric closes the gap between source-controlled code and live database logic. Schema definitions, transformation rules, and executable cells live in a Git repository next to your application code. A declarative manifest at the repo root describes the database’s desired state. Pushing the manifest is the deploy: the engine reads it, calculates the necessary changes, and applies them atomically.

Every piece of logic deployed this way carries the Git commit that authored it, and every row it produces is tagged with the same commit. You can ask “show me everything produced by commit a4b2” and get a precise answer — there is no “mystery code” without a source anywhere in the running database.

Why it matters

Most production database incidents trace back to one of two questions: “who deployed this?” or “does the database match what’s in source control?” The Source Fabric makes both answerable instantly. The roles, reviews, and revert workflows from your existing Git pipeline apply to database logic as a matter of course.

Cryptographic provenance — every cell and every row carries its authoring commit.
Atomic deploy — a manifest push is one transaction: either the new state is live or nothing changed.
Instant rollback — revert the commit and re-deploy; the database repoints to the previous logic.
Reviewable — there is no ad-hoc path to land code; the only way in is a tracked, reviewed commit.

flowchart LR
  classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef b fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80

  G[(Git repository)]:::a --> M[manifest<br/>desired state]:::a
  M --> C[CI / CLI<br/>push]:::b
  C --> DB[(AetheriusDB)]:::g
  DB -. each row tagged .-> G

How you use it

Define your database’s desired state in a manifest, commit it, and push. The engine reconciles. Rollbacks are a normal Git operation.

# aether.yaml — declarative desired state (illustrative)
schema:
  - file: schemas/sales.aes
  - file: schemas/inventory.aes

cells:
  - name: trending_products
    source: cells/trending.aes
    target: sales_cube

horizons:
  - table: events
    retain: "90 days"

# Deploy: read the manifest, calculate deltas, apply atomically.
aether-pack deploy --manifest aether.yaml --cluster prod

# Rollback: revert the commit and re-deploy.
git revert HEAD
aether-pack deploy --manifest aether.yaml --cluster prod

The cluster refuses to load any logic that doesn’t carry a valid commit — the only way to land code in the database is through a tracked, reviewed source commit.

Key concepts

Concept	What it means
Manifest	A single file in your repo root describing the database’s desired state.
Registry	The in-database catalog that maps logic to commits and target tables.
Commit tag	The provenance marker every piece of logic and resulting row carries, pointing back to its source commit.
Atomic deploy	A manifest push applies as one transaction — all or nothing.

Database Branching →

Branch data the same way you branch code.

In-Database Compute →

The compiled-logic runtime the manifest deploys against.

Schema-as-Code & Migrations →

Schema changes as versioned, reviewable writes.

Configuration & Availability →

What is on by default vs. opt-in vs. planned.