Starting with the 2026.4 release, the Hyperscale experience in DCT has changed. The previous read-only Hyperscale reporting UI and its separate “Hyperscale job” object are retired. If you currently rely on that UI, contact your account team about migrating to the model described below.
Hyperscale is no longer a parallel object model alongside Continuous Compliance. Instead, it is integrated directly into the standard Compliance experience in DCT, so the same connectors, rule sets, algorithm assignments, and jobs used for Continuous Compliance are also used for Hyperscale. The only thing that changes is where a job executes.
What's changed
Previously, a Hyperscale dataset bundled source and target connector information with a defined schema in a single object. That object is retired, and its components now exist in the same locations used for standard Compliance:
|
Previously (Hyperscale dataset) |
Now |
|---|---|
|
Source and target connector info |
Connector (onboarded like any Continuous Compliance connector) |
|
Schema/inventory definition |
Rule set and algorithm assignments |
|
Runtime parameters (engines, memory, split size) |
Job, with Hyperscale-specific runtime settings |
If you are using terminology from the previous model, "dataset" no longer refers to a distinct object. It remains a useful shorthand for what was previously bundled together, but it does not correspond to any object in the current UI.
Why converge the two experiences
-
Shared, auto-aligned resources. Connectors, rule sets, and algorithms are managed once and referenced by both Compliance and Hyperscale jobs, keeping referential integrity intact across both workload types without separate upkeep.
-
Platform benefits. Hyperscale inherits DCT’s access control and user management, along with a unified UI, CLI, and API, the same interface layer every other Delphix product in DCT uses.
-
Discrete admin and end-user experiences. Setting up Hyperscale infrastructure and running a job on it are separated by role, covered in the two sections below.
-
Optionality. For a data source that supports both, the same job can run on a standard Compliance engine or a Hyperscale Orchestrator, chosen at run time. This is bounded by what infrastructure an admin has provisioned (see Hyperscale Administration).
-
Central reporting for auditability. Every job for a data source, regardless of which infrastructure ran it, is tracked centrally alongside the algorithms it used, giving you one audit trail instead of two.
Job execution states
Whether a job runs on a Job Orchestrator or a Hyperscale Orchestrator, its execution moves through the same states:
|
State |
Applies to |
Description |
|---|---|---|
|
Pending |
Hyperscale executions |
The execution has been created but not yet submitted for placement |
|
Submitted |
Compliance & Hyperscale |
The job has been initiated but not yet assigned execution capacity |
|
Queued |
Compliance & Hyperscale |
The job is waiting for available execution resources |
|
Running |
Compliance & Hyperscale |
The job is actively executing |
|
Completed |
Compliance & Hyperscale |
The job finished successfully |
|
Failed |
Compliance & Hyperscale |
The job stopped because of an error |
|
Cancelled |
Hyperscale executions |
The execution was stopped before completing, by a user or the system |
Cascading configuration priorities
Runtime settings (split size, table-level configuration, and similar) can be set at three levels, each overriding the one before it:
-
Orchestrator defaults — the base configuration applied to all newly created jobs on that Hyperscale Orchestrator. Set by an admin.
-
Job defaults — job-specific settings that override the orchestrator default. Set when the job is created or edited.
-
Runtime override — applied at job run time by a power user optimizing a specific execution; updates the job’s defaults going forward rather than applying just once.