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-aware: a single release can drive PostgreSQL (and its wire-compatible engines: CockroachDB, Redshift, Aurora PostgreSQL, YugabyteDB, TimescaleDB), MySQL/MariaDB, SQL Server, Oracle, and SQLite targets in one run, each executed through its own native driver.

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.

On a phone-sized screen the Database DevOps navigation is tucked behind the menu button at the left of the top bar; it opens as a drawer that closes when you pick a page, press Esc, or tap outside it, and every page uses the full screen width.

Press Ctrl+K (⌘K on a Mac) to open the command palette: type part of a page name, move with the arrow keys and press Enter to go there, or Esc to close it. It offers the same pages the navigation shows you.

When a page's list cannot be read from the server, the page says so in place of the list, for example The migration scripts could not be loaded: followed by the reason, with Retry. It never shows an empty list for data it could not read.

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 list of scripts that runs as one unit. A release is Pending while it is assembled, Signed Off once an approver has reviewed it, and Executed or Failed after each run. Sign-off requires every script to be approved and records the exact SQL that was signed off; changing the scripts or their SQL returns the release to Pending. A run executes the scripts in dependency order, each against its own target, and stops at the first failure. In the Execute dialog, scripts without a target of their own run on the Fallback Instance; hovering a script shows when it runs on its own target, and hovering Scripts to Execute shows how many there are.

Approval Workflows

Multi-signature review enforcing separation of duties: a script or a release in an environment goes from Pending to Approved or Rejected, with resubmit after a rejection and revocation of granted approvals. With Allow Self-Approval turned off (Settings, Approval), nobody approves or signs off their own work; changing an approved script's SQL returns it to pending. 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. It also includes the Decision Flight Recorder (point-in-time schema/statistics snapshots at request and signature), and custom roles.

Dependency Resolution

Scripts declare the scripts they depend on. A dependency loop is refused when the script is saved. A single script runs only after every script it depends on has completed a run, and a release runs its scripts in dependency order, stopping at the first failure so dependents are never attempted.

Multi-Environment Promotion

Environments are user-defined deployment targets (no fixed taxonomy), backed by one or more connections. Each can require an approval, and can require a completed run in an earlier environment first (for example Production after Staging). The same signed-off release, the same scripts with the same SQL, moves from stage to stage; changing it returns it to Pending, so what passed the earlier environment is exactly what reaches the next.

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, a single script, each script of a release run, and each rollback, records the script, the exact SQL that ran with its SHA-256 and script revision, the connection and database it ran against, the mode, who started it, start and end time, duration, status (RUNNING / COMPLETED / FAILED / ROLLED_BACK), rows affected, output, full driver error text, and the rollback captured for it. Only the server writes these records, so they are the authoritative account of what ran, where, when, and by whom.

Each target executes through its dialect's native driver on a single pinned session, so multi-statement scripts carry session state (temp tables, USE, SET) across statements. Runs support three modes: transactional (all-or-nothing; the first failure rolls the batch back), halt (stop at the first failure), and continue (run every statement, collecting per-statement errors). Note that DDL auto-commits on MySQL and Oracle, so transactional mode is best-effort there. Neo4j runs a script of data statements in one transaction; MongoDB, Redis, Cassandra, Elasticsearch and Neo4j scripts that change its schema are made all-or-nothing by reversal (see Execution Modes). Every engine captures a deterministic rollback before the run (see Deterministic Rollback Generation).

Notifications

The bell in every top bar lists your notifications: approvals requested from you, your scripts approved or rejected, and releases signed off. Each one opens the item it is about, can be marked read or unread or dismissed, and each kind can be switched off in Settings. See Notifications.

Schema Ops

Snapshots record a connection's schema; one per connection is the baseline that drift scans compare with, and each difference becomes an alert that is open, acknowledged or resolved. Snapshots can be exported as DDL, compared with each other or the live schema, and used as the desired state for a plan that generates the SQL to get there. The linter checks SQL or a saved script, and a script's -- @check lines run read-only before every run of it. See Schema Ops.

Seed Data

Seed definitions hold the rows a reference table should have. A plan compares a seed with a connection's table, lists the rows to insert, update and delete with their values, and can be saved as a migration script that goes through approval. See Seed Data.

Compliance Rules

Rules every script is checked against. A rule checked by a pattern is decided exactly on every script, and a failing error rule blocks approval; rules judged by the AI model run in the Compliance Check. Rules can be limited to engines and environments and tried on SQL before they are saved. See Compliance Rules.

Schema ERD

A diagram of a connection's live tables, views and foreign keys, with an inspector for each table's keys, indexes and incoming references, a schema filter, table search and SVG download. It works from the keyboard and on touch screens, and only reads the database. See Schema ERD.

Metrics

Success rate, failures by cause, release and approval flow, script activity and system use, counted from your own records for the last 7, 30 or 90 days or 12 months. See Metrics.

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 one or more file patterns. A pull walks the folder and every subfolder, and re-pulling only touches files whose content changed. Pull is explicit, not a background poll.

Overview

The Overview counts the migration scripts, the releases not yet run, the approval requests awaiting sign-off and the registered connections; each count says what it counts beneath it and opens its page. Active Deployments lists every run in progress with its script (and release), environment, target, how long ago it started and by whom, and how far it has got (the statement running of the total, or the step before the first statement), and refreshes every 3 seconds while anything runs and every 15 seconds otherwise; it says when nothing is running, and when the runs cannot be read it says why and offers Retry. Recent Executions lists the five latest runs with their environment and status; selecting one opens its Full Details, and View All opens Executions. Every value is read from the server; nothing is fabricated.

RBAC

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

Each role includes everything the roles below it can do. Admins also choose which sections each role includes and can add custom roles; a person sees, and can change things in, only the sections their roles include. See Roles & Access Control on the Configuration page.

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) and rollback (with the reason and the rollback run); auth events; license activation/deactivation; configuration changes. Records capture actor, timestamp, action, and full before/after detail (sensitive fields redacted), and can be searched and filtered in the Audit Log.

Licensing

Every active license includes Database DevOps, the Audit Log, AI, usage sampling and single sign-on, with unlimited connections, for the number of users its seats allow; Settings shows the customer, the seats in use and the expiry of the active key.