Manager Tool Overview

The Manager Tool, Database DevOps, is the change-management and release-orchestration control plane of Simcha DB Studio. It governs the path a schema or data change takes from authored SQL to executed migration across a fleet of heterogeneous targets, with review, approval, dependency ordering, environment promotion, and an immutable execution record enforced at every hop. It is the ChangeOps half of the "one product, not two" thesis: the same objects and connections you query in the IDE are the ones you version, gate, and deploy here.

The Control Plane

Every change is modeled as a first-class, versioned, content-hashed script with an explicit target (connection + database + environment), a dependency set, and an approval state. Scripts compose into releases, versioned, environment-scoped units with their own state machine, which execute in dependency-topological order against per-script targets. Approval is a separate concern from authorship (separation of duties), execution is a separate concern from approval, and all of it lands in a tamper-evident audit log. The platform is dialect-agnostic: a single release can drive PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, and MongoDB targets in one run.

The change-management surfaces (Scripts, Releases, Approvals, Executions) render each item as a status-bearing card; opening one reveals the full detail and a status-gated action set, Scan Impact, Request Approval, Execute (surfaced only once approved), Edit, Delete, in the panel's top-right. Available actions are a pure function of the item's current state.

Primitives

Migration Scripts

The atomic unit of change: a single logical mutation (DDL, DML, or MongoDB shell operation). Each script carries approval status, an auto-incrementing version, a SHA-256 content hash, tags, a database-type classification, a resolved target (connection + database), an environment, and a dependency set referencing other scripts. Scripts are authored inline or pulled from source-control / object-store providers. The content hash binds the reviewed bytes to the executed bytes, editing an approved script invalidates its approval.

Releases

A named, versioned aggregate of Release-type scripts targeting an environment, advancing through Draft → Planning → Ready → Deploying → Completed | Failed | Rolled Back. Membership is mutable in Draft; the gate to Ready requires every member script Approved. On deploy, scripts run in dependency order, fail-fast on first error, each against its own persisted target.

Approval Workflows

Multi-signature review enforcing separation of duties: Draft → Pending → Approved | Rejected, with revise-and-resubmit on rejection and admin revocation of granted approvals. Authors cannot approve their own work; approved content is pinned by hash. Once a request reaches Approved, its approval card exposes an Execute action that launches the same targeted run flow as the script card, so an approved change can be deployed without leaving the Approvals surface. Professional adds the Decision Flight Recorder (point-in-time schema/statistics snapshots at request and signature); Enterprise adds custom RBAC roles.

Dependency Resolution

Scripts declare dependencies; the engine builds a DAG, topologically sorts it, and executes in resolved order. Cycles are detected and rejected at save time. A failed node halts the frontier, dependents are never attempted.

Multi-Environment Promotion

Environments are user-defined deployment targets (no fixed taxonomy), each optionally gated by an approval requirement and backed by one or more connections. The same release, same scripts, same versions, same hashes, is promoted stage to stage; no per-environment edits, so what passed lower environments is bit-identical to what reaches production.

Opening an environment lets you attach existing connections to it, or create a brand-new connection right there (+ New connection) pre-assigned to that environment, no need to leave for the Connections page first.

Execution Tracking

Every run, standalone or release-scoped, persists the script name, the exact SQL snapshot at execution time, the resolved target, the actor, start/end timestamps, duration, terminal status (RUNNING / COMPLETED / FAILED / ROLLED_BACK), rows affected, and full driver error text. This is the authoritative record of what ran, where, when, and by whom.

Repository & Storage Integration

Scripts sync on demand from GitHub, GitLab, Bitbucket, and Azure DevOps (source control) and S3, Azure Blob, GCS, and Dropbox (object stores), scoped by per-source release/ad-hoc path pairs and a file-pattern glob. Pull is explicit, not a background poll.

Dashboard

The overview surfaces live counts, total scripts, total releases, configured connections, pending approvals, and a recent-activity stream (uploads, approval decisions, executions), each item a deep link into its detail. Values are read from the backend on load; nothing is fabricated.

RBAC

Built-in roles separate authorship, review, deployment, and administration:

The split structurally prevents self-approval and enforces the four-eyes principle. Enterprise adds SSO federation and configurable custom roles on top of the built-in set.

Tamper-Evident Audit

Every consequential action is appended to an immutable log: script create/edit/delete; approval request/approve/reject/revoke/resubmit; release create/modify/deploy; execution (success or failure, with resolved target); auth events; license activation/deactivation; configuration changes. Records capture actor, timestamp, action, and full before/after detail (sensitive fields redacted), and are queryable for compliance reporting.

Licensing

Database DevOps requires Professional or Enterprise. Starter is IDE-only; SSO federation, full audit, and custom RBAC are Enterprise.