Agentic kill switch is a database problem. So we built Redpanda SQL

Redpanda SQL is now GA on GCP, rad. The interesting part is why we built a new database. 

Agents are simultaneously less predictable and more technically capable, proficient across multiple domains, often with root access to your systems and the ability to generate code for novel tasks. TL;DR: a nightmare for your CISO to rein in. Old news. 

Today’s news is that you can design out-of-band rules and enforcement for agents so that your systems aren't in the press with a zero-day exploit next week. Either you believe the only way to enforce system boundaries with agents is with out-of-band systems, or you’ll find the rest of the post boring as we dig into a new query engine build. 

Redpanda SQL, powered by the Oxla engine

Last year we announced Redpanda SQL (formerly Oxla), a new database hyper-focused on helping us solve a new design point in database research, which reduces to efficient SQL JOINs specialized to scale linearly with the number of cores. And, a new ring-buffer-based shuffle algorithm that keeps every core saturated. It should be no secret to anyone that the bottleneck in OLAP systems is the memory-to-core bandwidth, with vectorized executions, compressed data types, and specialized hash tables all aiming to make every trip to memory worth it.

To build an agentic kill-switch where the signals are coming in real time (we’ve been really good at this historically), we leaned heavily on the stream-table duality we now call bridge queries. This gives us the freedom at the analytical layer to ignore where the data is stored, how it's stored, and how fast the agent transcripts are coming in with tools, agent instance ID, prompts, models, failures, retries, and conversations to detect trends and kill them when they misbehave.

Specialized database design for agentic governance

Many SaaS products are a disaggregated database. Is Salesforce a database? It acts and feels like one. Is Redpanda Streaming a database? Yes, it's an immutable log, which is the heart of nearly every persistent system. And regardless of your religious affiliation with immutability and correctness (you do need to flush to disk as we do). Ultimately, the job to solve is this: what does an agentic kill-switch need, from first principles, to handle the difference between humans who click and agents that can swarm?

Agentic governance workloads are fundamentally join-heavy. They need to correlate identities, tools, prompts, models, transcripts, historical behavior, and policies in real time while ingesting a continuous stream of events. At the same time, Postgres has become the lingua franca of databases. Those two design dimensions, high-performance joins at scale and Postgres compatibility, became the foundation for Redpanda SQL.

AI agents don’t behave like traditional applications. In an infinite loop, they’re constantly making decisions, accessing systems, and taking action. Managing agents at enterprise scale requires real-time visibility into their behavior, context, and impact, historical trends, and a full DAG of agent-to-agent* where you didn’t even write both upstream or downstream consumers. These assumptions demand a new kind of data infrastructure, and we just shipped it, with a policy engine that governs agents through channels they can't see or touch.

The goal for us was to do real-time analysis of anomalies so we can dispatch a circuit breaker, which we call an “agentic kill switch” (we hinted about this late last year when we launched the Redpanda Agentic Data Plane) 

Open protocols, no lock-in, win on technical merit. 

The typical architecture we see with customer deployments can be broken into a connectivity layer to get data in and out of systems integration. This integration layer is consumed by a catalog that organizes the data with proper schemas, access controls, and indexes in case you want to query it later for analytics. At the bottom, you have a processing layer that consumes the catalog and data in motion and at rest. 

Where Redpanda SQL shines is in unifying architecture with open protocols. It can’t be overstated how much freedom relying on the Postgres protocol gives you from an architectural paradigm. Choose anything in the world and it probably already speaks Postgres. It is simply where the world has converged. 

The ability to represent the duality of the streams as a table with Schema (+evolution), Governance (access controls, authentication, authorization, RBAC, OIDC) as a single entry point that agents or humans can query is an incredible freedom that CIOs demand. Deploy it in your own cloud (BYOC/BYOVPC) and levitate. (What can I say, it’s true.)

Now available in GCP

We wrote a great deal on the mechanics of bridge queries. The takeaway is that data residency is the cost-dominant factor for all data-intensive workloads. So shipping this across clouds wasn’t a viable option for all our GCP customers, and based on the demand, we brought it forward to GCP. 

Why is Redpanda releasing a query engine as the Agentic Data Plane company?

Our entire Agentic Data Plane is the foundation on which the governance layer sits. We simply couldn’t do Agentic Governance at scale with Kill Switch, Guardrails, Evals, AI Gateway/Router (tools and models), among others, if we were not able to do joins at scale, absorb swarms of agents logging data, and be compatible with existing data infrastructure protocols and tools like Iceberg and Postgres. 

Redpanda SQL also shipped in a BYOC (Bring Your Own Cloud) deployment, which means no data ever leaves your firewall. Along with BYOVPC on AWS and GCP,  customers get full control over networking and security, deploying within a new or existing VPC, with all the benefits of a fully managed solution.

Check the Docs, or book a demo to see it yourself.