Skip to main content

​
General

Prizm is a data observability and quality platform with advanced AI capabilities. It connects to your data sources (Snowflake, Databricks, dbt, Tableau, Spark), discovers and catalogs your data assets, monitors them for quality and freshness issues, and surfaces problems as alerts and issues — before they reach downstream consumers.Prizm also provides AI-powered features for natural language querying, automated context generation, and data governance through the Model Context Protocol (MCP).
Prizm currently supports the following connectors:
  • Snowflake — full catalog, profile, observability, performance, and lineage
  • Databricks — catalog, profile, and observability
  • dbt — model metadata, job runs, test results
  • Tableau — dashboard and report catalog
  • Spark — job and pipeline observability
Additional connectors are on the roadmap. Contact the Prizm team for details on upcoming integrations.
An Alert is an automated signal generated when a monitored metric value breaches its expected threshold. Alerts are produced by the system — you don’t create them manually.An Issue is a tracked work item created from one or more related alerts. Issues can be assigned to owners, commented on, linked to external tickets (Jira, ServiceNow), and marked as resolved. Think of alerts as raw signals and issues as the actionable investigation record.
A Quality Score is a 0–100% health indicator for a data asset, computed across all active metrics. It is shown on the asset Overview tab and tracked over time so you can see whether quality is improving or degrading.A score of 100% means all active metrics are passing. A score below 100% means one or more metrics have breached their configured threshold.
In Prizm, Metric and Measure are closely related terms. A Metric is the type of check (e.g., null rate, volume, distribution, custom SQL). A Measure is a specific, configured instance of that check applied to an asset or attribute — for example, “null rate on email column must stay below 5%.” Measures are what fire alerts; metrics describe the category of check being applied.

​
Deployment & Architecture

Prizm supports two deployment models:Hybrid Agent Outbound (standard): The Prizm platform is hosted as SaaS on Azure. Lightweight agents are deployed inside your infrastructure (cloud or on-premises) and connect outbound to Prizm SaaS over WSS/443. No inbound connections to your infrastructure are required.Self-Hosted: The entire Prizm platform (UI, API, database, Ray) runs on a VM you provision, using Docker Swarm. Images are private and pulled from a registry provided by the Prizm team.
No. Prizm agents connect outbound only — they subscribe to NATS JetStream over WSS/443 and wait for tool call messages from the Prizm platform. No inbound ports need to be opened on the agent VM or Kubernetes cluster. Only outbound port 443 to the NATS host and to your data sources is required.
Agents can be deployed on:
  • AWS — EKS (kubectl YAML) or EC2 (Docker, Ubuntu)
  • Azure AKS — AKS (Helm chart) or Azure VM (Docker, Ubuntu)
  • GCP — GKE (kubectl YAML) or Compute Engine (Docker, Ubuntu)
  • On-Premises — self-managed Kubernetes or VM (Ubuntu)
Each platform has its own deployment guide under the Deployment section of this documentation.
No. Agents can be deployed on a VM using Docker. Each agent runs as a Docker container. Kubernetes (EKS, AKS, GKE, or self-managed) is the recommended approach for production and HA, but VM + Docker is a fully supported option for simpler setups.
The Prizm self-hosted stack requires:OS: Ubuntu 22.04. The Ray service is the primary resource consumer — undersizing the VM will cause Ray to restart and degrade UI performance.
Yes. Each agent type (Snowflake, Databricks, dbt, Tableau, Spark) runs as a separate container or pod and listens on a different port. They all share the same NATS connection details (NATS_HOST, NATS_PASSWORD, NATS_ENVIRONMENT) and can be collocated on the same VM or Kubernetes node pool.For production workloads, ensure the VM or node pool has sufficient CPU and RAM — approximately 4 vCPU and 8 GB RAM per active agent type is recommended.

​
Connectors & Data Sources

Prizm requires a dedicated service account with a role (PRIZM_ROLE) that has:
  • USAGE on the warehouse, databases, and schemas to monitor
  • SELECT on tables and views to profile
  • IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE for tag sync, lineage, and performance metrics (Enterprise edition required for full lineage)
  • MONITOR ON PIPE if monitoring Snowpipe pipelines
The full setup SQL is in the Snowflake Setup guide.
Yes. PRIZM_ROLE is a naming convention, not a requirement. Any role with the equivalent grants will work. However, using a dedicated role is strongly recommended — it makes auditing easier and prevents accidental privilege changes from affecting Prizm’s access.
Default schedules (current product naming — see the naming note below if you’re working from an older guide):All schedules are configurable per connector under Settings → Connectors. Jobs can also be triggered manually from the connector detail page.
Hourly is the only supported cadence Prizm documents. A 5-minute schedule was observed in testing to collect roughly every 30 minutes rather than every 5 — treat hourly as the practical floor until a supported sub-hourly minimum is published.
Yes. Each connector has Include and Exclude pattern fields in its scope configuration. Patterns support wildcards (e.g., PROD_* to include all schemas starting with PROD_, or TEMP_* to exclude temporary schemas). Assets outside the configured scope are not discovered or profiled.
Prizm does not store raw data. It stores metadata: schema information, statistical profiles (null rates, row counts, distributions), quality scores, alert history, and lineage graphs. The actual data values remain in your source systems. Credentials are stored encrypted and can optionally be managed through an external secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault).
“Catalog,” “Observability,” and “Pipeline” are the names used in some older Prizm guides and runbooks. The product and current documentation now use these names instead:If you’re following an older runbook or support ticket that references Catalog, Observability, or Pipeline jobs, use this table to map it to the current job names. See Scheduling for the complete, current job list including Lineage, Usage Summary, and Compute Metric.

​
Metrics & Alerts

Prizm supports several metric categories:Operational — Built-in checks: Volume (row count), Freshness (last modified time), Schema Change (DDL diff).Structural — Column-level checks: Distribution, Frequency, Pattern (regex/format), Statistics (mean, std dev, percentiles).Business — User-defined checks: Standalone (custom expression), Conditional (filter-then-check), Query (custom SQL), Behavioral (trend over time).Reconciliation — Cross-system checks: Comparison (value matching across tables), Lookup (referential integrity).Performance — Snowflake-specific: Credits usage, Query performance, Warehouse utilization.
Prizm establishes a statistical baseline for each observability signal (volume, freshness, schema change) using historical data. It then computes adaptive bands around that baseline. When a new data point falls outside the expected band — measured in standard deviations — Prizm fires an alert.The sensitivity of the detection (how many deviations trigger an alert) is configurable per metric. Critical assets use tighter bands; lower-criticality assets use wider ones.
Yes. Prizm supports both adaptive (anomaly detection) and fixed threshold modes. For metrics where you know the acceptable range — for example, “row count must be between 1,000 and 10,000” — you can configure fixed min/max bounds instead of relying on historical baselines.
If a business change (migration, seasonal shift, product launch) causes valid data changes that Prizm is alerting on, you have two options:
  1. Recalibrate the baseline — update the training window start date to exclude pre-change data, so the new pattern becomes the baseline.
  2. Temporarily suppress alerts — use the alert suppression window on the metric to pause alerting while the new baseline is established.
Contact your Prizm administrator to update the metric configuration.

​
Integrations

Prizm supports the following integrations:Alerting & notifications: Slack, Microsoft Teams, Google Chat, EmailIssue tracking: Jira, ServiceNowData catalog: AlationCI/CD: GitHub App, GitHub ActionSecrets management: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault (AppRole)AI / MCP: Model Context Protocol (MCP) access tokens for AI client integration
Yes. Prizm supports multiple notification destinations. You can configure routing rules based on alert priority, domain, asset criticality, or owner, and direct them to different Slack channels, Teams channels, or email recipients. Configuration is under Settings → Integrations.
When a Prizm Issue is created (from one or more alerts), Prizm can automatically create a linked Jira ticket in a configured project. The ticket includes the issue title, affected assets, severity, and a link back to Prizm. Updates to the Jira ticket status can be reflected back in Prizm. Setup requires a Jira API token and project configuration under Settings → Integrations → Jira.
MCP (Model Context Protocol) allows AI assistants such as Claude to connect to Prizm and call data quality, lineage, metric, and governance tools directly — without manual copy-paste. It is useful for data engineers, analysts, and stewards who want to query Prizm data from within an AI chat interface.To use it, generate an MCP access token in Settings → Access Tokens (with generated_for: MCP) and add the mcpServers config block to your AI client. See the MCP Access Tokens guide for full setup instructions.
Yes. Prizm integrates with AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault. When you connect using Vault, credentials are never stored directly in Prizm — they are fetched from your secrets manager at runtime. When credentials are rotated in the secrets manager, Prizm picks up the new values automatically on the next job run without any connector reconfiguration.

​
Access & Security

Prizm uses role-based access control (RBAC). Users are assigned roles that control which features, assets, settings, and actions they can access. Roles are managed by administrators under Settings → Security → Access.Prizm also supports Group-based access, allowing you to assign permissions to teams rather than individual users.
Yes. Prizm supports Single Sign-On (SSO) with major identity providers. When SSO is configured, users authenticate through your identity provider rather than the standard Prizm login form. Contact your Prizm administrator or the Prizm team to configure SSO for your organization.
The two token types are not interchangeable — an API token cannot be used for MCP and vice versa.
Token TTL is configurable at generation time. The default TTL depends on your organization’s settings. Tokens that have expired will return authentication errors — generate a new token and update any clients or configurations that use the expired one. You can view and manage tokens under Settings → Access Tokens.

​
Support

Email the DQLabs support team at support@dqlabs.ai. When reporting an issue, include:
  • The connector ID or asset URL
  • The timestamp of the failed job or error
  • Any error message shown in Settings → Connectors → Logs or in the agent pod logs
  • Your Prizm tenant name or deployment type (SaaS / self-hosted)