NexaGres

NexaGres DMS

Tool for moving off Oracle/MySQL/MariaDB/SQL Server onto Postgres: assess how hard the migration is, launch and track the real data-movement run, and bridge your existing application to Postgres while you do it.

Two ways to get an assessment#

• Connect a databaseA read-only connection profiles the real schema, feature usage, and query workload directly — no data leaves your database, only metadata and query statistics. Deterministic: run it twice, get the same score.
• Upload a performance reportDrop in an Oracle AWR report, a MySQL performance report, or a SQL Server DMV/Query Store export, and an LLM reads it for you. A genuinely different kind of signal than a live connection — labeled as such everywhere it shows up, never presented as equivalent.

What you get#

• Migration difficulty score and tierReproducible and rules-based — run it twice against the same database, get the same score and the same itemized breakdown behind it.
• Feature inventoryPL/SQL packages, triggers, procedures, partitioning, database links, scheduled jobs, and more, each weighted by real migration cost.
• Schema, workload, and parameter browsingDrill into any table, view, procedure, or function's real definition; a captured-query-workload summary (top SQL by cost, executions, buffer gets); and the source database's full configuration parameter list, filterable — all read-only, all from the same connection.
• Downloadable findings report (PDF)Generated live from the current scan, built for sharing with a stakeholder who'll never open the app.
• Postgres sizing recommendationvCPUs, memory, storage, and IOPS from a live connection's schema size and captured workload — or from an uploaded report's signals — with the caveats and the reasoning behind every number spelled out, not just the numbers themselves.
• PL/SQL summarization (Oracle sources)An LLM explains what a package or procedure actually does in plain English, with an optional second-opinion "judge" model for a review pass — advisory only, layered on top of the rules-based score, never replacing it.

Where NexaGres DMS is still early: saved connection credentials are stored as-is today — encryption at rest is planned but not yet built, so treat this like any other tool you'd point at a database with a password in a config file. There's a single shared admin account, no per-user roles or SSO yet. Worth knowing before you point it at anything you wouldn't otherwise put in a plaintext config.

Connecting, exploring, and reviewing PL/SQL with an LLM's help#

A connection is a JDBC URL, a schema/user, and a credential — plain password today, or a reference into Vault or CyberArk if you'd rather not store the secret in NexaGres DMS at all. Once it's saved, Objects lists everything that user can see, grouped by type and (for a multi-schema connection) owner-qualified so a package in one schema is never confused for one in another. Selecting a routine shows its real source, pulled live from the database, not a cached copy.

What the LLM step actually does, precisely: select a package, procedure, or function and NexaGres DMS can ask an LLM to explain it — a plain-English summary of what it does, a bullet list of the specific constructs that are non-trivial to port to Postgres (cursor locking, DBMS_OUTPUT, autonomous transactions, and the like), and a trivial/moderate/substantial effort estimate with its reasoning. This is a reviewer's aid, not a code generator — it does not emit PL/pgSQL, and nothing it produces feeds back into the deterministic score above. Runs entirely local by default (no API key, nothing leaves the machine) against a small on-box model, or against an external provider if you configure one on the LLM page.

Admin console#

The two screenshots above are the real product against a real connection. The embed below is the click-through demo — synthetic data standing in for a real connection, but the same console, every page explorable, nothing left as a static picture.

Migration Service: launch and track a migration#

Assessment tells you what you're dealing with; Migration Service is where you actually move the data — real, massively-parallel nexagres-migration runs (MongoDB change streams, MySQL binlog, SQL Server/Oracle native CDC, DynamoDB Streams, SQS, Neo4j snapshot, InfluxDB timestamp-cursor tail), launched from a form and tracked to completion, without ever leaving NexaGres DMS. Every write lands through PolyWire's own gRPC driver — never a direct JDBC connection to the target — so a migration in progress is subject to the exact same firewall, QoS, and cache pipeline as any other client.

Launch picks a connector, the target Postgres connection, and the source's own credentials, then starts the run server-side. Status shows the same live progress every worker process itself checkpoints against — partitions done, events applied, change-feed lag, and which worker currently owns the live tail — for every source pointed at that target, not just the one you just launched. Parallelism above 1 needs an Enterprise PolyWire license; without one, a migration still runs correctly, just serially, one partition at a time.

Sources Migration Service accepts#

Every source gets a real, parallel initial snapshot. Where the source has a genuine change-tracking mechanism, Migration Service also runs a live change-data-capture (CDC) tail after the snapshot — not a polling re-scan. Where it doesn't (a queue; a graph database with no CDC in its free tier), that's stated plainly below, not glossed over.

Every target schema is matched byte-for-byte to PolyWire's own wire protocol store, so a real client speaking that protocol can use the migrated data immediately.