Overview

Simcha DB Studio collapses two product categories, a multi-dialect database IDE and a database change-management (ChangeOps) control plane, into one self-hosted application backed by a single control plane, one identity/RBAC model, and one license. The market ships these as separate tools with separate auth, separate audit, and no shared object model. Here, the client you run ad-hoc queries in and the pipeline that promotes those changes to production are the same system, so a script authored in the editor, its dependency graph, its approvals, and its execution history are all first-class objects in one store.

The product is delivered as a single multi-arch (linux/amd64 + linux/arm64) 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; the application never sees data it isn't pointed at, and it stores only its own metadata. Your target databases are reached directly over their native wire protocols from the container.

Fleet of One

There is no "single database" mode and no "fleet" mode. One connection is a fleet of one; 5,000 connections exercise the same code paths, the same discovery, the same release and approval machinery. Nothing about the workflow changes as cardinality grows, so operational patterns you establish against a single target hold unchanged across the whole estate. There are no per-scale toggles to reason about.

IDE

A browser-delivered, zero-install client covering the full estate of supported engines from one surface. Connections are independent and worked concurrently across tabs.

• Editor, Monaco with per-dialect syntax and completion driven by live schema introspection (tables, columns, keywords), inline validation, multi-tab sessions, and statement-vs-selection execution.
• Schema navigation, object tree by schema and type with an inspector for columns, types, constraints, and indexes; context actions for top-N sampling, INSERT generation, and DDL extraction.
• Plan and timing, per-statement latency plus EXPLAIN / EXPLAIN ANALYZE plan visualization (node types, estimated vs actual rows, cost, buffers) where the engine exposes it.
• Result handling, in-tab charting (bar / line / pie / area) and export to CSV, JSON, INSERT statements, or TSV.
• Organization, connections foldered by environment, project, or team.

Supported engines

Engines fall into two states. Implemented engines have a full backend (introspection, execution, plan where applicable); Preview engines are selectable in the connection picker but not yet backed.

ChangeOps (Database DevOps)

The change-management half moves schema and data changes from authorship to production under review, approval, dependency ordering, and immutable audit, everything the IDE lacks by design and every serious release process requires.

• Change-script lifecycle, scripts authored in the editor or synced from source control and object storage. Each carries a target engine, environment, tags, version, content hash, and declared dependencies; the content hash makes drift and post-approval tampering detectable.
• Versioned releases, scripts grouped into releases with an explicit state machine: Draft, Planning, Ready, Deploying, Completed, Failed, Rolled Back. A release binds its script set and target environment.
• Multi-signature approvals and separation of duties, production changes require reviewer sign-off distinct from the author. Reviewers approve or reject with comments; rejected changes are revised and resubmitted. Author-cannot-approve-own is enforced.
• Dependency resolution, declared inter-script dependencies are topologically sorted and cycle-checked before any execution begins, so ordering is deterministic and a bad graph fails fast rather than mid-deploy.
• Multi-environment promotion, Dev, QA, Staging, Production, DR, each with its own connection bindings; releases promote stage to stage behind approval gates.
• Execution tracking, every run persists script, target, start/end, status, output, rows affected, and errors, retained as history for audit and forensics.
• Repository and storage sync, pull from GitHub, GitLab, Bitbucket, Azure DevOps and from S3, Azure Blob, Google Cloud Storage, Dropbox, scoped by branch, path, and file pattern, on demand.
• RBAC, five built-in roles (admin, developer, reviewer, deployer, viewer); Enterprise adds custom roles and SSO federation.
• Tamper-evident audit, every state-changing request is recorded with actor, timestamp, request ID, and old/new values, with sensitive fields redacted at write time.

Licensing and tiers

Per-seat licensing across three tiers. The IDE is present at every tier; ChangeOps unlocks at Professional; federation, custom RBAC, and full audit/compliance are Enterprise.

Licenses are RSA-signed by Simcha and verified locally against the public key baked into the build, tier and seat entitlements are enforced entirely offline, with no runtime call to any Simcha service. Activate via the UI or POST /api/license/activate; state persists in the metadata store across restarts. Pricing: contactus@simchasolutions.com.

Runtime topology

One image, two co-located processes, one Postgres metadata database:

• Next.js (standalone) serves the UI. The browser never talks to the API directly, it proxies through Next.js API routes to the backend.
• Express (TypeScript) is the API: auth, connection and query operations, ChangeOps, and license validation.
• PostgreSQL holds all control-plane state, users, connections, scripts, releases, approvals, executions, audit, in a single metadata database. Stored connection secrets and other sensitive fields are AES-256-GCM encrypted at rest.

Target databases are contacted over their native protocols. Application data is never proxied through, cached in, or persisted to the metadata store, only Simcha's own control-plane metadata lives there.

Deployment surface

The same image runs everywhere; the wrapper is your choice:

• Kubernetes (Helm), the universal production path, EKS, AKS, GKE, OpenShift, k3s, on-prem.
• Docker Compose, single-host deploys and evaluations.
• Managed container services, ECS Fargate, Azure Container Apps, Cloud Run, thin wrappers over the identical image.
• Bare metal / VM, any OCI runtime (Docker, Podman, containerd), no orchestrator required.

See Deployment for specifics.

Next

• Quick Start
• Installation & System Requirements
• IDE Documentation
• ChangeOps Documentation
• Configuration Reference