What is data governance, and what does it actually change day to day?

Data governance is the operating model that decides who owns each data asset, what it means, where it came from and who may use it. Day to day it changes four things: every important table has a named owner, contested terms like active customer have one approved definition, any figure can be traced back to its source columns, and access follows data sensitivity rather than old tickets.

What is OvalEdge — is it a database?

No — OvalEdge is not a database, and it does not store your data. OvalEdge catalogs metadata about the systems you already run — names, definitions, ownership, sensitivity and how data flows. It connects with read-only credentials, reads structure and statistics, and writes only metadata to its own store. Your data never moves, which is the answer to the first question every security review asks.

Can OvalEdge be deployed on-premise or in an air-gapped environment?

Yes — OvalEdge can be deployed on-premise or in an air-gapped environment, and that is the normal deployment here rather than an exception, which is why it survives the first filter in Azerbaijani banking and government evaluations. It needs its own database and network access to the systems it reads. Nothing requires internet connectivity at runtime.

How long does a typical OvalEdge implementation take?

A typical OvalEdge implementation takes six to twelve weeks to a working catalog for one domain, with harvested lineage and a glossary people use. Installing, connecting and harvesting take three to four weeks and are largely mechanical. The rest is the human phase — definitions, ownership, classification — which slows down in proportion to how many domains you attempt at once.

Which data sources does OvalEdge connect to?

OvalEdge ships more than 170 pre-built native connectors, covering Oracle, SQL Server, PostgreSQL, Teradata, SAP, 1C, mainframe extracts, object storage, Snowflake, Databricks and the major BI tools. Ask about your systems rather than the total, and ask specifically whether lineage is supported for each — many products can read a source's metadata but cannot parse its transformation logic.

Does a data catalog replace our data warehouse?

No — a data catalog does not replace a data warehouse. The warehouse stores and serves data; the catalog stores metadata describing that data and everything in your other systems. They are used together. Deploying a catalog changes nothing about your pipelines or reports — it makes them findable, documented and traceable.

What is the difference between a data catalog, a data dictionary and a business glossary?

A dictionary describes one database's structure for developers. A glossary defines business concepts like net exposure for the business. A catalog is the platform that spans the whole estate and holds both. What makes the catalog more than a document is the binding: each glossary concept is linked to the physical columns that implement it.

What is column-level data lineage, and why does it matter during an audit?

Column-level lineage traces a single column from its source, through every transformation, to the figure in a report — which is exactly the shape of the supervisory question show us how this number was calculated . Without it the answer is a reconstruction from memory that takes days. Insist on lineage parsed automatically from your SQL: hand-drawn diagrams are misleading within a year.

Who should own data governance — IT or the business?

Data governance is owned by the business, with heavy technical support from IT. IT can implement a catalog and harvest lineage; it cannot decide what active customer means. When governance sits entirely inside IT, definitions get made by people without the business context to make them, and the business ignores the result.

Do we need a data governance program in place before we start doing AI?

You do not need a full data governance programme before starting AI, but you do need governance on the specific data your AI will use — and that is more than most organisations have. Gartner expects over 40% of agentic AI projects to be cancelled by end-2027, with inadequate controls among the causes. Catalog and classify the one domain your first use case depends on: a few weeks, not a year.

How does OvalEdge handle Azerbaijani, Russian and English metadata in one catalog?

OvalEdge holds trilingual metadata as one canonical concept carrying a label in each language, rather than three parallel glossaries. `müştəri`, `клиент` and `customer` share no characters, so no automated matching will connect them — a person who knows the business in all three languages has to decide they are one concept. Design for this on day one; retrofitting it is expensive.

Does OvalEdge help satisfy Central Bank of Azerbaijan reporting requirements?

OvalEdge supplies the evidence CBAR requirements depend on, though no software makes an institution compliant on its own. CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on ISO/IEC 27000, expects asset ownership, classification and access control tied to it. A catalog produces that evidence from the systems themselves rather than from memory.

How do you measure whether a data governance program is working?

Measure a data governance programme by behaviour change, not by row counts. A catalog with fifty thousand documented assets and no users is a more expensive spreadsheet. The metrics that mean something: analysts checking the glossary before building a report, engineers checking lineage before changing a schema, and how long it now takes to answer a regulator's question about a figure.

What does data stewardship involve, and how many stewards do we need?

A steward is a named person in the business accountable for a set of assets: approving definitions, confirming ownership, settling disputes. Roughly two hours a week. Fewer than you expect — one per domain, so ten to twenty across a large bank. Make it part of an existing role, because a programme built around a few exceptional individuals collapses when two of them leave.

Is Yukon Labs an OvalEdge reseller or an implementation partner?

Yukon Labs is an OvalEdge implementation partner, not a reseller. We deploy, configure and operate OvalEdge inside your environment rather than selling a licence and leaving. That means connectors against your real systems, lineage validated on your own transformation code, the multilingual glossary modelled correctly from the start, and the change management that decides whether the catalog gets used.

OvalEdge vs Atlan: Catalog Comparison

Atlan leads on user experience and active metadata; OvalEdge on on-premise viability, connector depth and cost. An implementer's comparison for supervised institutions.

Atlan and OvalEdge are frequently shortlisted together, and they are built around different assumptions about where a catalog runs. Atlan is a cloud-native active metadata platform with the best user experience in its price band. OvalEdge is an on-premise-first catalog with strong automated lineage and a materially lower total cost.

For most organisations, that difference is a preference. For a bank under Central Bank supervision or a ministry handling citizen data, it is usually the whole decision — and it gets made before anyone opens a feature matrix.

Disclosure: Yukon Labs implements OvalEdge. That is a reason to read this critically and a reason it is worth reading — we deploy these systems and see where they fail. Where Atlan is the better choice, this article says so.

The filter that decides most of these evaluations

Before features, one question eliminates more options than all the others combined: can this be deployed in our own environment, as a supported first-class product?

Atlan is cloud-native by design. That is not a limitation the company apologises for — it is the architectural choice that makes the product what it is, and much of its speed and polish follows from it. But it means that where a foreign public cloud is not available for the data, Atlan usually falls out at this stage.

The objection people raise is that a catalog stores metadata rather than data. True, and insufficient. Metadata about a core banking system is itself sensitive: table names, column names, row counts and profiling statistics describe your systems in considerable detail. A complete metadata repository is an excellent map for anyone who should not have one, and security reviewers in this market treat it accordingly.

OvalEdge was built to be installed in the customer's environment and still is. On-premise and hybrid are normal deployments rather than exceptions, and that shows in how installation and upgrades are handled. If your requirement is air-gapped — no outbound internet at all — verify it by asking each vendor to describe the upgrade process without internet access. The answers separate the field quickly.

Where Atlan is genuinely better

Worth being direct about, because a comparison that finds no advantages in the other product is not a comparison.

User experience. Atlan's interface is the best in this segment. Search behaves the way analysts expect, the product is opinionated in ways that reduce configuration, and adoption among non-technical users is easier than with anything else at a comparable price. If your primary goal is analyst self-service in a large, cloud-based analytics organisation, this is a real differentiator.

Active metadata and integration depth into modern tooling. Atlan pushes metadata into the places where work happens — the query editor, the BI tool, the collaboration platform — rather than waiting to be visited. That is the difference between a catalog people consult and a catalog people encounter, and it is the direction Gartner's 2026 Magic Quadrant rewards, having weighted active metadata and automation more heavily.

Time to first value in a cloud estate. If everything you own is already Snowflake, dbt and a modern BI tool, Atlan connects quickly and looks good doing it.

Product velocity. The release pace is fast and visible.

Where OvalEdge is better

Deployment flexibility. On-premise, hybrid and air-gapped as first-class options rather than a legacy tier. For a supervised institution this is not a feature; it is the precondition.

Connector coverage for legacy systems. OvalEdge publishes more than 170 pre-built native connectors, with deliberate emphasis on legacy databases and reporting systems alongside modern cloud sources. That emphasis matters more here than in a greenfield estate, because the systems holding the regulated data in this market are usually the oldest ones — Oracle, MS SQL, SAP, 1C, mainframe extracts and the specific core banking system in place. A catalog that cannot read your core system is decorative.

Automated column-level lineage relative to price. OvalEdge parses SQL, stored procedures and ETL definitions to build column-level lineage automatically, and this is its strongest technical feature at its price point. See data lineage explained for how to test it properly.

Cost. Materially lower, with a flatter module structure — lineage, glossary, quality and access workflow are part of the product rather than separate purchases. Over three years the difference is frequently large enough to fund the stewardship function that makes governance work at all, which is the most common reason organisations in this market choose it.

Multilingual glossary modelling. One canonical concept carrying Azerbaijani, Russian and English labels, with physical columns from all three system generations bound to it. Rarely on a feature matrix, decisive here.

Where they are comparable

Honest ground, and it is more of the product than either vendor's material suggests.

Both harvest technical metadata automatically. Both hold a business glossary with terms bound to physical columns. Both support classification and sensitivity tagging. Both provide access-request workflow adequate for a normal governance process. Both will produce a searchable, populated catalog for a modern cloud estate within a quarter.

Neither will clean your data, decide which of your four customer tables is authoritative, or create ownership where management has not assigned it. And neither will be adopted without deliberate change management — a fully populated catalog with no users is the standard failure mode across every product at every price point.

How to run the evaluation

Four tests, in this order. The first two decide most cases.

Deployment. Require a description of the on-premise or air-gapped upgrade process, in writing. Not whether it is possible — how it works without internet access, and how long after a cloud release the equivalent version ships.

Lineage on your own worst code. Take your three most complicated real transformations — nested views, dynamic SQL, a stored procedure someone wrote in 2015 — and require column-level lineage for them during the proof of concept, on your own code, in your own environment. Never on vendor sample data; sample data is chosen precisely because it parses.

Your actual connectors. Not the count. Whether the specific systems on your inventory are supported natively, and what "supported" means for lineage — many products connect to a source for metadata but cannot parse its transformation logic.

Multilingual glossary. One term, three language labels, bound to columns whose names are in three different scripts, with search working from any of the three. Products that respond with a translated user interface have solved a different problem.

Which to choose

Choose Atlan if your data platform is cloud-based and will remain so, foreign cloud deployment is permitted for your metadata, analyst self-service is the primary goal, and user experience is what will drive adoption. Its interface advantage is real and worth paying for in that context.

Choose OvalEdge if you need on-premise or air-gapped deployment, your estate is legacy-heavy, you want strong automated column-level lineage without enterprise-suite pricing, and you need to show results in a quarter rather than a year.

For most banks and government institutions in Azerbaijan, the deployment constraint decides it before the other criteria are reached — which is why we implement OvalEdge. For a cloud-native company with a modern stack and no residency constraint, Atlan is a strong product and we would say so.

Key points

On-premise viability is the first filter and eliminates more options than every feature comparison combined. Atlan is cloud-native by design.
"It only stores metadata" is true and insufficient — table and column names map your estate in detail, and reviewers treat the repository as sensitive.
Atlan leads clearly on user experience, active metadata push and modern-stack integration.
OvalEdge leads on deployment flexibility, legacy connector depth, lineage-per-cost and multilingual glossary modelling.
Test lineage on your own worst transformation code, in your own environment. This separates catalogs faster than any feature matrix.
The platform is roughly a quarter of the outcome. Neither product supplies the other three quarters.

We deploy OvalEdge on-premise for regulated organisations in Azerbaijan and the wider region. Related reading: OvalEdge vs Collibra vs Alation and data catalog build vs buy.

OvalEdge vs Atlan: Catalog Comparison for Regulated Industries