Product
How EVOSCA works
A change starts in a developer's own schema and ends as a versioned edition in production. Everything in between — capture, integration, conflict detection, approval, promotion — is recorded in the database that is being changed.
The chain, step by step
1 · Onboard a developer
Each developer gets their own schema under EVOSCA's management. It is a real working schema, not a scratch copy — they build and test in it as they normally would.
evosca onboard alice
2 · Package what changed
EVOSCA compares the developer's schema against the current baseline and captures the difference — tables, packages, functions, views, sequences — as a change set. Nobody hand-writes a migration script.
evosca package -d alice
3 · Integrate
The change set is applied to the integration schema, where it meets everyone else's work. If two developers have altered the same object, the collision is logged rather than silently resolved in favour of whoever ran last.
evosca integrate --change-id 42
4 · Check for conflicts
Developers see outstanding conflicts against their own environment, with the specific object and the diff behind it, and acknowledge them explicitly.
evosca conflicts -d alice
5 · Promote under approval
A promotion carries a set of changes to a target environment. Where approval is required, the promotion waits for it — the gate is a row in the database, not a convention someone remembers.
evosca promotion create --env-type STAGING
6 · Cut over
Cutover moves the current version forward. Editions track which version is current and which is next, so what is live is a property of the database rather than of a deployment log.
evosca cutover v1.4
The control surface is in the database
Promotion state, versions, approvals, the change catalogue and the conflict log are tables and stored procedures inside the managed database. A worker process drives the asynchronous work, but the record of what happened does not live somewhere else.
That has practical consequences:
- An auditor can query the database directly for what changed, when, and under whose approval.
- The history survives losing the CI system, the dashboard, or the vendor.
- Promotion decisions can be enforced by database privileges, not only by a UI.
Both engines, one model
Oracle and PostgreSQL are supported by the same commands and the same promotion model, through engine-specific adapters. Where the engines genuinely differ — editions, session behaviour, DDL semantics — EVOSCA absorbs the difference rather than exposing it.
Snapshots
Structural snapshots capture a schema's shape so a baseline can be re-established or a developer environment refreshed. Data snapshots, including masking for non-production use, are a paid capability.
What it does not do
Worth being straight about, because it decides whether EVOSCA fits.
- It does not replace your CI system — it is what CI calls to move a schema change forward.
- It does not manage application code or infrastructure. Database schema and database code only.
- It is not a query tool, an IDE, or a monitoring product.
- Today it supports Oracle and PostgreSQL. Nothing else is planned in the near term.
Run it against your own database
The self-hosted PostgreSQL build will be free for small teams, including promotion all the way to production. Not released yet.