Impact analysis with severity
Pick an object, describe the change, and get every dependent object that breaks, classified from critical (it will not compile) down to low, with the reason for each.
Dependency, impact and lineage analysis for Oracle databases
Understand your Oracle database before you change it.
SchemAxis parses your data dictionary and your PL/SQL code, including the SQL your code builds at runtime, which the catalog never records.
It works through an open-source, read-only local connector you run on any machine with access to your database, so your credentials never leave your environment.
Request early access
Free during the closed beta. No credit card.We review new requests every week.
- Read-only by construction
- Credentials stay in your network
- Bring your own AI key
Built for Oracle databases and PL/SQL today. The rest of the Oracle estate (APEX, ODI etc.) is a published direction in the roadmap.
Map dependencies and lineage
Interactive schema graphs and column-level lineage, including the SQL your code builds at runtime (Dynamic SQL)
Simulate change safely
Impact analysis shows what will break, ranked by severity, before you ship a line of DDL
Compare environments
Drift detection between test and production, down to the line that changed in a package body
AI assistant built in
Ask in plain language: it explains your schema, writes documentation, reads your uploaded spec docs, and drafts PL/SQL code against your real objects
Every change to a schema nobody documented is a gamble
A twenty-year-old Oracle system carries thousands of objects and millions of lines of PL/SQL, written by people who left a decade ago. Most of the dependencies are recorded in the catalog. Reading all of them before a release goes out is the part that does not happen, and the statements your code assembles at runtime were never recorded there at all.
“If I add a column to this table, which of the 3,000 procedures, views and packages break?”
“Half of this application builds its table names with string concatenation. What does the dependency list miss?”
“What does this legacy 2,000-line PL/SQL package do?”
“Where does the number in this report view actually come from?”
“The customer wants documentation for a system that has never had any. That is three weeks of reverse engineering.”
“How does data flow from table A to table B?”
“Did anything change in production that is not in test?”
“We need a PL/SQL audit trigger that follows the compliance rules in this spec document.”
Today these are answered with seniority, fear or consultants at day rates. The answer is already in the database. It is just not readable at the speed a release needs.
How it works
Install the connector, point it at a schema, and start asking.
Install the open-source SchemAxis local connector
A small program you run next to your database, with its source public so you can read what it does. It dials outward over TLS, so you open no inbound port and change no firewall rule. Your database username and password are configured in it, locally, and are never sent to us.
It maps the schema, read-only
Tables, views, packages, triggers, synonyms, constraints, and every dependency between them: read from the data dictionary and parsed from the source, never from the rows in your tables. The connector inspects every statement and refuses anything that is not a read, inside your network, whatever the cloud side asks.
Ask the questions that used to take a week
Simulate a change and read the blast radius, ranked by severity. Follow a column backwards through every view, procedure and trigger that touches it. Diff two live environments before a release, and get the documentation the schema never had.
Request early access
Read-only is enforced inside your own network, and your database credentials never reach us: how that works, in full.
See it working
Real screens from the product, on a synthetic schema built to look like the ones it is used on.
The blast radius, computed
Describe the change and read back every object that breaks, ranked by severity, with the statements the parse could not resolve listed underneath rather than dropped.
Then AI, on top of a finished result
Deep Scan begins from the result above and takes on what the engine itself marked unresolved: a table name assembled at runtime. The list was already computed before the AI assistant was opened.
Where a value actually goes
Explorer → Data Lineage: pick a column, pick a direction, and follow the value hop by hop through the code that moves it. Hops the parser cannot reach on its own are marked as inferred rather than mixed in.
Answers grounded in your schema
Ask in plain language and get PL/SQL back. The object and column names in it come from your schema, checked against the dictionary before you ever see them.
Where the product actually is
SchemAxis is currently operating in a private Closed Beta for selected design partners. The product is ready to be pointed at a real schema: every security control described on this site is enforced in code today, and every participant has a direct channel to us for feedback, support and feature prioritization.
What you get on day one
Dynamic SQL, not quietly skipped
Statements assembled at runtime are parsed out of the PL/SQL source instead of being dropped from the count. Whatever the parser cannot resolve is reported as an explicit gap on the result, because a dependency list that hides what it missed is worse than no list.
Column-level data lineage
Follow one column's value through views, inserts, merges, updates and triggers as a graph, or as an audit-friendly list of every process that reads and writes it and the tables each one touches.
Dependency explorer
What depends on what, forward and backward, across schemas, with broken synonyms, cycles and cross-schema links flagged. Legacy schemas keep referential integrity in application code, so the foreign keys the database never declared are reconstructed as a separate, confidence-scored layer.
Environment comparison
Diff the schema you developed on against the one you would promote onto, down to column types, indexes, constraints and the exact line that changed in a package body. Nothing in the release plan then depends on what someone remembers changing.
An AI assistant that can read your schema
Ask in plain language and get answers grounded in your own objects, your own code and the specification documents you upload. It will explain a 2,000-line package, write documentation you can hand over for tables that have none, or draft PL/SQL against the real column names and types.
Deterministic first. AI where it actually helps.
Nobody should point a large language model (LLM) at a production database and trust the output. So SchemAxis analyses are computed by a parser rather than generated by a model; the AI sits above the computed analysis as an optional layer: Deep Scan takes on the dynamic SQL the parser could not settle, and the assistant answers questions in plain language.
The engine does not guess
Dependencies, impact, lineage and environment differences come from parsing your data dictionary and your PL/SQL. Same schema, same question, same answer.
AI picks up where the engine stops
AI Deep Scan begins from the deterministic output and takes on what the engine itself marked as unresolved: a table name assembled at runtime, a transformation hidden in a cursor, the real risk in a schema difference.
It cannot invent an object
Every object an AI pass claims is checked against your real dictionary before it is displayed. A name that does not exist in your schema never reaches the screen.
Your provider, your key, your bill
AI is bring-your-own-key (BYOK). Prompts go to the provider you chose, on the account you own, down to a model running entirely inside your own network. We train nothing on what you send, and we keep no copy beyond the conversation you can see and delete.
No AI key configured? Impact analysis, lineage, the dependency graph and schema comparison all still run, and anything the parser could not resolve is still flagged as a warning on the result rather than left out of it.
Why not the tools you already have
The database catalog tells you the edges, not the blast radius
The dictionary's dependency views list direct references. They do not follow a chain through a package body, resolve a synonym, or see a statement your code assembles at runtime, and they never tell you which of the hits actually stop compiling.
The risk is in the code you have not opened
The established tools built around the Oracle ecosystem are excellent at running SQL, browsing objects and explaining whatever is in front of you. That is the half you can see. The other half decides the release: which of three thousand objects stop compiling if you drop this column, where the number in this report is actually computed, what a statement assembled at runtime touches. Explaining the package you found is a different job from finding it.
A general-purpose AI has never seen your estate
Pasting code into a general-purpose AI gets you plausible Oracle code, not your PL/SQL: no idea what it would break, wrong object names and your source code in somebody else's product. The AI assistants now built into IDEs are a real step up, but they usually work on what they can reach. SchemAxis assistant is a schema-aware AI that grounds its answers in your Oracle environment, reading the impact graph and the cross-schema lineage the engine has already computed, with your own specification documents uploaded in the same context.
Reverse engineering by hand does not scale to a release cadence
A senior engineer can answer any of these questions by hand, given enough time. But under tight release deadlines, manual reverse-engineering may miss hidden and not obvious dependencies, leading to broken production code, untested edge cases, and undocumented knowledge that leaves when the engineer leaves.
Access & Pricing during the Closed Beta
What does it cost? Nothing, for the whole beta. No credit card, no billing, no obligation.
When commercial plans launch they will start at €99/month for one developer and from €249/month for teams, excluding VAT.
The people who help us get this right will pay less for it: every design partner gets a founding-customer discount when they move to a paid plan, agreed with each partner before launch.
- Free for admitted design partners, for the whole beta. In return we ask for your feedback as you use it.
- Nothing to redo at launch: your workspace carries over into general availability.
- No lock-in: export your data or delete your organization from inside the product at any time.
Where this is going
SchemAxis is designed to stay inside the Oracle ecosystem. What makes an answer worth trusting is how far it reaches into the data dictionary and the PL/SQL. So the roadmap goes further into the Oracle estate: the applications and integration jobs built on top of the schema.
Building next
The rest of the Oracle estate
The same dependency, impact and lineage answers for what is built on top of the database (e.g., APEX applications, ODI mappings, Forms and Reports, Business Intelligence and Analytics etc.) so a change can be assessed across the ecosystem and not only inside the schema.
Analyses a team works on together
Hand a result to a colleague, keep the record of what was checked before a change, and connect it to the ticket in your issue tracker that the change belongs to.
The same questions, asked by your pipeline
Programmatic access to the analyses you run in the product, so a release process can check what a change would break without anyone opening a browser.
These are directions, not delivery dates: nothing here is scheduled, ordered, or promised. What gets built first is decided by what design partners actually need.
If one of these decides whether the product is useful to you, say so in the request form below. The order gets set during the beta.
Questions we get asked
What is SchemAxis?
SchemAxis is a web-based dependency-analysis, impact-analysis and data-lineage platform for Oracle databases. It reads schema structure (tables, views, packages, triggers and their dependencies) through an open-source read-only connector you install inside your own network, and answers questions such as "if I change this column, what breaks?" It is built for the developers, DBAs and system integrators who maintain legacy Oracle databases.
Which databases are supported?
Oracle only. SchemAxis reads the Oracle data dictionary and parses PL/SQL, and that depth is what answers the questions the tool exists for. The direction is deeper into the Oracle estate (the applications and integration jobs built on top of the database), not sideways: no other database engine is on the roadmap now. It works with Oracle Database 11g Release 2 (11.2) and every later release, including 19c and 23ai. The connector reaches your database the way a SQL client on that machine would, by service name or SID. The install guide shipped with it lists the releases tested and what it can connect to today.
Does it understand SQL that is built at runtime?
Yes, and it is one of the main reasons the product exists. Large Oracle applications assemble statements at runtime (EXECUTE IMMEDIATE, dynamic cursors, table names composed from strings) and the data dictionary records none of those references, so a dependency list built from the catalog alone is silently incomplete. SchemAxis parses the PL/SQL source itself to recover the object names those statements resolve to, and reports the ones it could not resolve as an explicit gap rather than omitting them: a statement whose target could not be confirmed is shown as a warning on the result, not hidden. The ambiguous cases can then be escalated to an AI Deep Scan, which reads the surrounding code and reconciles the runtime targets against objects that really exist in your catalog.
Is the analysis generated by AI, or can I trust the numbers?
The analysis is computed, not generated. Dependencies, impact, lineage and environment differences come from a deterministic engine that reads your data dictionary and parses your PL/SQL: the same schema and the same question produce the same answer every time, and every object in a result is one that exists in your catalog. AI is a separate, optional layer that runs on top of a finished deterministic result. The AI Deep Scan explains the result, resolves the cases the engine itself flagged as ambiguous (such as dynamically built SQL); AI assistant writes documentation and drafts code. Every claim it makes is checked against real dictionary objects. You can turn the AI off.
Do I need to open a port or change my firewall?
No. The local connector agent only makes outbound connections, like a browser. If your network allows outbound HTTPS, the connector works.
Can the product modify or delete anything in my database?
No. The local connector agent blocks every non-read statement before it reaches your database, inside your own network. Running it with a read-only database account adds a second, database-enforced guarantee.
What is processed on your servers and what do you actually store?
There is an important difference between the two. To run an analysis, schema structure (object names, column definitions, code, dependency information) is fetched on demand through the local connector agent's tunnel, processed in memory, and discarded: we keep no copy of your schema or your code. Never table contents, never your database credentials. What we do store is your own workspace: your analysis history (which tool ran, on which object), your AI conversations, environment-comparison snapshots (stored as content fingerprints, not raw code), and any documents you explicitly upload. All of it is yours, scoped to your organization, and physically erased if you delete it.
Do I need a paid AI subscription to use the AI features?
No. AI features need an API key from a provider of your choice (BYOK), and several reputable providers hand out a key in minutes with a free tier that is plenty for evaluation. Without a key every non-AI feature (dependency graphs, impact analysis, lineage, schema comparison) works normally.
What does the AI see, and who pays for it?
AI is bring-your-own-key: SchemAxis acts as a secure relay to the provider you configured, under your key and your billing. The AI receives only the schema metadata and code context needed to answer, never business data. We don't retain those payloads beyond the conversation you see in your chat history, nor use them for anything else, nor train any model on them. The provider account is yours, so its own retention and training terms are ones you accept and can verify directly; if that is still too much exposure, the same features run against a model hosted inside your own network. Without a configured key, AI features are simply off.
How do I instantly cut off the product's access to my database?
Stop the local connector agent's process on your machine, since it is the only path to your database, all access ends immediately. Alternatively, revoke or regenerate its token from the Connections page: a revoked token disconnects a live connector within seconds.
What does it cost during the closed beta?
Nothing. Design partners use the full product free of charge, with no credit card and no obligation, and pricing is announced before general availability.
How do I get access?
Access is by invitation during the closed beta. Submit your email address through the request form on this site; eligible requests receive an access code by email, which is what unlocks account creation. The only data the form requires is the email address the code is sent to.
Evaluating us for a security review? Everything a reviewer asks for is on the security page.
Request early access
SchemAxis is in Closed Beta: leave your email and, if eligible, you will receive your access code to register.
- · The email address is the only thing we ask for.
- · Free during the closed beta. No credit card. We review new requests every week.
- · No sales call, no demo booking, no phone number.
Already have an access code? Create your account.