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, and from there it reaches every other developer's schema automatically. If two developers have altered the same table, columns one of them added merge on their own; any other collision, and every clash over the same code object, is logged with its diff 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
A release is promoted into production beside the one users are running — its own edition on Oracle, its own version schema on PostgreSQL — so you can check it, and fix or roll back any object, before anyone sees it. Columns it adds stay out of the current version's view. Cutover then switches users over: a blue-green approach for database changes. 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 can be loaded into Integration with the columns you declare masked, once the masking rules are approved.
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.
- It does not yet switch a whole release back after cutover. Any object's last change rolls back with one command, as an approved promotion.
- Today it supports Oracle and PostgreSQL. Nothing else is planned in the near term.
Run it against your own database
The self-hosted build will be free for up to 6 managed environments and 2 managed schemas, including promotion all the way to production. At first release PostgreSQL is a public download and Oracle is early access on request. Not released yet.