READ-ONLY SCHEMA REVIEW
Compare PostgreSQL and MySQL Schema Snapshots
Keep reviewable evidence of supported database metadata before and after a separately managed change. Spekra compares snapshots from the same engine and reports observed differences; it does not execute or certify migrations.
Guided pilot scope · Reviewed 2026-10-16. No production AI diagnosis, automatic infrastructure/DDL remediation or compliance certification is offered.
The capture and comparison workflow
An organization administrator with Database Pulse access chooses an enabled PostgreSQL or MySQL target. Capture a baseline, then another snapshot after a change approved outside Spekra. Select the baseline and comparison to view added, removed or changed supported objects.
PostgreSQL captures a selected user schema; MySQL captures the database configured on that target. Register another MySQL target for a different database. Comparing PostgreSQL against MySQL is not supported.
- Read supported table and column metadata without selecting business rows.
- Compare selected ordinary-index attributes.
- Retain snapshots, complete comparison reports and content hashes.
- Download evidence or remove comparisons before deleting their referenced snapshots.
What differences are covered?
Supported fields include column names/types/nullability and selected identity, generated or default-presence markers. Ordinary indexes include selected method, uniqueness and ordered-column attributes. MySQL also reports index prefix length, direction and visibility.
Default/generated expressions, constraints, enum/set labels, triggers/routines, partition details and expression-index definitions are excluded. PostgreSQL partial/expression indexes may be recorded as unsupported inventory. No differences means only that the collected subset matches.
Consistency and retry behavior
PostgreSQL uses a repeatable-read, read-only transaction. MySQL requires two matching consecutive metadata scans and rejects unstable collection. Two matching scans do not create a global DDL lock or guarantee an atomic catalog view.
A completed capture can be replayed with its idempotency key. Changing target or schema under the same key rejects the request. Captures have bounded timeouts/concurrency; failures return errors instead of substituting a demo catalog.
Evidence limits and responsibilities
Each organization permits 100 snapshots and 200 comparisons. Snapshot/report JSON is bounded to 2 MB; collection also limits tables, columns and indexes. The UI displays the first 200 changes; complete retained report JSON is downloadable.
A SHA-256 hash is a content checksum, not an author's signature. Downloads can include object names and operator email addresses. Review them before sharing. There is no scheduled continuous drift capture, evidence re-import, automatic DDL, DDL dry-run validation or production AI diagnosis.
Frequently asked questions
Does no drift mean a deployment is safe?
No. Matching supported metadata does not establish complete schema equality, application compatibility, equivalent performance or migration safety. Review excluded properties and deployment tests separately.
Which database versions have been validated?
Readers support PostgreSQL 12+ and MySQL 8.0.13+. Retained actual Docker acceptance used PostgreSQL 17 and MySQL 8.4. MariaDB is unsupported.
Can team members download schema evidence?
Members can read and download their organization's retained evidence. Capture, comparison and removal require administrator permissions. Referenced snapshots cannot be removed until their comparisons are removed.
Evaluate your own workflow
Start with supported sample or staging infrastructure and agree on a success measure. Contact the operator to arrange a pilot. This static website does not create accounts or send invitations automatically.
Request a guided pilot →