Simcha DB Studio

Simcha DB Studio is a unified Database IDE and a Database DevOps workspace, shipped as one product. Connect to every dialect your team runs, query and browse them in a single interface, then version schema changes, move them through environments, and audit every step.

Looking for the complete reference? The complete reference is published on this site, generated directly from the product documentation: start at the full docs. It covers the IDE, change management, the AI agents, configuration, deployment (Docker, Kubernetes, ECS, Azure), SSO setup, the API reference, and troubleshooting. This page is the condensed public version.

Architecture

DB Studio is delivered as a single container image that you run inside your own perimeter, any cloud, on-prem, Kubernetes, or a bare container runtime. There is no Simcha-operated SaaS or control plane, nothing phones home, and the application stores only its own metadata. Your target databases are reached directly over their native wire protocols.

• Fleet of One. One database is just a fleet of one. The same product manages a single instance on your laptop and an enterprise-scale fleet without separate “single” vs “fleet” modes.
• One auth surface. SSO, MFA, RBAC, audit. The same identity model whether you are a solo developer or a multi-team enterprise.
• Schema changes are artifacts. Every change is a versioned, reviewed, approved, deployable record with a content hash. Audit and rollback are first-class, not bolt-ons.
• Connection encryption at rest. AES-256-GCM, PBKDF2 key derivation, secrets pulled at runtime. Connection passwords are never written to disk in plaintext.

Supported databases

Native adapters across the common production stack. The fully implemented set:

Additional engines (Snowflake, BigQuery, DynamoDB, InfluxDB, FaunaDB, Supabase, PlanetScale) appear in the connection picker as preview: selectable, but without an execution backend yet. Don’t see your dialect? Tell us about it, we prioritize the beta roadmap based on cohort feedback.

Quick start

Zero to a running instance with an activated license and a live connection. Two paths: Docker Compose for single-host and evaluation, Helm for clusters. The delivery bundle ships docker-compose.yml, .env.example, and helm/; your license key arrives separately by email.

Secrets

Three secrets are mandatory; the app fails closed at startup if any is missing.

• JWT_SECRET: signs session tokens; rotating it invalidates all live sessions.
• ENCRYPTION_KEY: the AES-256-GCM key wrapping stored connection secrets. Back it up and treat it as unrotatable in place; without the original key, previously encrypted rows are unrecoverable.
• DB_PASSWORD: password for the metadata Postgres.

Docker Compose

cp .env.example .env
echo "JWT_SECRET=$(openssl rand -hex 32)" >> .env
echo "ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env
echo "DB_PASSWORD=$(openssl rand -hex 16)" >> .env

docker compose up -d
curl http://localhost:5002/api/health

Compose pulls the image, starts Postgres, applies migrations idempotently, and launches the app. First boot is 30 to 60 seconds; health reads STARTING until the metadata database is reachable. Open the UI, paste your SDB-... license key (verified locally against the bundled public key, no network call), then add a connection, test it, and query.

On Kubernetes, helm install renders the app Deployment, a Postgres StatefulSet, and a migration Job that gates the rollout so migrations complete before any new pod serves traffic. The full walkthrough, including production overrides, lives in the full Quick Start guide.

Connect PostgreSQL

Connections are server-held records bound to your user account: the browser never sees a credential or opens a socket to a database. Passwords are encrypted at rest and never returned to the client. Test before saving; the probe authenticates, runs a liveness statement, and returns the server version on success or the precise driver error on failure.

• SSL mode: the full spectrum from disable through require to verify-ca and verify-full. Managed Postgres (RDS, Cloud SQL, Azure) generally mandates at least require; use verify-full with the provider CA.
• Application name is propagated to pg_stat_activity, so IDE sessions are attributable server-side.
• A full connection URI may be supplied instead of discrete fields. CockroachDB and TimescaleDB speak the same wire protocol; TimescaleDB additionally surfaces hypertable metadata.
• Private targets: per-connection SSH tunneling through a bastion, with a mandatory SHA256 host-key pin. There is no trust-on-first-use; a missing or mismatched fingerprint fails loud.

Connect MySQL / MariaDB

Standard host, port, database, and credential fields, plus optional TLS and connection character set (utf8mb4 default). MariaDB is protocol-compatible; selecting it only adjusts dialect handling for MariaDB-specific SQL. The target-database picker is populated live from information_schema.schemata, excluding system schemas.

Connect SQL Server

• Instance name support for named instances.
• Encrypt (TLS) on by default, with Trust Server Certificate available for self-signed development endpoints.
• Azure SQL Database and Managed Instance connect with the same form. Integrated/Windows auth requires the host process to sit in the same AD domain; otherwise use SQL Server authentication.

Connect MongoDB

• Connect via a full URI (including mongodb+srv:// for Atlas) or discrete host fields.
• Auth source, replica set, and TLS are exposed for real topologies rather than single-node assumptions.
• Schema introspection samples collections so a schemaless store still gets a browsable tree, and the change manager classifies MongoDB shell scripts and filters targets accordingly.

Per-dialect field references for every engine, including Oracle service names, SQLite server-side paths, and Redis database indexes, are in the connection-fields reference.

Versioned scripts

A script is the atomic, versioned, content-hashed unit of change. Author inline in the editor or pull from a configured source: GitHub, GitLab, Bitbucket, Azure DevOps, S3, Azure Blob, Google Cloud Storage, or Dropbox, scoped by branch, path, and file pattern.

• Version + content hash. The version starts at 1 and increments on every content edit; a SHA-256 content hash binds reviewed bytes to executed bytes.
• Type classification. Content is classified live as SQL or MongoDB shell, and the target picker filters to compatible instances. Target databases are enumerated from the instance's real system catalogs, not free text.
• Dependencies. Declare that B depends on A; the engine builds a DAG, topologically sorts, executes in order, and halts on first failure with dependents unattempted. Cycles are rejected at save.
• Edit semantics. Editing an approved script recomputes the hash and resets it to Draft. Re-review is mandatory before the mutated script can run.

Approval gates

Approval is the separation-of-duties gate between authorship and execution: Draft, Pending, Approved or Rejected (with a required comment), Executed. Author-cannot-approve-own is enforced, rejected scripts follow a revise-and-resubmit cycle with an incremented version, and admins can revoke a granted approval, which resets the script to Draft.

• Hash-bound approval. Sign-off is pinned to the exact content hash, so there is no path to deploy bytes that diverged from what was reviewed.
• Blast radius. Before sign-off, DB Studio walks the live target and computes downstream impact: dependent views, inbound foreign keys, triggers, partitions, plus the services registered or observed as readers of the affected objects. Incomplete walks are marked partial with the reason rather than fabricated.
• Shadow execution. From the approval screen, a shadow run provisions a disposable twin of the target, applies the pending script, diffs the schema before and after, and tears the twin down, surfacing the real effect and the exact SQL error without touching the target. PostgreSQL and MySQL/MariaDB.
• Decision Flight Recorder (Professional) captures point-in-time schema evidence at request and at sign-off, so reviewers and auditors can see exactly what the database looked like at each moment, and diff the two.

Rollback

On PostgreSQL targets, the engine captures the relevant pre-change state before the forward script runs and derives an exact inverse, computed from the actual prior state rather than guessed:

• UPDATE becomes per-row restores of prior values, matched by primary key.
• DELETE becomes INSERTs re-creating the removed rows.
• CREATE (table, index, view, sequence, function) becomes a DROP of that object; ADD COLUMN becomes DROP COLUMN; renames invert.
• Genuinely irreversible operations (TRUNCATE, DROP, lossy type changes) are enumerated as irreversible rather than papered over, so the rollback’s coverage is explicit.

Execution modes control failure behavior: transactional all-or-nothing (default), stop on first error, or continue on error for idempotent batch remediation. On AI-enabled licenses, the Auto-Rollback agent drafts inverse SQL for review as well.

Execution history

Every run persists an immutable record: the executed script, an exact SQL snapshot captured at execution time, the resolved target connection and database, the triggering actor, start and end timing, status (RUNNING, COMPLETED, FAILED, ROLLED_BACK), rows affected, and the full driver error on failure.

Releases group approved scripts and deploy them as one fail-fast, dependency-ordered unit through a state machine (Draft, Planning, Ready, Deploying, Completed, Failed, Rolled Back), with a live progress panel per script. Promotion redeploys the same release, identical scripts and hashes, from Development through QA and Staging to Production; what was validated below is bit-identical to what reaches production.

Auth (SSO, MFA)

• Passwords are hashed with bcrypt (cost 12, per-hash salt, constant-time verification) and never logged or returned.
• Sessions are stateless JWTs with an 8-hour expiry, carried in the Authorization header, so the API is not CSRF-exploitable. Honest revocation semantics: deactivating a user blocks new logins immediately, while an already-issued token remains valid until it expires; rotating JWT_SECRET revokes every live session at once.
• MFA is TOTP (RFC 6238) with QR enrollment and 10 single-use backup codes stored as SHA-256 hashes, never plaintext.
• RBAC: five roles (admin, developer, reviewer, deployer, viewer) enforced at the route and license-tier boundary, giving a two-person rule for production: the author, approver, and executor are different people.
• SSO federation (Enterprise): SAML 2.0, OIDC, and LDAP/Active Directory, with Azure AD, Okta, Google, and AWS Cognito configured on top. Just-in-time provisioning matches on email, and IdP groups map to roles, so privilege is managed in your directory.

Encryption at rest

• Algorithm: AES-256-GCM with PBKDF2-SHA512 key derivation from ENCRYPTION_KEY.
• What is encrypted: managed connection passwords, SSH tunnel secrets, repository and cloud-storage tokens, MFA seeds, and sensitive settings. Secrets are decrypted only at use time (pool open, outbound API call) and masked in ordinary reads.
• Fail closed: in production the app refuses to boot without ENCRYPTION_KEY, so there is no silent plaintext fallback.

Audit log

• Automatic. Every state-changing action is captured with actor, timestamp, action code, entity, before and after values (sensitive fields redacted at write time), and source IP. Read-only queries are excluded by design.
• Tamper-evident. Each row is sealed by a database trigger into a SHA-256 hash chain; updates and deletes are refused at the table level, and an integrity endpoint verifies the chain end to end and pinpoints the first broken sequence.
• Retention defaults to 90 days and is configurable; the controlled purge trims the oldest tail while keeping the surviving chain verifiable. Archive off-box before purge for longer compliance windows.
• Viewer (Administration, Audit Log) requires an administrator role and an Enterprise license; collection itself runs on every tier.