OvalEdge is a data catalog and governance platform that connects to the systems you already run, crawls their metadata, builds column-level lineage from query history and code, and presents the result as a searchable catalog with a business glossary, classification and access workflows on top. It is not a database and it does not store your data.
That last sentence is the single most common misunderstanding in evaluation meetings, so it is worth expanding before anything else.
Is OvalEdge a database?
No. OvalEdge stores metadata — the description of your data — not the data itself.
Concretely, it holds table and column names, data types, row counts, profiling statistics, query patterns, ownership, business definitions, classifications and lineage relationships. It does not hold your customer records. When a user searches for "loan balance" and finds the column, OvalEdge tells them which system it lives in, what it means, who owns it and how to request access. Retrieving the actual values still happens in the source system, under that system's access controls.
There is one deliberate exception. Profiling — computing null rates, distinct counts and value distributions — requires reading data, and sampling for preview requires holding a small sample. Both are configurable, and in institutions with strict data handling requirements both are typically restricted or disabled for sensitive assets during the security review. That configuration decision is worth making explicitly at design time rather than discovering during an audit.
The practical consequence: OvalEdge does not replace your warehouse, your lake or your operational systems. It describes them. The broader argument for why an organisation needs that description layer at all is in what a data catalog is.
What does the architecture look like?
Four components, and understanding the split makes the deployment conversation much shorter.
The metadata repository. A relational database holding the catalog itself — assets, relationships, glossary terms, classifications, lineage edges, audit records. This is a normal database you run and back up like any other. In an on-premise deployment it sits on your infrastructure.
The crawler and connector layer. The component that reaches out to source systems, reads their system catalogs, and writes what it finds into the repository. Crawlers run on a schedule, and each connector understands the metadata model of its source — the way to enumerate schemas in Oracle differs from the way to do it in a Hadoop cluster or an S3-compatible object store.
The application and search layer. The web application users interact with, plus the search index that makes discovery fast. Search quality is what determines adoption, because a catalog people cannot search is a catalog people do not open.
The lineage engine. The component that parses SQL, ETL definitions and query logs to derive how data moves between assets. This is the part with the most engineering depth behind it, and the part whose output most differentiates catalogs in practice.
The deployment topology follows from this split: the repository and application are yours to run; the crawlers need network paths to each source; nothing needs an outbound internet route at runtime.
How do the crawlers actually work?
The crawler connects to a source with a service account, enumerates its metadata, and writes the results to the repository. What matters in practice is what that service account needs to be able to do.
For most relational sources, read access to the system catalog is sufficient for structural metadata — schemas, tables, columns, types, constraints. Profiling needs read access to the data itself. Query-log-based lineage needs access to whatever the source uses to record executed statements.
Three practical points that come up in every security review:
The permissions are read-only. The crawler does not write to source systems. This is usually the first question a DBA asks and the answer that unblocks the engagement.
Crawl scheduling matters on production systems. A full crawl of a large estate is not free, and profiling in particular reads data. Scheduling crawls outside business hours, and scoping profiling to selected assets, is standard practice rather than an optimisation.
Incremental crawling is what keeps the catalog current. A catalog refreshed quarterly describes an estate that has moved on. Daily incremental crawls with a weekly full crawl is a common pattern, and the freshness question is worth settling during the proof of concept rather than after rollout — a stale catalog is the most common way catalogs die.
The connector inventory covers the usual enterprise sources — relational databases, warehouses, Hadoop and object storage, BI tools, ETL platforms and file systems — and the exact list changes with each release.
[[TK: confirm the current OvalEdge connector count and the specific connectors validated in Yukon Labs engagements — core banking systems, 1C, SAP, and any local platforms — before publishing a number here.]]
The list is maintained on the OvalEdge product site, and connector validation against your actual source versions is the first phase of any implementation, because version mismatches are the most common early surprise.
How is lineage built?
Three mechanisms, used together, and the distinction matters when evaluating any catalog.
Parsed from SQL and ETL definitions. Views, stored procedures, ETL job definitions and transformation scripts declare how data moves. Parsing them yields lineage that is accurate to what the code says.
Derived from query history. Where the source system logs executed statements, those logs reveal actual data movement, including movement that no ETL definition describes — the ad-hoc CREATE TABLE AS SELECT that became a permanent dependency.
Declared manually. For movements crossing systems the catalog cannot observe — a file exported and re-imported, a process running outside the estate — a person records the edge.
The reason to care about the mix: catalogs that rely mainly on manual declaration produce lineage that is complete on day one and wrong by month six. Automated derivation is what makes lineage a live artefact rather than documentation, which is why it is the capability to test hardest during evaluation, and why the comparison in OvalEdge vs Collibra vs Alation spends most of its time there.
Column-level rather than table-level lineage is the standard to hold out for in a regulated institution, because the question an examiner asks is about a specific reported figure, not about a table.
Which deployment models are available?
Three, and the choice is usually made on data residency grounds rather than technical ones.
On-premise. The repository, application and crawlers run entirely on your infrastructure. This is the normal model for banks and state institutions in Azerbaijan, for the reasons set out in data residency and personal data law: metadata about personal data is itself sensitive, and column names alone can reveal a great deal about what an institution holds.
Cloud. Vendor-hosted, appropriate where the estate is already in a public cloud and residency permits it.
Air-gapped. A variant of on-premise with no outbound connectivity at all. This works because nothing in the runtime architecture requires internet access — crawlers talk to internal sources, the application serves internal users. What air-gapping does affect is the update path: releases and connector updates arrive as artefacts through whatever controlled process the institution already uses for software, and that process needs to be agreed at the start rather than at the first upgrade.
The pattern in supervised institutions here is on-premise with restricted profiling on classified assets, and it is worth designing for that from the first workshop.
How does access control work?
Two distinct layers, and confusing them causes real problems.
Access to the catalog determines who can see metadata: which assets appear in search, whose glossary terms are visible, who can view lineage. Metadata is not automatically public — in a bank, the existence and column structure of certain tables is itself restricted.
Access to the data remains the source system's decision. OvalEdge can carry the request workflow — a user finds an asset, requests access, the request routes to the owner, the decision is recorded — but the grant is executed in the source system. The catalog produces the audit artefact; it does not become a second authorisation authority.
That request-and-record workflow is where the catalog produces the evidence an examiner asks for, and it is one of the seven practices that hold up under supervision.
What does an implementation involve?
A first implementation typically runs eight to twelve weeks, and the shape is consistent.
Weeks 1–2 — discovery and connector validation. Which systems are in scope, what versions they run, what network paths exist, what the security review requires. This phase surfaces the surprises: an unsupported database version, a system whose owner did not know it was in scope, a network segment with no route.
Weeks 3–4 — deployment and first crawl. Repository and application stood up, service accounts provisioned, first crawls executed against a subset. The output of this phase is a populated technical catalog, which is often the first time anyone has seen the estate enumerated in one place.
Weeks 5–6 — glossary and ownership. The business layer: critical data elements defined, terms approved, owners and stewards assigned to assets. This phase is where the engagement succeeds or fails, and it is organisational work, not configuration.
Weeks 7–8 — classification and lineage validation. Classifications applied, lineage checked against known flows — pick a report whose derivation people already know and verify the graph matches.
Weeks 9–10 — workflows and adoption. Access request workflows, stewardship queues, search tuning, and getting the first cohort of analysts using it daily.
Weeks 11–12 — handover and measurement. Operating cadence established, coverage metrics baselined.
The failure mode to guard against is spending all twelve weeks on the technical phases because they are tractable, and leaving ownership until the end. A technically perfect catalog with no owners is a level 2 artefact, in the terms used by the data governance maturity model.
Where does it sit alongside query engines and AI?
Two adjacencies worth understanding.
With a federated query engine. A catalog describes and governs; an engine like Starburst queries across sources without moving data. They solve different halves of the same problem, and they compose well: the catalog says what a column means and who may see it, the engine executes the join. Neither substitutes for the other.
With enterprise AI. When an AI system retrieves internal data as context, the catalog's classification becomes a runtime input — what an assistant may surface depends on how the underlying asset was classified and who the user is. Organisations that deploy AI on an uncatalogued estate discover this late, which is a recurring theme in enterprise AI in Azerbaijan.
Key points
- OvalEdge holds metadata, not data. Profiling and sampling are the configurable exceptions, and both are usually restricted for sensitive assets.
- Four components: metadata repository, crawler and connector layer, application and search, lineage engine.
- Crawler service accounts are read-only; schedule crawls off-hours and scope profiling deliberately.
- Lineage comes from parsed SQL, query history and manual declaration. Test the automated share hardest during evaluation.
- On-premise, cloud and air-gapped deployments are all supported; air-gapping mainly changes the update path, which should be agreed up front.
- Catalog access and data access are separate layers. The catalog carries the request workflow and produces the audit artefact; the source system still grants.
- A first implementation runs eight to twelve weeks. Do the ownership work in parallel with the technical phases, not after them.
Yukon Labs implements OvalEdge on-premise in Azerbaijan, including air-gapped environments. A readiness assessment is the usual starting point, because connector validation and ownership are what determine the timeline. For the regional framing, see data governance in Azerbaijan.