Developers are changing how they build and manage databases, bringing AI agents into schema design, migration planning, and query tuning. The decisions made in these workflows shape an application’s performance, scalability, and resilience. CockroachDB expertise needs to be part of that work from the start.

Today, we’re introducing the CockroachDB plugin for ChatGPT and Codex, built for developers, AI agents, and teams using agentic workflows. It brings CockroachDB-specific expertise into the environment where developers and agents write, review, and troubleshoot code.

The plugin combines task-specific skills with an optional authenticated CockroachDB Continuum connection. Skills guide the work, live database context grounds the recommendations, and your permissions determine which actions are available.

The SQL was valid. The design would not scale.

Consider a familiar scenario: a coding assistant produces a clean schema with sensible names, foreign keys, and indexes. Nothing looks alarming in a quick review. Under sustained insert traffic, however, a monotonically increasing key concentrates writes in one part of an index. The schema that looked reasonable becomes a hotspot under load.

That is where CockroachDB-specific context matters.

CockroachDB speaks familiar SQL, but every design runs on a distributed system. Key order affects where writes land. Indexes influence both read performance and write cost. Transactions can span nodes and regions. Locality choices shape latency and resilience. Migration plans must account for application behavior, validation, cutover, and rollback.

The plugin brings these considerations into the workflow, helping developers and agents evaluate database decisions before those decisions reach production.

Where generic guidance runs out

We work with partners and customers at exactly these boundaries. One week the question is how to model tenants without concentrating writes. The next is how to move a PostgreSQL application with limited downtime. Then a query slows down, and the team has an EXPLAIN plan but no clear path from plan to fix.

The questions repeat. The context changes.

Version 0.1.3 packages 34 task-specific skills covering schema design, SQL optimization, transaction behavior, migrations, cluster operations, multi-region deployments, observability, security, compliance, and maintenance. We sourced those skills from the public CockroachDB skills repository, giving future releases a clear path to carry improvements forward.

Skills carry the workflows and CockroachDB guidance. They are loaded when a task calls for them; they do not retrain the underlying model. A configured MCP connection can add current schema, query-plan, and cluster context. Permissions and approvals define what the assistant may access or change.

That separation matters. An MCP connection can provide a table definition or query plan. A skill explains which details matter and how to turn them into a useful recommendation.

Three ways to put the plugin to work

We kept returning to three jobs while testing because they expose the moments when database judgment matters most: design, migration, and diagnosis.

Design for tenant growth and write distribution

Design a CockroachDB schema for a multi-tenant SaaS app that avoids write hotspots.

A generic answer can produce valid Data Definition Language (DDL) in seconds. A useful CockroachDB answer begins with the workload. How many tenants are expected? Will a few create most of the traffic? Which values increase over time? Are reads and writes scoped to one tenant? Does the application need tenant-level locality?

Those answers drive the key and index choices. Putting a tenant identifier first can support tenant-scoped access, but it does not automatically spread a very large tenant's writes. A hash-sharded index can help some sequential workloads, but it changes how reads reach the data. Every secondary index also adds write work and storage.

The goal is not one universal schema. It is to make distribution part of the conversation before the schema reaches production.

Plan a low-downtime PostgreSQL migration

Plan a low-downtime migration from PostgreSQL to CockroachDB using MOLT.

Moving data is only one part of a migration. The application, schema, workload, cutover window, and rollback point all shape the plan. The plugin can guide a compatibility assessment, identify PostgreSQL features that need attention, and organize the work around MOLT Fetch, MOLT Replicator where appropriate, MOLT Verify, and the final cutover checks.

The useful questions are concrete. How much replication lag is acceptable? What proves the target is complete and healthy? When will writes pause? At what point is rollback no longer safe?

A useful result is not a list of commands. It is a plan with assumptions, owners, decision gates, validation, and rollback steps.

Diagnose a slow query from evidence

This query is slow on CockroachDB. Help me read the EXPLAIN plan and fix it.

Start with the query and its EXPLAIN plan. Add table definitions, indexes, row counts, statistics, and runtime evidence. If the slowdown appears only under load or in one region, include that context before choosing a fix.

The plugin follows the same evidence-first discipline. It can look for scans that process far more rows than the query returns, repeated lookups a covering index may avoid, filters that do not align with an index prefix, poor cardinality estimates, unnecessary sorts, or distributed work that costs more than it saves.

Make the next step testable: change one index or predicate, rerun the query under comparable conditions, and compare the plan and observed behavior. Keep a change only when the evidence supports it.

Three jobs we kept returning to while testing: design, migration, and diagnosis.

Built for real database work

You don’t have to connect anything to get started. Paste a schema, your migration requirements, or a query plan into the conversation, and the plugin works from what you give it. Connecting CockroachDB Cloud saves you the copying. The plugin then sees your actual environment instead of the snippet you remembered to paste.

Once connected, the plugin can look around. It can see your clusters, databases, schemas, query plans, and running queries, and pull back a limited set of query results. It can also write, but only to create things: when a task calls for it, it can set up a new database, table, or rows.

That said, it can’t do whatever it wants. There’s no tool for deleting a database, and the read-query tool can’t be used to slip in a change. Everything it does runs under your own CockroachDB Cloud permissions, so it can never do more than you could.

There are two ways to install it. The simplest is the public plugin directory that ChatGPT and Codex share, which gives you all 34 skills with the Cloud connection already set up. If you work in the Codex CLI, the open-source package lets you connect to CockroachDB Cloud or to your own self-hosted cluster through Toolbox, which is read-only unless you change it. You can also add optional local hooks that check the SQL and application files you edit for common CockroachDB issues, and stop an explicit DROP DATABASE or TRUNCATE before it runs. Read through them first, then turn them on if they fit how you work.

The plugin is open source under Apache 2.0. You can read how it’s put together, how its connections are configured, and what the optional checks do before you point it at your database.

The CockroachDB plugin is live now, and the Codex CLI package is available on GitHub. Try it on a real task, like a schema review, a migration plan, or a slow query, and tell us where it should go deeper.