You're on Vertica: It Runs High-Speed Analytics for the Teams That Depend on It. Data Workers Owns Whether the Data Behind It Is Right
Vertica runs high-concurrency analytics in Enterprise and Eon Mode, with in-database ML and an MCP server. Data Workers owns whether the data behind it is right: it catches bad loads, traces them and gets fixes approved.
Your product, finance and marketing teams get their answers from Vertica. Projections keep hundreds of concurrent queries fast, COPY and the Kafka data loader bring in events all day, and in-database machine learning runs where the data lives. Many teams run Eon Mode, with compute in subclusters and data in communal storage on S3 or an on-premises object store. The current release, 26.3, updates the Vertica MCP Server and the Unified Console with no core database changes. Vertica's current documentation lists Vertica as a trademark of Rocket Software; the 25.x documentation called it OpenText Analytics Database. DBAs live in Management Console and vsql, engineers in COPY scripts, flows and dbt models, analysts in Looker or Tableau.
The expensive Vertica incidents are the loads that succeed: zero rejected rows, a green flow, and a wrong number because something upstream changed. Vertica runs high-speed analytics for the teams that depend on it. Data Workers owns whether the data behind it is right: it checks what each load wrote, traces a bad number to its cause across the systems around Vertica, and hands the owner a fix and a run plan.
Key takeaways
- •Vertica keeps its job. Projections, subclusters, in-database models and your DBAs' grants stay as they are. Data Workers works on whether the data is right.
- •A clean COPY gets checked too. Metrics your team defines are recorded after every load, so a load with zero rejects and wrong data becomes a diagnosed incident within the hour.
- •Built around the tools you run. Prefect, dbt, Looker, PagerDuty, Slack and GitHub connect natively. Your assistant runs the Vertica MCP Server, read-only, next to Data Workers' MCP servers.
- •Changes go to a named owner. Fixes arrive as a diff, cleanups as a statement the owner runs, reruns queue through Prefect after approval, and every step leaves a receipt.
- •The same loop covers a move. Data Workers plans each wave off Vertica with its parity checks and holds the completion gate for the owner's sign-off.
Vertica runs high-speed analytics for the teams that depend on it. Data Workers owns whether the data behind it is right.
Wrong data is a different job from fast queries: notice it, connect it to a change Vertica never sees, size the damage, hold anything that would act on it, fix the cause, rerun and prove the result. Here is one evening at a mobile game studio's player data team. This is an illustrative example.
The stack: the collector writes the game client's purchase events to S3 as hourly Parquet files. A Prefect flow, iap_events_hourly, runs a COPY into game.iap_events on a Vertica Eon Mode database. The table declares a primary key on event_id without the ENABLED keyword, so Vertica stores it as DISABLED: new primary keys aren't enforced by default, a sensible choice for load speed on a high-volume fact table. A nightly flow, ua_marts_nightly, builds fct_payer_daily with dbt-vertica, Vertica's official dbt adapter, then scores seven-day lifetime value in-database with PREDICT_XGB_REGRESSOR. At 06:00 a Prefect task exports bid targets from those predictions to the studio's ad networks, and the Looker "UA performance" Explore shows return on ad spend; the dbt project declares both as exposures, and the team has recorded both in the context graph. On-call pages go through PagerDuty; approval requests reach people in Slack.
| Time | System | What happens |
|---|---|---|
| Tue 17:30 | Game client (iOS 6.2) | A phased rollout starts. The new offline purchase queue holds purchases made without a connection and sends them on reconnect, but it resends the whole queue each time the app reconnects, with the original event_id. Each receipt is valid, so the collector accepts every copy |
| 18:05 | Prefect + Vertica | iap_events_hourly runs. COPY loads the 17:00 files into game.iap_events: 0 rows rejected, because the primary key on event_id is not enforced. The flow completes |
| 19:07 | Data Workers | The flow's last task records two metrics per platform and client version with monitor_metrics, a step the team added during the pilot: the share of rows whose event_id already appears in the last 72 hours, and purchases per paying player. For iOS 6.2 the duplicate share reads 6.8% against a baseline of 0.0%, and purchases per payer read 1.42 against a band of 1.10 to 1.25. Both are flagged and Data Workers opens an incident |
| 19:12 | Data Workers | diagnose_incident classifies the flagged signals with their context (the Prefect run history, the client version tagged on each metric, no schema change): quality degradation confined to iOS 6.2, starting with the 18:05 load, most likely duplicate delivery upstream that the load accepted. get_incident_history finds no earlier case |
| 19:18 | Data Workers | blast_radius_analysis walks the dbt lineage, the team's context-graph notes and the Looker read: game.iap_events feeds fct_payer_daily, the 01:00 LTV scoring, the 06:00 bid export and the UA performance Explore. Overstated iOS purchases would inflate predicted iOS LTV, and the export would raise bids on every iOS campaign in the morning |
| 19:22 | PagerDuty + Slack | Data Workers raises a PagerDuty incident for the data on-call with the diagnosis and recommends holding the 06:00 export until checks pass. The approval request goes to the player data owner in Slack, with the user acquisition lead and the client team copied |
| 19:35 | Vertica MCP Server | The on-call asks her assistant, which runs the Vertica MCP Server with a viewer role and a read-only user, to export the table definition: the primary key is DISABLED. A query finds 2,914 event_id values present two to five times, all from iOS 6.2 |
| 19:40 | Game client team | The client team confirms the resend behaviour, pauses the rollout at 20% and schedules a fix for 6.2.1 |
| 19:55 | Spellbook | The owner reviews the proposal: a diff for the flow's load step that copies each file into a staging table and inserts only event_id values not already loaded in the last 72 hours; a cleanup statement that saves the 4,388 extra rows to a holding table, then deletes them by keeping the earliest load of each event_id; and a run plan (cleanup, merge the diff, rerun the hourly flow, let the 01:00 flow run, release the export after the LTV check). Enforcing the key on the fact table was considered; Vertica's own guidance warns of overhead on large fact tables, so the dedupe lives in the load. She approves |
| 20:10 | GitHub + Vertica | The data engineer opens a pull request with the approved diff, merges it and runs the approved cleanup in vsql |
| 20:15 | Data Workers + Prefect | Data Workers queues the approved run of iap_events_hourly through Prefect with trigger_prefect_flow and reads the run's status from Prefect |
| 20:24 | Data Workers | The run completes. The recorded metrics read 0.0% duplicate share and 1.18 purchases per iOS payer, inside the band |
| Wed 01:00 | Prefect + Vertica | ua_marts_nightly builds fct_payer_daily and scores D7 LTV in-database on clean data |
| 01:40 | Data Workers | Mean predicted iOS D7 LTV, recorded with monitor_metrics after scoring, sits inside its band. Data Workers recommends releasing the hold |
| 05:45 | Spellbook + PagerDuty | The owner releases the export. Data Workers writes the receipt (cause, approvals, diff, cleanup and who ran it, rerun, checks passed, undo from the holding table), links it from the PagerDuty incident and resolves it. The approved fact "purchase events can repeat on reconnect; the load dedupes by event_id" lands in the Context Wizard graph |
| 06:00 | Ad networks + Looker | Bid targets go out from clean predictions. The UA performance Explore shows iOS return on ad spend in line with last week |
Every system did its job. Catching this took knowledge no engine was built to hold: that an event_id should appear once, and that tomorrow's bids are set from tonight's purchases.
| Job | What Vertica does | What Data Workers does |
|---|---|---|
| The run | Loads with COPY and the Kafka data loader, scales subclusters in Eon Mode, answers queries at high concurrency | Reads the flow runs and task runs that load Vertica, and the dbt models built on it |
| The signal | Management Console, system tables and the Unified Console show how the cluster and its queries are doing | Metrics the team defines, recorded after every load, show the owner whether the data is right |
| The diagnosis | Query profiles and explain plans show what ran and how it performed | Joins the upstream release, the flow run, the metrics and the lineage into one cause, with the blast radius across models, exports and dashboards |
| The fix | Runs whatever statements and loads the team deploys | Proposes the load change as a diff and the cleanup as a statement for the owner to approve and run |
| The rerun | Executes the loads and models the orchestrator sends | Queues the approved rerun through Prefect and reads its status |
| The proof | Keeps query history in its system tables | Re-checks the recorded metrics and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't Vertica just do this itself?
Because Vertica is built to answer analytical queries at speed and concurrency, and it does that very well. Its unit is the query, the projection and the load. It knows the 18:05 COPY rejected nothing; it does not know that one purchase should mean one row, or that a bid export reads the table at 06:00.
Vertica's AI follows that scope, and it is well designed for it. In-database ML trains and scores models without moving data. The Vertica MCP Server, a standalone RPM since 26.3, lets an AI agent run queries with a JWT token mapped to a database user whose privileges it inherits; the viewer role keeps cluster operations off limits. 26.3 adds ML tools that train, evaluate and score models through natural language, on top of LLM-powered query profiling from 26.2, and Vertica AI Assist explains query optimizations in the Unified Console. Each makes people in Vertica more productive.
Owning whether a number is right across a game client, Prefect, Vertica, dbt, a model, an ad export and Looker is a different product: a context graph across every system, blast-radius scoping, named approvals, a recorded undo and receipts. A database that rewrote another team's flows or held another company's exports would carry liability it was never built for. 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
Vertica owns high-speed analytics at high concurrency. 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.
| Stage | Data Workers | Vertica | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4 | System tables and the catalog describe the projections and tables inside one Vertica database. Data Workers keeps one governed context graph across Vertica and every system around it. |
| Analytics & Insights | 8 | 8.5 | Vertica's home stage: columnar MPP SQL at high concurrency, with time series, pattern matching and geospatial functions in the database. Data Workers answers data questions from governed definitions on top. |
| Data Quality | 8 | 4 | Declared constraints and ANALYZE_CONSTRAINTS validate keys when the team turns them on. Data Workers checks what each load wrote, with metrics the team defines, after every run. |
| Observability & Incidents | 8.5 | 4 | Management Console and the Unified Console watch the cluster and the queries. Data Workers diagnoses the data incident across the source, the flow, the models and the dashboards, and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 6 | COPY, the Kafka data loader and the Spark connector load data fast, in Enterprise and Eon Mode; the schedule usually lives in an orchestrator. Data Workers queues the approved rerun through it. |
| Schema & Migration | 8 | 4 | Vertica runs the schema it is given, and planning a move off it is not its job. Data Workers generates schema migrations with rollback SQL for the owner and plans moves in approved waves. |
| Governance & Access | 8.5 | 5 | Roles, grants and access policies govern who reads what inside Vertica. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 6 | Mature engine security: TLS, Kerberos, LDAP and OAuth sign-in, and MFA in Management Console. Data Workers leaves a receipt on every data change across systems. |
| Cost / FinOps | 8 | 5 | Eon Mode subclusters scale compute up and down against communal storage. Data Workers reads AWS spend by service with its forecast and drafts any resize for the owner. |
| MLOps & Models | 7.5 | 6 | In-database ML trains and scores models where the data lives, and the MCP server now runs ML workflows by prompt. Data Workers keeps the data under those models healthy. |
How Vertica and Data Workers work together
Prefect (runs and approved reruns), dbt (models, lineage, tests), Looker (read), PagerDuty, Slack, GitHub pull request review and AWS Cost Explorer connect natively (full list). Detection rests on what those connectors read plus the load metrics your own flows record with monitor_metrics, so it starts the moment a COPY ends. For questions inside Vertica, your assistant runs the Vertica MCP Server next to Data Workers' MCP servers, and each answers its own questions. Statements, loads and grants stay with your team. More in read-only warehouse access for LLM agents and connecting AI agents to a data warehouse via MCP.
On Vertica, create a user with SELECT on the schemas your team investigates, generate the MCP token with the viewer role and keep its expiry short, as Vertica's token guidance recommends. Data Workers follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client.
// Example: Vertica MCP Server (viewer role, read-only user) next to Data Workers agents.
// The Vertica entry follows Vertica's Claude Desktop example; add its certificate flags.
{
"mcpServers": {
"vertica": {
"command": "npx",
"args": ["mcp-remote", "https://<MCP_SERVER_HOST>:8667/mcp", "--header", "X-API-Key:${VERTICA_MCP_TOKEN}"],
"env": { "VERTICA_MCP_TOKEN": "<viewer-role token for a read-only user>" }
},
"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-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] },
"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 (dw-context-catalog), and trigger_prefect_flow, send_pagerduty_alert and resolve_pagerduty_alert (dw-connectors). You're on Prefect covers the Prefect side in depth.
If a workload moves off Vertica. 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 on both sides, tracks the results and holds the completion gate for the owner's sign-off. generate_migration writes target schema changes with rollback SQL for the owner to apply. See Data Workers on Snowflake and data migration automation with AI agents.
The agents run in your infrastructure and hold the credentials and model key; the hosted Conductor sees workflow metadata only. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. On Wednesday the user acquisition lead asks why iOS bids jumped. Two teams spend the day on it.
- •L1 observe. Data Workers flags the duplicate share at 19:07 with the cause and blast radius. Nothing changes.
- •L2 propose. The load diff, cleanup, run plan and export hold wait for the named owner's approval.
- •L3 act reversibly. For a class with a clean record, Data Workers queues the rerun itself, verifies it and sends any failed check to a person. Cleanups stay with the owner.
- •L4 autonomous. For a scoped domain, the fix is waiting for the owner before the next model or export reads the table.
More in how approvals work and autonomy levels L0 to L4 explained.
What changes for your team
- •The DBA stops being the first suspect. A wrong number from a clean load arrives with its upstream cause, so nobody asks the DBAs to prove the cluster innocent.
- •Models and exports get a guard. When a model, a bid export or a partner feed is about to read a table that just went wrong, the hold is recommended first.
- •Client, data and business owners share one record. Everyone sees the same receipt in Spellbook Data Catalog (in preview), linked from the PagerDuty incident.
Data Workers is the agentic data platform for the whole lifecycle, so one record covers the release, the load, the model and the export (what is an agentic data platform).
Keep Vertica, or consolidate?
Keep Vertica 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 that keep Vertica consolidate the tooling around it: hand-written duplicate checks, a separate observability tool on event tables, and "rerun the flow and ask analytics" runbooks. Teams moving a workload run the move through Data Workers, wave by wave. See you're on Teradata for a batch estate mid-migration, you're on ClickHouse for real-time event analytics and the agentic data platform for media and advertising for ad-funded businesses.
Building on the Vertica MCP Server and a coding agent instead? Running SQL is the easy part; context, approvals, undo and receipts are the work. See build it ourselves with Claude Code and MCP servers.
The case for your CFO
The outcome. A wrong number from a Vertica load is caught within the hour and corrected before anyone spends money on it. Here, a morning of inflated bids never went out.
The risk story. At L0 and L1 agents only read; on Vertica your assistant uses a read-only user and a viewer-role token your DBAs issue and can revoke. At L2 agents 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 the undo.
Why now. Vertica now ships an MCP server and an AI assistant. More agents and faster loads mean more green flows with wrong data, and more decisions, like bids, made automatically from it.
The first win. L1 on the event loads that feed revenue, LTV and bidding.
What stays the same. Vertica, projections, subclusters, COPY scripts, Prefect flows, dbt and in-database models, Looker and the on-call rota. Zero migration to start; a move you choose runs in approved waves, with a design target of 4 to 8 weeks per migration instead of 6 to 12 months. See the ROI of agentic data operations.
The sentence for upstairs: "Vertica keeps our analytics fast; Data Workers makes sure the data behind it is right and gets problems fixed with our approval before we spend money on a wrong number."
Getting started
Start with a pilot. Pick the Vertica tables behind spend or revenue, give Data Workers read access to the flows and dbt project that build them, record two or three metrics that define "right" after each load, 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 Vertica? Through the systems around it: Prefect, dbt, Looker, PagerDuty and Slack connect natively, and your flows record load metrics with monitor_metrics. Your assistant runs the Vertica MCP Server, with a viewer-role token for a read-only user, next to Data Workers' MCP servers.
Vertica has an MCP server and AI Assist. Why add Data Workers? Both make Vertica's users more productive inside Vertica. Data Workers covers the operations job across the whole estate: whether what a load wrote is right, what it reached downstream, the fix, the approval and the receipt. Teams use both.
Will Data Workers write to our Vertica database? No. Load changes arrive as a diff for the owner to merge, cleanups as a statement the owner approves and runs, and reruns queue through your orchestrator after approval. Your DBAs keep every grant and token.
Our COPY loads report zero rejected rows. How would Data Workers know the data is wrong? Your team records the metrics that define "right" after each load with monitor_metrics, such as the duplicate share on a key, rows per hour per source or purchases per paying player. A value outside its baseline opens an incident even when every flow is green. Failing dbt tests count too; row-level rules stay in your own tests.
Should we just enforce primary keys in Vertica? Sometimes. Vertica can enforce keys on load; its documentation notes significant overhead on large fact tables, and new keys are not enforced by default. Data Workers proposes the guard that fits each table, an enforced key on a dimension or a dedupe in the load for a big fact table, and the owner decides.
Sources
- •Vertica, "What is Vertica?" (Enterprise and Eon Mode, in-database ML), https://vertica.com/about/ (checked Oct 3, 2026)
- •Vertica documentation, "New and changed in version 26.3" (standalone MCP server RPM, ML tools, AI Assist; no core database changes), https://docs.vertica.com/latest/en/new-features/26.3/ (checked Oct 3, 2026)
- •Vertica documentation, "New and changed in version 26.2" (AI Assist, MCP query profiling), https://docs.vertica.com/26.2.x/en/new-features/26.2/ (checked Oct 3, 2026)
- •Vertica documentation, "New and changed in version 25.3" (OpenText Analytics Database naming), https://docs.vertica.com/25.3.x/en/new-features/25.3/ (checked Oct 3, 2026)
- •Vertica documentation, copyright notice (Vertica is a trademark of Rocket Software), https://docs.vertica.com/latest/en/copyright-notice/ (checked Oct 3, 2026)
- •Vertica documentation, client authentication (Kerberos, LDAP, OAuth), https://docs.vertica.com/latest/en/security-and-authentication/client-authentication/ (checked Oct 3, 2026)
- •Vertica documentation, MCP server (JWT tokens, inherited privileges, viewer role, token expiry guidance), https://docs.vertica.com/latest/en/admin/mcp-server/ (checked Oct 3, 2026)
- •Vertica documentation, MCP server Claude Desktop example, https://docs.vertica.com/latest/en/admin/mcp-server/claude-desktop-example/ (checked Oct 3, 2026)
- •Vertica documentation, machine learning with the MCP server, https://docs.vertica.com/latest/en/admin/mcp-server/machine-learning/ (checked Oct 3, 2026)
- •Vertica documentation, Eon Mode concepts, https://docs.vertica.com/latest/en/architecture/eon-concepts/ (checked Oct 3, 2026)
- •Vertica documentation, levels of constraint enforcement (new primary keys not enforced by default), https://docs.vertica.com/latest/en/admin/constraints/constraint-enforcement/levels-of-constraint-enforcement/ (checked Oct 3, 2026)
- •Vertica documentation, constraint enforcement (COPY, overhead on large fact tables), https://docs.vertica.com/latest/en/admin/constraints/constraint-enforcement/ (checked Oct 3, 2026)
- •Vertica documentation, PREDICT_XGB_REGRESSOR, https://docs.vertica.com/latest/en/sql-reference/functions/ml-functions/transformation-functions/predict-xgb-regressor/ (checked Oct 3, 2026)
- •dbt-vertica, official dbt adapter for Vertica (1.12.0, Sep 22, 2026), https://github.com/vertica/dbt-vertica (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations), 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)