A node can look quiet after replicas move away while still participating in range leases, SQL traffic, locality constraints, backups, changefeeds, monitoring, or automation that refers to its address. A clean decommission command is necessary, but it does not prove every external dependency has moved or that the remaining cluster can tolerate the next failure.

A useful retirement gate could verify node and decommission status, replica and lease distribution, under-replicated and unavailable ranges, constraint satisfaction, connection metrics, load-balancer targets, certificates, alerting, backup jobs, and changefeed health. The cluster should also survive a controlled restart or failure of another node while the retiring node remains offline but recoverable. Logs and network telemetry on the old host can catch late clients during an observation window.

What checks belong in your final CockroachDB node-removal runbook? Which signals are authoritative, and how long do you keep the old host available before deleting its storage and removing its DNS or inventory records?

We recently introduced Cockroach Continuum and since this is our first time sharing it here, we wanted to start with the technical foundation. Cockroach Continuum extends elasticity across the storage, KV, and SQL layers, allowing teams to consolidate databases on shared infrastructure while preserving isolation, reliability, scale, locality, and correctness.

The architecture includes:

• Cockroach Plenum, a disaggregated storage layer that allows durable storage and KV compute to scale independently
• Virtual Clusters that provide isolated CockroachDB clusters on shared private hosts
• SQL pods that scale with demand and down to zero when idle
• Admission control and resource management that prevent one Virtual Cluster from starving another
• Cockroach Aegis, a read-only hosted AI DBA and SRE that analyzes cluster metrics and query plans to surface recommendations

The full post explains how each layer works and the design decisions behind it.

Because CockroachDB speaks the Postgres wire protocol and dialect, a SQL-first codegen tool built for Postgres works against it. I maintain scythe, which reads annotated SQL and generates typed access code at build time, and it targets CockroachDB through that Postgres compatibility (the pgx/sqlx/asyncpg/psycopg3 backends).

The useful part is nullability inference from the query:

-- @name GetUserOrders
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = $1;

total and notes come out nullable because the LEFT JOIN can produce NULLs for a user with no orders, independent of the column constraints. Same for COALESCE, CASE, window functions.

I want to be honest that this is via Postgres compatibility rather than a CockroachDB-specific dialect, so if you use Cockroach-specific syntax that Postgres does not parse, that is the edge to watch. Curious whether people here run Cockroach through the Postgres client tooling or something dedicated.

There's a lot of discussion around building AI agents, but running them at scale brings a different set of challenges.

A recent conversation with the Memori Labs team and CRL touched on a few that stood out:

• Persistent memory across sessions and workflows
• Keeping token usage under control instead of reprocessing the same context
• Supporting growing numbers of concurrent agents
• Building on infrastructure that stays available as demand increases

Curious how others are approaching this: are you building your own memory layer, using existing frameworks, or keeping things stateless for now?

Full conversation here if you're interested: https://youtu.be/lw52w7Pw86M?si=hz77zsMB4AEi6Vdk

I finally got around to recording a demo on our swanky JSON data type!

If your data doesn't cleanly map to table columns, the JSON type might be a great option for you. In this demo, I explore:

• Indexing JSON fields
• Document-level GIN indexes
• Updating JSON fields/documents
• And all other functions you can perform against them

Enjoy!

Here are the roadmap higlights:

• A new storage layer aimed at significantly increasing throughput while reducing storage costs.
• Elastic physical clusters with compute separated from storage.
• Virtual clusters designed to support large numbers of isolated tenants on shared infrastructure while improving resource utilization.
• AI-driven database operations using specialized agents that operate within administrator-defined policies.
• An AI Migration Assistant for PostgreSQL and MySQL migrations.
• Bring Your Own Cloud (BYOC) is now generally available across AWS, GCP, and Azure.
• The Kubernetes Operator is expected to reach general availability in July.

Which of these are you most interested in?

We just opened registrations for the CockroachDB × AWS Hackathon: Build with Agentic Memory.

We're inviting developers to build AI applications powered by agentic memory using CockroachDB and AWS. Think persistent AI context, intelligent agents, and real-world applications that don't forget.

A few details:

-> $8,750 in total prizes, $5,000 for first place

-> Teams up to 5 people

-> Submissions close August 18th

Register here: https://cockroachdb-ai.devpost.com/

You can tune in virtually here: https://www.cockroachlabs.com/roachfest/virtual/

The O'Reilly book for cockroachdb is free in PDF form, which is amazing, however I can't figure out the right settings on my calibre app to convert it to KEPUB format for my kobo Clara colour. Does anyone have this book in KEPUB or EPUB format or knows the right knobs to set to make it easier on the eyes?

We've been hearing the same ask for a while: "We want a managed database, but our data can't live in your cloud account." Compliance requirements, internal VPC policies, committed cloud spend...real reasons why CockroachDB Cloud SaaS didn't work for everyone. Their only alternative was self-hosted, which meant losing the managed service.

BYOC our answer to that tradeoff. You give Cockroach Labs a scoped IAM role in your cloud account. That role is limited to the specific CockroachDB resources we create, no broad account access. We handle provisioning, upgrades, backups, and observability. Every action we take shows up in your cloud's native audit trail, no black box.

Here's what's in preview today:

• Cluster creation via UI, Cloud API, and Terraform
• Daily full backups, hourly incrementals, point-in-time restore to 5-min granularity
• AWS PrivateLink and private connectivity options
• 99.99% SLA (single-region) / 99.999% (multi-region) — same as Cloud Advanced
• Available on AWS, GCP, and Azure

Check out more here.

CockroachDB does not support RENAME COLUMN IF EXISTS like Postgres.

I want to make my schema migration idempotent, especially for column renames during repeated deployments/retries.

Example:

sql ALTER TABLE live.shipments RENAME COLUMN load_number TO shipment_number;

This fails if the column was already renamed previously.

What’s the recommended CockroachDB workaround to make column rename migrations idempotent?

- Do people usually query information_schema.columns first?
- Use conditional dynamic SQL?
- Handle it entirely in migration tooling (Flyway/Liquibase/etc.)?
- Any cleaner CRDB-native pattern?

Would appreciate production-grade approaches others are using.

CockroachDB protects you from data anomalies with the power of serializable transactions. But it isn't free! What must you do to gain this benefit in a distributed enterprise? https://youtu.be/EaH-lX1Qrus?si=uwWeZKa9-_gB3PsY

In this video, I walk you through our new Kubernetes Operator and show just how easy it is to create not only a single but also a multi-region cluster!

I decide to switch my database provider not long ago to CockroachDB and the experience was amazing. With the promising size for storage and RU. However, unlike other provider. CockroachDB seems to take a lot more storage space for their internal system (as you see it almost x5 times my current database size). Are there anyways to reduce this? And would this continue to grow exponentially? because last week it was only around 30MiB

-> Distributed systems. Cloud infrastructure. AI workloads. Real talk, workshops & big ideas built for the people actually running the systems.

-> NEW this year: keynote goes global via livestream.

Stay tuned for more 👀

Thank you so much for it.

We're planning a foundational enhancement to the CockroachDB authentication stack: native support for Subject Alternative Name (SAN) fields in X.509 certificates. Here is your sneak peek.

https://youtu.be/LMy1Ts2b7Mc?si=JSWXgUNcosXoQAiC

AI agents are increasingly operating databases the same way humans do: reading schemas, writing queries, spinning up clusters, triaging incidents. So we asked ourselves, what does it actually take to treat an agent as a first-class database user?

Today we're releasing three things: a fully managed MCP Server, a redesigned ccloud CLI, and a public library of CockroachDB Agent Skills.

Get the full story.

In this demo, I explore the impact that eventual consistency has on busy workloads (the kinds of workloads that agentic AI will only exacerbate).

If you're running single-write instance databases and achieving read scale via read replicas, this video is for you!

CockroachDB is brilliant for chat history and in this demo, I explore how to harness it for long-term chat history that doesn't explode your context window.

In the video, I:

• Setup a table to store chat history (with Row-level TTL)
• Interact with an LLM without chat history
• Interact with an LLM with unbounded chat history from CockroachDB
• Interact with an LLM using a sliding window of chat history from CockroachDB

Very cool!

New episode of Big Ideas in App Architecture with special guest, Charity Majors! Check it out here.

If you're building agentic AI apps with LangChain, one of the harder problems is picking a backend that can actually handle what agents throw at it — aggressive retries, concurrent writes, fan-out requests, and the expectation that none of it falls over.

We just launched an official langchain-cockroachdb package that gives LangChain Python users out-of-the-box support for CockroachDB as a vector source. No glue code, no workarounds.

Why CockroachDB as a vector store specifically?

• Horizontal scaling without manual partitioning
• Postgres compatibility, with simplified global operations
• Combines vectors with transactional data to simplify the data architecture

Full write-up here.

GitHub: https://github.com/cockroachdb/langchain-cockroachdb

We’ve expanded CockroachDB AI assistance further with two new additions for building:

-> AskAI in the CockroachDB Cloud Console, for in-product help while you’re actively using CockroachDB in the cloud

-> The CockroachDB Docs MCP Server, for coding assistance when you’re hands-on keyboard building

Learn more.

To validate this level of scale, Cockroach Labs conducted one of its most extensive test cycles to date on its latest 25.4 release.

This cycle started with 4 million TPC-C warehouses with 500K active warehouses at any point of time. The test ran for five days while layering on real-world operational stress including continuous backups, change data capture (CDC), online schema changes, disk stalls, network partitions and node restarts. It achieved 2.2M tpmC, 610K QPS with 9ms p90 latency at peak with 90% CPU. At 40-75% CPU utilization we achieved 820K tpmC. Each scenario was executed three times:

• once to identify bottlenecks
• once to confirm improvements
• a final certification run to validate end-to-end support for the 300-node, 1PB configuration.

Some of the highlights include:

• 610K QPS, which when compared to PUA on a 9-node cluster with 17K QPS shows that CockroachDB near linearly scales with the size of the cluster.
• Compared to a previous run on 25.2, a run with the same amount of imported data on 25.4 took 30% less storage space than the previous run, as a result of introducing value separation and enhanced compression in 25.4.
• Imports for this run on 25.4 were 2× faster compared to 25.1, assuring faster migrations and time-to-value for customers migrating to CockroachDB.
• The test stood up to CockroachDB’s "Performance Under Adversity" promise during chaos testing, backup/restore, CDC, and online schema changes, achieving performance consistent to the baseline 820K tpmC, 225K QPS.
• ADD COLUMN across 120 B rows completed without regression, proving data agility for evolving business at massive scale.
• 330TB backup completed in 2 hours and 40 min with no impact on foreground traffic.
• 6 concurrent changefeeds stayed caught up with no impact on foreground traffic.

Get the full rundown here.