VIA
VIA maps every table, column, join and transformation in your Oracle warehouse into a graph you can walk. Column-level lineage that takes a senior engineer over an hour to resolve by hand in five to ten minutes — and you can ask what it looked like on any date in the past.
We will trace one of your own columns end-to-end on a live warehouse. Yours, or a sample of ours if you would rather not share one yet.
The Client’s Situation
When someone questions the number
A figure comes up in a meeting and somebody asks where it came from. The honest answer is that it depends on a chain of ETL mappings, and finding out means reading SQL until you reach the origin. For a senior engineer that is roughly an hour of work per column, and it is never an hour anybody had planned.
The same missing map causes three more problems. A schema change goes in, and the downstream breakage gets discovered by the people whose reports stopped working. A regulator asks how a figure was calculated during a period two years ago, and a warehouse that only knows its current state cannot answer a question about the past. And eventually the person who understood how it all fitted together leaves, taking the only copy of the map with them.
None of this is really a documentation problem, in the sense that no amount of documentation discipline would solve it. A warehouse running thousands of ETL processes changes faster than anyone can write it down.
What changes once the warehouse is mapped
Talk to usTracing takes minutes rather than an afternoon
Column-level lineage resolves in five to ten minutes where working it out by hand runs over an hour, which is the difference between answering the question and adding it to a backlog.
You can ask about the past
Every mapping, join and transformation is versioned rather than overwritten, so lineage can be viewed as it stood on any date. This is the only honest way to answer an audit question about a closed reporting period.
Impact is known before the change, not after it
Every downstream table and column a proposed change would touch, visible in advance. Incident analysis that used to take hours becomes a question you ask first.
The knowledge stops living in people
What a handful of experts understood about how the warehouse fits together becomes queryable, and stays behind when they move on.
Analysts answer their own lineage questions
Exploring the graph needs no SQL, which takes a steady stream of tracing requests off the engineering queue.
What VIA does
1
Column-level lineage
Resolves complex SQL expressions recursively rather than stopping at object-level links, with filters and join conditions included in the resolution.
2
Historical lineage
Every mapping, table, join and column transformation versioned with effective dates. Temporal graph snapshots are created automatically, so any past date can be queried without an archive restore.
3
Impact analysis
The full downstream reach of a proposed change to any object, before the change is made.
4
Interactive exploration
The property graph rendered in APEX and traversable in any direction, by people who do not write SQL.
5
Incremental refresh
Only changed mappings reprocessed, which is what keeps a routine catalogue refresh down to minutes at scale.
Turn your data into a competitive advantage.
Whether you’re trying to prove marketing performance, modernise enterprise reporting, or build a stronger data strategy, we’ll help you create analytics that deliver measurable business value.
Four steps, then it maintains itself
It reads your ETL metadata
VIA takes metadata from your ETL source and detects which processes are new or changed. Only what has actually changed gets reprocessed.
It builds a property graph
Raw ETL expressions become a network: tables and columns as nodes, transformations, joins and filters as the edges between them.
It resolves lineage column by column
The inference engine traverses the graph, working through SQL expressions hop by hop until every column’s true origin is known. Not table to table — column to column, through the expressions that changed it on the way.
You explore it by clicking
An interactive graph inside Oracle APEX. Pan, zoom, follow a column upstream or downstream, move to a date in the past. No SQL at any point.
A warehouse with thousands of ETL mappings is a city nobody has mapped. VIA surveys every street, records what connects to what and when it changed, and lets anyone walk it without needing to read the plans.
Deployment is an initial load to build the full graph, then incremental loads — daily, weekly or monthly — that pick up only what has changed. Routine refreshes complete in minutes even on warehouses with thousands of mappings, and the scheduled operations are largely self-maintaining.
Data & Analytics
What VIA does that a data catalogue does not
Trace one of your own columns
Thirty minutes, a live warehouse, and one column of your choosing followed from where it is reported back to where it began. If you would rather not point us at your own environment on a first call, we will use a sample warehouse instead.
What do our clients say?
Want to hear more from us?
For insights and updates straight your inbox. No spam, unsubscribe at any time.
Questions we are asked
Do we need to install or licence any external software?
No third-party software and no VIA licence fee. VIA runs as a plug-in inside your existing Oracle database, on cloud or on premise, so there is no new vendor to bring in. To be clear about what that does not cover: VIA uses Oracle Database, APEX and Property Graph, and your Oracle licensing remains your own.
Does it work with PL/SQL?
Not yet. VIA currently reads ETL metadata, and support for lineage held in legacy PL/SQL is on the roadmap rather than in the product. If a significant part of your transformation logic lives in stored procedures, tell us at the demo and we will be straight with you about what VIA would and would not cover today.
How is this different from a third-party data catalogue?
Most catalogues also work from metadata, and most stop at table-to-table links. VIA resolves lineage recursively through the SQL expressions themselves, including filters and join conditions, renders the result as a property graph you can traverse in any direction, and versions every change so you can see how lineage looked on any past date.
How does the time travel work?
Every mapping, table, join and column transformation is versioned with effective dates, using the same slowly-changing-dimension pattern a warehouse already uses for its own history. Temporal snapshots of the graph are created automatically. You pick a date in the interface and see lineage as it existed then, with no manual export and no archive restore.
How long does a refresh take on a real warehouse?
Minutes, including on warehouses with thousands of ETL mappings. The incremental engine compares the current ETL state against the last known state and reprocesses only the mappings that have actually changed, which is what stops a routine refresh becoming an overnight job.
What does deployment involve?
You provide your ETL metadata, VIA loads it and builds the full lineage graph once. After that, incremental loads run on whatever schedule suits you — daily, weekly or monthly — and pick up only what has changed. Routine operations are scheduled and largely self-maintaining.
Trace one of your own columns
Thirty minutes, a live warehouse, and one column of your choosing followed from where it is reported back to where it began. If you would rather not point us at your own environment on a first call, we will use a sample warehouse instead.
London Office
51 Lime Street
c/o HCR Law LLP
London EC3M 7DQ
United Kingdom
Zagreb Office
Centar 2000
Radnicka cesta 37a
10000 Zagreb
Croatia
Tell us which Oracle version you run, which ETL tooling your pipelines are built in, and roughly how many mappings you are dealing with. An engineer will come back to you.
"*" indicates required fields