PRODUCTS

KEYWORDS

Dolt Workbench Now Supports Doltgres Agent Mode

Earlier this year, we launched agent mode in Dolt Workbench. It’s a Cursor-like agentic chat interface that allows you to safely interact with your databases.

Doltgres Agent Mode

Originally, agent mode only supported Dolt, MySQL, and Postgres databases. Today, we’re announcing that we’ve also added support for Doltgres. In this article, I’ll walk through an example showing how to use agent mode for a data import task.

Agent Data Import Example#

To get started, you’ll need a running doltgres server and a copy of Dolt Workbench downloaded on your computer. For this example, I’m starting with a completely empty database. After connecting to the doltgres server from the workbench, click the orange robot icon at the top right of the screen to open the agent panel. If it’s your first time using agent mode, you’ll be prompted to supply an Anthropic API key.

Now, with an empty database and a fresh agent session, it’s time to do something interesting. I wanted to see how well the agent could handle a somewhat ambiguous data import task. To test this out, I asked the agent to load in Pagila, the canonical Postgres example database. This was my prompt:

Prompt: Can you import the 'pagila' database? You can find it here: https://github.com/devrimgunduz/pagila

I was intentionally vague here. That link points to a GitHub repository with a bunch of scattered .sql files. I wanted to see if the agent could accurately decipher the schema for each of the tables, pull down the data appropriately, and load everything into my doltgres database. Additionally, I knew that there would likely be features of this database that are not yet fully supported in doltgres. I was curious to see how the agent would adapt when it ran into these issues.

About 10 minutes and 20 tool calls later, I was greeted with this message:

Doltgres Commit Confirm

When using agent mode in the workbench, the agent will never make direct commits without your permission. This gives you the luxury of examining the diff before any changes become part of your commit history. Immediately, I could see in the main view that all 15 tables had been created:

Doltgres New Tables

And here’s a summary of the diff:

Doltgres Diff Summary

Before committing, I also wanted to know what changes were necessary in order to make this database fully Doltgres-compatible.

Prompt: What changes did you make in order to make this database work with Doltgres? Response: Here is a summary of the actual changes I had to make, based on what I verified through testing. Things that genuinely do not work in Doltgres (and had to be changed or omitted): tsvector type --The film.fulltext column was tsvector in the original schema. Doltgres returned ERROR: type "tsvector" does not exist, so l stored it as plain text instead. CREATE AGGREGATE - The original schema defines a custom group_concat aggregate. Doltgres returned ERROR: CREATE AGGREGATE is not yet supported. This meant the three views that depended on it (actor_info, film_list, nicer_but_slower_film_list ) could not use the original definitions. CREATE MATERIALIZED VIEW - The rental_by_category materialized view could not be created. Doltgres returned ERROR: CREATE MATERIALIZED VIEW is not yet supported. This was omitted entirely. rewards_report function -- This function uses advanced plpgsql features (dynamic SQL with EXECUTE, temporary tables, RETURN NEXT with records). It failed with ERROR: unhandled statement type: plpgsql.statement. Omitted. Partitioned tables -- The original payment table was partitioned by range across 7 monthly partition tables. I consolidated these into a single flat payment table since Doltgres does not support PARTITION BY RANGE. ALTER TABLE ... USING - When I tried to fix column types after the fact, this syntax was not supported. Not a schema difference per se, but it forced me to drop and recreate the film table rather than alter it in place.

After confirming with the team that this was all in accordance with the current state of Doltgres, I allowed the agent to commit my changes. With this done, I had a fully version-controlled Pagila clone!

Conclusion#

This is just one example of a task you can use agent mode for with a Dolt or Doltgres database. For a more complete summary of its capabilities, check out this overview blog. For an example of a more complex data analysis task, read about how we used agent mode to uncover Medicaid fraud. This is a feature we think has a ton of potential, so we’d love for you let us know what you think on Discord.