You're on IBM Netezza: It Runs the Warehouse Workloads You've Trusted for Years. Data Workers Owns Whether What It Serves, and What Leaves It, Is Right
Netezza runs your long-standing warehouse workloads on appliance, SaaS or BYOC. Data Workers watches what Netezza serves and what you offload to watsonx.data or Snowflake, and holds each wave's gate behind approvals.
Your nightly numbers come out of IBM Netezza. Data slices and zone maps keep the big scans fast, and years of nzsql scripts, nzload jobs and stored procedures build the marts that Cognos, MicroStrategy and the regulatory extracts read every morning. IBM sells it as Netezza Performance Server on four footings: the Netezza Appliance in your data center, Netezza SaaS, Netezza SaaS BYOC on AWS or Microsoft Azure, and software-only. And since IBM added open table formats, part of the estate now reaches Apache Iceberg tables in watsonx.data, IBM's open lakehouse.
That is where most Netezza teams are today: mid-move. Every wave copies numbers out of an engine that has been right for a decade into one that hasn't been proven yet. Netezza runs the workload. Data Workers owns whether what it serves, and what leaves it, is right: it reads the checks each load and offload records, tracks each wave's parity checks, traces a wrong number to its cause across every system around Netezza, and keeps the wave's gate closed until the owner signs off.
Key takeaways
- •Netezza keeps its job. The engine, your
nzsqlandnzloadjobs and the Database Assistant stay as they are. Data Workers works on whether the data they produce and offload is right. - •What leaves Netezza gets checked as hard as what stays. Each offload wave has parity checks planned and tracked, and the gate stays closed until a named owner signs it.
- •Row counts are only the first check. Data Workers proposes comparison queries on the values that matter (sums and scales per business date), so a type mapping that shaves a fraction of a cent off two million rows gets caught on the first night.
- •Changes go to a named owner. Mapping fixes arrive as a diff, table rebuilds as a statement the owner runs, and reruns queue through your orchestrator after approval. Every step leaves a receipt.
- •Any target, one loop. Whether a wave lands in watsonx.data or Snowflake, the same incident loop covers both sides while the move runs.
Netezza runs the warehouse workloads you've trusted for years. Data Workers owns whether what it serves, and what leaves it, is right.
Netezza answers the query it's given, fast. Whether the lakehouse copy matches it is a different job: know which checks define "the same", notice the one that drifts, connect it to a change Netezza never sees, stop the wave, get the fix made where it lives and prove the result. Here is one night at a mortgage servicer in week two of a Netezza to watsonx.data move. This is an illustrative example.
The stack: Netezza SaaS BYOC in the servicer's AWS account holds the loan book. The stored procedure LOANS.SP_DAILY_ACCRUAL computes each loan's daily interest into LOANS.DAILY_ACCRUAL, with ACCRUED_INT as NUMERIC(19,6) because the general ledger posts month-end interest from the summed daily values. Wave 2 offloads that table nightly: an Airflow 2 DAG, offload_loans_wave2, submits a Spark application on watsonx.data that reads Netezza over JDBC and writes the Iceberg table lake.loans.daily_accrual on Amazon S3, using a type map kept in the offload repository on GitHub. A Presto view on that table feeds a new Cognos Analytics dashboard, "Interest income MTD", which treasury is piloting for its 08:00 liquidity call. The DAG's last task runs the three wave 2 parity checks the team agreed with Data Workers, as one query inside Netezza (which reads the Iceberg table through its lakehouse connection), and records each result with monitor_metrics. The DAG and the Spark job send OpenLineage events to Marquez. Tickets live in Jira Service Management, alerts go to Microsoft Teams, approval requests go by email. The wave owner is due to sign the wave 2 gate on Friday at 10:00, which retires the old Netezza extract to treasury.
| Time | System | What happens |
|---|---|---|
| Thu 16:30 | GitHub | A developer merges a cleanup of the offload type map: every money column now maps to decimal(19,2), "to match the reporting standard". The loader casts by dropping extra digits |
| 22:00 | Netezza | SP_DAILY_ACCRUAL writes 1,912,406 rows for Thursday's accrual date. Total accrued interest: $4,118,302.52 |
| 23:15 | Airflow + Spark on watsonx.data | offload_loans_wave2 writes 1,912,406 rows to lake.loans.daily_accrual with ACCRUED_INT as decimal(19,2). Every task succeeds |
| 23:48 | Netezza | The parity task joins the local table with the lakehouse table: row count per accrual date, total principal, total accrued interest. It records each result with monitor_metrics |
| 23:50 | Data Workers | The recorded results: rows equal, principal equal to the cent, accrued interest $4,108,741.30 in the lakehouse against $4,118,302.52 on Netezza, short by $9,561.22. Data Workers flags the failed interest check, keeps the wave 2 gate closed and opens an incident |
| 23:56 | Data Workers | diagnose_incident works from the recorded checks and the DAG run: no rows are missing and the gap averages half a cent per row, which points at scale in the offload, not lost data. get_incident_history finds no earlier case |
| 00:04 | Data Workers | blast_radius_analysis walks the context graph, where the team registered the Presto view and the dashboard: the Iceberg table feeds the treasury dashboard and nothing else yet. Friday's gate would retire the extract treasury still uses |
| 00:08 | Jira SM + Teams | create_jira_sm_ticket opens a ticket with the evidence; send_teams_alert posts a card to the migration channel. The approval request goes by email to the wave owner, with the treasury reporting lead and the lakehouse owner copied |
| 00:20 | Netezza + GitHub | The on-call data engineer compares the two definitions (NUMERIC(19,6) on Netezza, decimal(19,2) in Iceberg) and finds the 16:30 type-map merge. The cause goes on the incident |
| 07:20 | Cognos Analytics | The treasury reporting lead holds the 07:30 dashboard refresh; the liquidity call uses the Netezza extract |
| 07:35 | Spellbook | The wave owner reviews one plan: a diff to the type map that keeps each source column's precision and scale; because Iceberg can widen a decimal's precision but never change its scale, a statement for the lakehouse owner that recreates daily_accrual with decimal(19,6); a rerun of offload_loans_wave2; and the checks to repeat. She approves |
| 07:50 | GitHub | The data engineer merges the diff |
| 08:05 | watsonx.data | The lakehouse owner runs the approved statement in Spark SQL |
| 08:12 | Data Workers + Airflow | Data Workers queues the approved rerun with trigger_airflow_dag and reads the run's status |
| 08:55 | Airflow + Netezza | The offload succeeds; the parity task repeats the three checks and records them |
| 08:57 | Data Workers | All three match: 1,912,406 rows, principal and accrued interest equal to six decimals. Data Workers marks the check passed and leaves the gate for the owner |
| 10:00 | Spellbook + Jira SM | The wave owner signs the wave 2 gate with the full parity record. Data Workers writes the receipt (cause, approvals, diff, statement and who ran it, rerun, checks passed, undo) and links it from the Jira SM ticket, which the service desk resolves. The approved fact "offloads keep the source scale on money columns" lands in the Context Wizard graph |
| 10:15 | Cognos Analytics | Treasury releases the dashboard on the corrected table |
Every system did its job. The miss lived between them: a mapping file nobody thought of as a data change, and a dollar figure that only matters when two million rows are summed. A wave plan that compares only row counts would have passed this night.
| Job | What Netezza does | What Data Workers does |
|---|---|---|
| The run | Computes, loads and serves the nightly workload; reads Iceberg tables through its lakehouse connection | Reads the orchestrator's runs and the checks each load and offload records |
| The signal | The web console, Advanced Monitoring and the Database Assistant tell the DBA how the engine is doing | Metrics and parity checks the team defines tell the owner whether the data is right on both sides |
| The diagnosis | Query history shows what ran and how long it took | Joins the recorded checks, the DAG run and the lineage into one incident, with the blast radius |
| The fix | Runs whatever procedures and statements the team deploys | Proposes the mapping change as a diff and the rebuild as a statement for the owners to approve and run |
| The rerun | Serves the reads the offload sends | Queues the approved rerun through Airflow and reads its status |
| The gate | Keeps serving the source until the team retires it | Tracks every wave's checks and holds the completion gate until the owner signs |
Why doesn't Netezza just do this itself?
Because Netezza is built to run a demanding warehouse workload fast and predictably. Its unit is the query, the table and the system. It knows SP_DAILY_ACCRUAL finished at 22:00; it has no reason to know what a Spark job on another platform did with that table an hour later.
IBM's AI follows that scope. The Netezza Database Assistant, generally available and powered by IBM watsonx, helps DBAs manage the database. The August 12, 2026 Netezza SaaS release (11.3.1.3) added a built-in vector data type, unstructured data processing on AWS SaaS and BYOC, Advanced Monitoring, and IBM Netezza Nexus, an open lakehouse catalog built on the Apache Iceberg REST Catalog specification, as a private tech preview. Around it, watsonx.data runs Presto and Spark over Iceberg, and watsonx.data integration, which now carries DataStage's capabilities, builds pipelines from natural-language descriptions.
Owning whether the numbers survived a move across Netezza, an offload repository, Spark, Iceberg, a dashboard and a ticketing system is a different product: a context graph across every system, parity checks per wave, blast-radius scoping, approvals that name a person, a recorded undo and receipts an auditor can read. An engine that rewrote another team's mapping files, or decided when a wave was done, would take on liability it was never designed to carry, and a move needs a referee that sits with neither the source nor the target. That product is Data Workers. More in is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
Netezza owns running the warehouse workloads your enterprise depends on. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the Netezza estate already there.
| Stage | Data Workers | Netezza | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | The system catalog describes what lives in Netezza, and the lakehouse connection and Nexus (private tech preview) reach Iceberg tables. Data Workers keeps one governed context graph across Netezza and every system around it. |
| Analytics & Insights | 8 | 8.5 | Netezza's home stage: massively parallel SQL with zone maps and in-database analytics for the nightly workload. Data Workers answers data questions from governed definitions on top. |
| Data Quality | 8 | 4 | Constraints and the team's own SQL checks run when someone writes them. Data Workers reads the checks each load and offload records, against baselines, after every run. |
| Observability & Incidents | 8.5 | 3 | The console and Advanced Monitoring watch the engine's health, not the business number. Data Workers diagnoses the data incident across the load, the offload and the reports, and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 5 | nzload, external tables and the object storage connectors load data; the schedule usually lives in Airflow or DataStage. Data Workers queues the approved rerun through the orchestrator. |
| Schema & Migration | 8 | 4 | Netezza runs the schema it's given, and moving off it is not its job. Data Workers plans moves off Netezza in approved waves, with parity checks planned and tracked and a gate the owner signs. |
| Governance & Access | 8.5 | 5 | Users, groups and object privileges govern who reads what inside Netezza. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 6 | Encryption, SSL/TLS with hostname verification and IAM-based bucket access on BYOC protect the engine. Data Workers leaves a receipt on every data change across systems. |
| Cost / FinOps | 8 | 4 | Appliance capacity and SaaS auto-pause shape what Netezza costs. Data Workers traces Snowflake credits to the dbt model for any workload that moves there. |
| MLOps & Models | 7.5 | 4 | In-database analytics and the new vector type support models close to the data. Data Workers keeps the data under those models healthy. |
How Netezza and Data Workers work together
Data Workers connects to Netezza over its SQL interface today, with a dedicated read-only user your DBAs create and can see in the query history. It connects to watsonx.data and Cognos Analytics over their APIs. Procedures, statements and offload code stay with your team: a mapping fix arrives as a diff for the owner to merge, a table rebuild or cleanup as a statement the owner approves and runs. On the rest of the estate, Airflow (DAG runs and task instances), Jira Service Management, Microsoft Teams and Snowflake connect natively; the full list is on Data Workers integrations. For agent access in general, see read-only warehouse access for LLM agents.
Engineers can run the agents in the assistant they already use. Setup follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client's MCP configuration.
// Example: Data Workers agents in one client config
// (Claude Desktop-style mcpServers block, per the client setup guide)
{
"mcpServers": {
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-connectors": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-connectors"] }
}
}List the tools with your client's own command (for example /mcp in Claude Code). In this incident: monitor_metrics, diagnose_incident and get_incident_history (dw-incidents); blast_radius_analysis and trace_cross_platform_lineage (dw-context-catalog); trigger_airflow_dag, create_jira_sm_ticket and send_teams_alert (dw-connectors).
Through a move. The Data Migration agent plans each wave with its parity checks from the object inventory your team exports, proposes the comparison queries your team runs, tracks the results and holds the completion gate for the owner's sign-off. Netezza helps: because it reads Iceberg tables through its lakehouse connection, many parity checks run as one query inside it. When a wave's target is Snowflake, Data Workers reads Snowflake natively on that side; see Data Workers on Snowflake, Apache Iceberg explained and migration agents for legacy modernization.
In production the agents run in your infrastructure and hold the database credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. Finance finds the gap at month-end close, weeks after the extract was retired.
- •L1 observe. Data Workers flags the interest check at 23:50 with the evidence and blast radius, and the gate stays closed. Nothing changes.
- •L2 propose. Data Workers proposes the mapping diff, the rebuild statement and the rerun, and recommends the dashboard hold. Nothing reaches production until the named owner approves; an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For a class with a clean record, Data Workers carries out reversible steps inside the domain you open, such as queuing the approved rerun, and sends any failed check to a person. Rebuilds stay with the owner.
- •L4 autonomous. For a scoped domain, Data Workers reads each wave's checks as the offload ends, and the fix is waiting for the owner before anyone opens the dashboard.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •Wave sign-off becomes a record, not a meeting. Each wave carries its planned checks, every night's results and the owner's signature, so "is wave 2 done?" has one answer.
- •The DBA stops being the referee. When the source and the copy disagree, the incident arrives with the evidence, not a request to prove the engine right.
- •Mapping files get treated like data changes. A type map, a cast or a view definition that changes what lands on the target is checked like any other change.
Keep Netezza, or consolidate?
Keep Netezza if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
The engine is your platform decision, and Data Workers supports it either way. Teams staying on Netezza consolidate the tooling around it: check scripts copied into every procedure, spreadsheets of reconciliation totals, runbooks that say "rerun and ask finance". Teams moving to watsonx.data or Snowflake run the move through Data Workers, so each wave has a plan, tracked parity checks and a signed gate. For other legacy engines in the same estate, see you're on Teradata; where PowerCenter loads them, you're on Informatica PowerCenter; where Airflow schedules the offloads, you're on Airflow. Banks and insurers will find the regulatory angle in the agentic data platform for financial services.
Weighing a build on JDBC and a coding agent? Running SQL on both sides is the easy part; the context graph, gates, approvals and receipts are the work. See build it ourselves with Claude Code and MCP servers.
The case for your CFO
The outcome. A number that leaves Netezza arrives the same, or the wave stops before anyone retires the source. A wrong number headed for a ledger, a regulator or a treasury call is caught the same night and corrected before anyone acts on it.
The risk story. At L0 and L1, agents only read, with a read-only Netezza user your DBAs can see. At L2 they propose and a named person approves; an unanswered request expires and escalates, never auto-grants. At L3 they act on reversible changes inside the domains you open; L4 is a later choice per domain. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. Every change carries a receipt: what changed, who approved it, the blast radius and how to undo it.
Why now. Appliance refresh decisions, IBM's push toward open lakehouse formats and the cost of running two platforms at once put Netezza moves on this year's plan.
The first win. L1 on the next wave: parity checks on the values that matter, recorded every night, with the gate held until the owner signs.
What stays the same. Netezza, your procedures and nzload jobs, the Database Assistant, your orchestrator, BI tools and on-call rota. Zero migration to start; when you move workloads, the move runs in approved waves with a design target of 4 to 8 weeks per migration instead of 6 to 12 months. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "Netezza keeps running the workloads we trust; Data Workers makes sure every number it serves, and every number we move off it, is right before anyone signs off."
Getting started
Start with a pilot. Pick the next offload wave or the Netezza tables behind the numbers regulators read, give Data Workers a read-only Netezza user and read access to the orchestrator, agree two or three checks that define "right", and run at L1 for a few weeks. Then turn on L2 for one domain, and open L3 for a narrow class once the receipts show the agents were right. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Netezza? Over Netezza's SQL interface today, on the appliance, Netezza SaaS or BYOC on AWS or Azure. Use a dedicated read-only user; your DBAs see every query it runs.
We're offloading Netezza tables to watsonx.data. What does Data Workers do in the move? It plans each wave with its parity checks, proposes the comparison queries your team runs (often as one query inside Netezza, which reads the Iceberg tables through its lakehouse connection), tracks every night's results and holds the completion gate until the owner signs off.
Will Data Workers write to Netezza or the lakehouse? It reads. Mapping and script changes arrive as a diff for the owner to merge, table rebuilds and cleanups as a statement the owner approves and runs, and reruns queue through your orchestrator after approval.
IBM has the Netezza Database Assistant. Why add Data Workers? The Database Assistant helps DBAs manage Netezza itself. Data Workers covers the operations job across the estate: whether what a load wrote and what an offload copied is right, what it reaches downstream, the fix where it lives, the approval and the receipt. Teams use both.
Does our data leave our environment? Your data stays in your systems. The agents run in your infrastructure with your credentials and model key; the hosted Conductor sees workflow metadata only, such as table names, proposals and run records.
Sources
- •IBM, Netezza Performance Server product page (appliance, SaaS, SaaS BYOC on AWS and Azure, software-only; Apache Iceberg and Parquet; Netezza Database Assistant generally available), https://www.ibm.com/products/netezza (checked Oct 3, 2026)
- •IBM Cloud Docs, Release notes for Netezza SaaS (11.3.1.3, Aug 12, 2026: IBM Netezza Nexus private tech preview, vector data type, unstructured data on AWS SaaS and BYOC, Advanced Monitoring,
setup-lh-connection; 11.3.1.1, Apr 10, 2026: hostname verification; 11.3.1.0, Feb 6, 2026: IAM-role bucket registration), https://github.com/ibm-cloud-docs/netezza/blob/master/start/release-notes.md (checked Oct 3, 2026) - •IBM Cloud Docs, Netezza with watsonx.data: overview, integrating, querying both local and remote data (Iceberg tables in Parquet, SELECT and INSERT, unsupported types), https://github.com/ibm-cloud-docs/netezza/tree/master/data_lakehouse (checked Oct 3, 2026)
- •IBM, watsonx.data (Apache Iceberg, Presto, Spark; Amazon S3 and IBM Cloud Object Storage), https://www.ibm.com/products/watsonx-data (checked Oct 3, 2026)
- •IBM, watsonx.data integration (agentic pipeline generation from natural language), https://www.ibm.com/products/watsonx-data-integration (checked Oct 3, 2026)
- •IBM, DataStage (its capabilities "are now available within watsonx.data integration"), https://www.ibm.com/products/datastage (checked Oct 3, 2026)
- •Apache Iceberg, Table spec, schema evolution (decimal(P,S) to decimal(P',S) if P' > P; scale is fixed), https://iceberg.apache.org/spec/ (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations in dw-incidents, dw-context-catalog, dw-connectors), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)