CoreWeave adds managed PostgreSQL inside the clusters running customers’ AI

CoreWeave customers can now put a managed database inside the same computing cluster as their AI workloads. On November 11, 2026, the company made CoreWeave Database generally available, bringing PostgreSQL alongside model training and inference. The launch offers teams an alternative to operating the database themselves or keeping it in another cloud.

The database stays inside the AI cluster

The service runs on CPU nodes inside a customer’s CoreWeave Kubernetes Service cluster, the environment hosting its training and inference workloads. Applications reach the database through a connection within that cluster. Live database records reside on CoreWeave Distributed File Storage, rather than requiring a database connection to another cloud provider.

CoreWeave’s rationale centers on repeated database calls, not just where a model runs. Agents save and retrieve state between tool calls; training jobs record experiment metadata; retrieval services query stored embeddings. The company argues that sending those requests across clouds adds latency and another environment to secure. Keeping the connection inside the cluster removes that cross-cloud step.

CoreWeave Database puts that data in the same cluster as the compute that depends on it, operated by CoreWeave so teams can spend their time on models instead of database operations.

Corey Sanders, CoreWeave senior vice president of product

CoreWeave runs the machinery; customers control the records

CoreWeave takes responsibility for replication, failover, patching and backups. Customers retain ownership of their data, schemas, queries and database users. They can manage the service through the CoreWeave Cloud Console or Kubernetes tools, using the same monitoring and security boundary as the rest of their cluster.

Underneath the managed service is CloudNativePG, an open-source tool that coordinates PostgreSQL on Kubernetes. It handles the primary database instance, replicas and failover. CoreWeave supplies the surrounding operations, storage, monitoring and management workflows. Each database has a primary instance and read replicas distributed across different hosts; a replica automatically takes over if the primary fails.

Data protection includes continuous backups by default and recovery to a chosen moment within the retention window. Teams can also schedule backups, take one on demand before a schema change or upgrade, and restore a full database to a new cluster to check its validity.

Access and security controls

• Private connections: Databases use endpoints inside the cluster. Customers decide whether to expose them beyond it.
• Provider-managed protection: CoreWeave encrypts data at rest and in transit, manages TLS certificates and applies security patches.
• Customer-controlled access: Native PostgreSQL roles and Kubernetes network policies govern connections, while audit logs record database activity.

Existing PostgreSQL data, plus vector search

CoreWeave says the service is fully compatible with PostgreSQL, allowing teams to move existing databases from another cloud or a self-managed installation using native Postgres tools. That migration path is part of the launch: customers can bring an existing database rather than start with a new set of application records.

The included pgvector extension adds storage and vector search for embeddings. Teams can use it for semantic retrieval and retrieval-augmented generation, or RAG, while keeping those embeddings in the same database as application data. CoreWeave presents this as an option to avoid operating a separate vector store.

One customer example comes from Advaita Bio. In a testimonial included in the launch, CEO Mike Mattacola said the company moved its biomedical literature database from another cloud to CoreWeave Database. He described the migration as straightforward and said CoreWeave’s team helped bring it into production, alongside the applications that depend on it.