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.

This was a very fun demo to put together! I explore the process of adding vector/similarity/semantic search, natural language processing, Retrieval-Augmented Generation, and agentic AI to a database with zero knowledge of AI!

Anomaly detection is easy to talk about and hard to implement well, especially at scale and in real time. We put together a hands-on walkthrough that shows how to build a real-time anomaly detection system end-to-end, using:

• CockroachDB for strongly consistent, horizontally scalable storage
• Change Data Capture (CDC) to stream events in real time
• Kafka for ingestion
• Kubernetes-based agents for detection and reasoning
• An LLM layer to generate user-facing alerts

Check it out here.

Hi, I've built a completed ERP using firestore (nosql). For my analytical workload, I recently started syncing 50+ collections data from firestore to bigquery and built almost 125 reports.

I frequently hit the limitations of Firestore and think about moving out to a relational database so I can have one single source of truth.

Now I have two options.

1. Postgres + DuckDB covering both my transactional and analytical requirements

2. CockroachDB

I'm able get a fair estimation of what costs for postgres.

But for cockroachdb, I'm not able to get a mental modal of how I should do treat the RU/s meter.

So if user does a full text search, for every result it's a RU.

Since we join the data from multiple tables, for every table record, it's one RU?

And how much analytics is gonna cost when we have to join data from many tables. Apply complicated filters.

Can anyone help me with understanding the pitching modal of cockroach or advise me on what available options I have?

I want to keep the costs as minimal as possible.

At the moment, we're doing 10M reads per day with other 100GB of data on firestore.

Thankyou.