The digna Engine: Choose Where Your Data Is Profiled

From the beginning, digna has profiled data where it lives: the checks run inside your own database, and digna works with the results rather than with copies of your tables. For most connections that is still the right answer, which is why it stays the default.

Not every source system is a comfortable place for that work, though, and not every question can be answered inside a single database. Release 2026.11 addresses both with the digna Engine, a second place where profiling can run, and with a referential integrity check that spans two connections, even when they point at two different database technologies. The one-minute video shows both.

One setting on each database connection

Every database connection in digna now has a profiling location with two values. Source Database is the default and behaves as before, with the profiling running in the database the connection points to. digna Engine moves that work into the Engine, so the source system serves the data and the Engine does the profiling. The setting is available for every source technology digna supports, and because it belongs to the connection, you decide once per system rather than table by table.

When to keep profiling in the source database

When the checks run in the source, the data stays inside the system that owns it, which keeps the setup simple and fits policies that ask for exactly that. Analytical warehouses are also built for this kind of work, aggregating large tables close to where they are stored, so on a platform with headroom, profiling in place is often the most natural fit, with all the work in one system and one place to look when you want to know what ran and when.

When to profile in the digna Engine

The picture changes when the source is busy. An operational database that serves applications all day, a warehouse that runs close to its limits in the nightly batch window, or a platform where every query competes with business workloads are all systems where a team may want monitoring to add as little load as possible. Switching such a connection to the digna Engine keeps the profiling work off the source.

Which option is lighter depends on table sizes, network and how busy each source is, which is why the setting is per connection: you can profile in place on the warehouse with capacity to spare and use the Engine for the production system that has none, within the same digna project.

Referential integrity across connections and technologies

In digna Data Validation, a referential integrity check confirms that every key in a dataset has a matching record in the dataset it refers to. Within one database that is a straightforward comparison, but data estates rarely live in one database any more. A customer master may sit in Oracle while the orders that reference it land in PostgreSQL, or a warehouse may move from Teradata to Snowflake one subject area at a time, leaving parents and children on different platforms.

With Release 2026.11, those relationships can be checked directly, between data sources on different connections and different technologies: Teradata and Snowflake, Oracle and PostgreSQL, Databricks and SQL Server, or any other two technologies digna supports. The check works with both profiling locations, and when a connection profiles in the source database, only the key columns are exported to the Engine for the comparison. On the Dashboard, you can see when a check runs across two connections, so whoever reads the result knows it spans two systems.

Your infrastructure, whichever location you choose

Both profiling locations run on your own infrastructure, on-premises or in your private cloud, and the digna Engine runs there alongside the rest of digna. Choosing it changes where the profiling happens inside your environment, not whether your data leaves it.

The profiling documentation explains the profiling location in detail, and the Data Validation documentation covers referential integrity checks and the other rule types.

Book a demo to see both profiling locations and a cross-technology referential integrity check on your own connections.

Frequently asked questions

What is the profiling location of a database connection?

A setting on each database connection that decides where profiling runs: Source Database, the default, runs the checks inside the database itself, and digna Engine runs the profiling in the digna Engine. It is available for every source technology digna supports.

Which profiling location should we choose?

It depends on the source. Profiling in the source database keeps all the work in one place, which suits platforms with capacity to spare, while the digna Engine keeps the load off a busy source. Because the setting is per connection, you can choose differently for each system.

Can digna check referential integrity between Teradata and Snowflake?

Yes. digna Data Validation checks referential integrity between data sources on different connections and technologies, including Teradata and Snowflake, Oracle and PostgreSQL, or Databricks and SQL Server, with either profiling location.

Does our data leave our infrastructure when we use the digna Engine?

No. The digna Engine runs on your own infrastructure, on-premises or in your private cloud, like the rest of digna.