In this article

The OpenMetal Medium v5 is built on dual Intel Xeon 6505P processors (Granite Rapids, Intel 3 process) with 96MB total L3 cache, 256GB DDR5-6400, and Micron 7500 MAX NVMe storage. This article covers the workloads it’s genuinely well-suited for, how the private cloud and bare metal configurations compare, where the Medium v5 fits in the broader v5 lineup, and when to step up to the Large or XL v5 instead.


The Medium v5 is the entry point in OpenMetal’s Granite Rapids server lineup. Entry-level in this context means it’s the smallest configuration in the v5 generation, not that it’s a low-performance server.

The Intel Xeon 6505P’s architecture, specifically its 48MB L3 cache per socket and DDR5-6400 memory bandwidth, makes it well-suited for workloads where cache hit rate and storage IOPS drive performance more than raw core count. Understanding what those workloads are helps you decide whether the Medium v5 fits what you’re running, or whether a larger v5 configuration is the right call.

How the Medium v5 Compares to the Medium v4

The Medium v4 is still available and a capable server. The v5 is a newer option built on a different processor architecture, and the hardware differences are worth understanding when deciding which fits your workload better.

The jump to Granite Rapids on Intel 3 delivers specific, measurable improvements over the v4’s Sapphire Rapids on Intel 7:

L3 cache: 48MB per socket on the Xeon 6505P versus 22.5MB on the Silver 4510. That’s 113% more cache per socket, or 96MB total across the dual-socket configuration. For workloads with hot data sets that benefit from cache residency, this is a direct latency reduction.

Memory bandwidth: DDR5-6400 at approximately 409GB/s aggregate bandwidth per socket versus DDR5-4800 on the v4. The 45% improvement in memory bandwidth benefits any workload that moves large amounts of data between CPU and RAM, including analytics, in-memory databases, and containerized applications with high concurrency.

Storage: Micron 7500 MAX NVMe delivers 7,000 MB/s sequential read and 1.1 million random read IOPS per drive. The v4 used the Micron 7450 MAX, a solid drive, but the 7500 MAX is a meaningful step forward for random I/O intensive workloads.

What Workloads Is the Medium v5 Best For?

The Medium v5 is well-suited for four categories of production workload where its specific hardware profile provides a real performance advantage.

Containerized Database Clusters

PostgreSQL, MySQL, and Redis deployments benefit directly from the Xeon 6505P’s L3 cache profile. Database engines keep frequently accessed index pages, buffer pools, and hot row data in CPU cache when it fits. With 96MB of L3 cache across the dual-socket configuration, a significantly larger working set stays in cache compared to the v4, which translates to lower query latency under concurrent load.

On a three-node Medium v5 private cloud, you’re working with 72 cores and 144 threads, 768GB of DDR5-6400 RAM, and 19.2TB of Micron 7500 MAX NVMe across the cluster. Ceph provides the distributed block storage layer for database volumes with replication across all three nodes. Live migration keeps your database VMs available during host maintenance. No shared tenancy means your database performance isn’t subject to what other tenants are doing on the same hardware.

For teams running PostgreSQL clusters that have hit the ceiling on managed RDS performance, or Redis deployments where cache miss latency is affecting application response times, the Medium v5 private cloud is a credible production destination.

Mid-Scale Kubernetes

The Medium v5 is a solid foundation for production Kubernetes clusters at the scale that SaaS companies typically run once they’ve outgrown the economics of managed EKS or GKE.

The hidden costs of managed Kubernetes at this scale compound quickly: EKS control plane fees, inter-AZ data transfer between pods, load balancer provisioning per service, NAT gateway fees for outbound traffic, and persistent volume costs tied to EBS pricing. A team running a meaningful production EKS cluster is likely paying $8,000 to $15,000 per month or more when all of these line items are added up.

A three-node Medium v5 private cloud gives you a fixed-cost Kubernetes environment with 20Gbps private bandwidth per node, no inter-node traffic charges, and Ceph-backed persistent volumes that aren’t subject to EBS pricing variability. OpenStack integrates with Kubernetes via Cluster API Provider OpenStack (CAPO), and the OpenMetal team provides engineering support for the infrastructure layer rather than a ticket queue.

For SaaS companies running 50 to 150 production pods with stateful workloads, the Medium v5 private cloud is worth a direct cost comparison against your current EKS spend.

CI/CD and DevOps Infrastructure

Engineering teams running heavy build and test pipelines have a different performance profile from production application workloads. Build jobs are highly parallel, benefit from fast local NVMe for build caches and artifact storage, and don’t require the multi-tenant isolation that production environments need.

For this use case, bare metal is usually the better choice over private cloud. A single Medium v5 bare metal server gives you 24 dedicated cores and 48 threads with no hypervisor overhead, 6.4TB of Micron 7500 MAX NVMe at 1.1 million random read IOPS, and 20Gbps private networking. Multiple servers can be deployed for parallel build capacity, each dedicated entirely to build and test workloads.

Teams running Jenkins, GitLab CI, or GitHub Actions self-hosted runners on shared cloud infrastructure often see build times that are inconsistent because of noisy neighbor effects. Dedicated bare metal eliminates that variable. The build time you measure during testing is the build time you get in production, because the hardware isn’t shared.

Multi-Tenant Dev and Staging Environments

SaaS companies often need isolated environments for multiple customers, feature branches, or internal teams. Running these on hyperscaler on-demand instances gets expensive quickly, particularly when environments need to stay up for extended periods rather than spinning up and down frequently.

The Medium v5 private cloud’s OpenStack Projects provide the isolation mechanism. Each project is a logically isolated environment with its own networking, security groups, and storage. You can run dozens of isolated dev and staging environments on a three-node cluster without per-VM licensing costs, per-instance billing, or the variability of shared cloud performance.

For a SaaS company with 10 to 30 customers each requiring an isolated environment, the fixed-cost model changes the economics meaningfully. The cost per environment on dedicated private cloud is lower than equivalent EC2 instances once the cluster is reasonably utilized, and the performance is more consistent because the hardware is dedicated.

Private Cloud vs Bare Metal for the Medium v5

The two configurations serve different needs and it’s worth being specific about which fits which workload.

Choose the private cloud configuration when: You need high availability and live migration for your workloads. You’re running multiple services or teams on the same infrastructure and need isolation between them via OpenStack Projects. You want Ceph-backed distributed storage with replication across nodes. You need the OpenStack API layer for infrastructure-as-code workflows. The three-node minimum gives you a full OpenStack and Ceph control plane alongside compute capacity.

Choose bare metal when: You’re running a single-purpose workload that doesn’t need multi-tenant isolation. You want maximum performance without hypervisor overhead. You’re running your own hypervisor such as Proxmox and don’t need OpenStack. You need full IPMI access and want to manage the OS layer yourself. Individual Medium v5 bare metal servers can be added or combined as needed without the three-server minimum.

The Medium v5 bare metal server and the Medium v5 private cloud are currently available in Ashburn, VA. Additional data center locations are planned as v5 inventory expands.

Where the Medium v5 Fits in the v5 Lineup

The Medium v5 is well-positioned for teams that want current-generation Granite Rapids hardware with predictable fixed-cost pricing for the use cases above. The pricing reflects current market conditions for v5 components. If your workloads are running well on Medium v4 hardware, that’s a reasonable place to stay. The v5 makes sense when the specific improvements in cache, memory bandwidth, or NVMe performance address a real bottleneck in what you’re running.

Move up to the Large v5 when: your workloads need more than 512GB of RAM, you’re running high-memory database configurations that don’t fit in the Medium’s 256GB per node, or you need the higher clock speeds of the Xeon 6517P for single-threaded performance-sensitive workloads.

Move up to the XL v5 when: you need 1TB or more of RAM per node, you’re running AI inference workloads that benefit from Intel AMX at larger memory footprints, you need Intel TDX confidential computing support, or you’re running multi-chain validator operations that need the higher core density. Intel TDX requires all DIMM channels to be fully populated. OpenMetal stocks 64GB RDIMMs across 16 slots, so TDX-capable configurations start at 1TB, which the XL v5 ships with out of the box. Reaching that on the Medium v5 would mean a RAM upgrade that isn’t cost-effective for what the platform is priced for.

The Medium v5 is well-positioned for teams that have outgrown managed cloud services for the specific use cases above and want predictable fixed-cost infrastructure with current-generation hardware. The pricing reflects the v5 generation’s Granite Rapids components in the current hardware market, and the performance improvement over v4 is significant enough that the comparison to v4 pricing isn’t the right frame. The comparison that matters is against the current alternatives: what EKS or RDS costs for equivalent workloads, or what a comparable dedicated server costs from providers who haven’t updated their hardware to Granite Rapids yet.

Frequently Asked Questions

What is the OpenMetal Medium v5 best for?

The Medium v5 is best suited for containerized database clusters (PostgreSQL, MySQL, Redis), mid-scale Kubernetes production environments, CI/CD and DevOps build infrastructure, and multi-tenant dev and staging environments. Its 96MB L3 cache and 1.1M random read IOPS NVMe profile specifically benefit workloads where cache hit rate and storage IOPS drive performance.

How does the Medium v5 compare to the Medium v4?

The Medium v4 is still available and a solid server. The v5 steps up with 113% more L3 cache per socket, 45% faster memory bandwidth (DDR5-6400 vs DDR5-4800), and the Micron 7500 MAX NVMe generation versus the 7450 MAX. The CPU moves from the Intel Xeon Silver 4510 (Sapphire Rapids, Intel 7 process) to the Intel Xeon 6505P (Granite Rapids, Intel 3 process). Both deliver 12 cores per socket and 4.1GHz max turbo. If your workloads are running well on v4, that’s a reasonable place to stay. The v5 makes sense when cache, memory bandwidth, or NVMe performance is a real bottleneck.

What is the difference between the Medium v5 private cloud and bare metal configurations?

The private cloud configuration is a three-server hyper-converged cluster running OpenStack and Ceph, giving you a full private cloud with HA, live migration, distributed storage, and multi-tenant isolation. Bare metal is one or more individual servers with full root access, IPMI control, and no hypervisor layer, suited for single-purpose workloads or deployments where you’re running your own hypervisor.

Can the Medium v5 private cloud be expanded?

Yes. Additional Medium v5 nodes can be added to an existing private cloud cluster in approximately 20 minutes. You can also add nodes of different sizes to expand compute capacity as your workloads grow.

Does the Medium v5 support Intel TDX confidential computing?

Not practically. Intel TDX requires all DIMM channels to be fully populated, and OpenMetal’s 64GB RDIMM stocking means TDX-capable configurations start at 1TB. The Medium v5 ships at a lower RAM footprint, and upgrading it to 1TB to unlock TDX isn’t cost-effective for most workloads at that tier. If confidential computing is a requirement, the XL v5 ships with 1TB DDR5-6400 as its base configuration and is the right platform for TDX workloads.


Ready to evaluate the Medium v5 for your workloads? See full specs and pricing or use the cloud deployment calculator to configure a private cloud deployment. Contact the team if you want to discuss whether Medium v5 or a larger v5 configuration is the right fit.


Chat With Our Team

We’re available to answer questions and provide information.

Reach Out

Schedule a Consultation

Get a deeper assessment and discuss your unique requirements.

Schedule Consultation

Try It Out

Take a peek under the hood of our cloud platform or launch a trial.

Trial Options

 

 

 Read More on the OpenMetal Blog

Infrastructure for GENIUS Act Stablecoin Reserve and Redemption Systems

Aug 03, 2026

We look at what the GENIUS Act actually requires of payment stablecoin issuers, why reserve tracking, redemption, and transaction monitoring systems need dedicated and auditable infrastructure rather than shared platforms, and where that requirement does and doesn’t touch broader blockchain infrastructure.

Large-Scale Ceph Storage for Financial Data Retention and Audit Archives

Jul 29, 2026

We look at why financial services firms accumulate large, long-lived data retention and audit archive requirements, why hyperscaler storage pricing works against that access pattern specifically, and how a large-scale Ceph cluster handles the same requirement with predictable costs and full control.

What US CLOUD Act Jurisdiction Means for Your Singapore Infrastructure

Jul 28, 2026

We answer a specific legal question that general Singapore sovereignty content doesn’t: whether US CLOUD Act jurisdiction reaches infrastructure physically hosted in Singapore, how that’s separate from Singapore’s own PDPA framework, and what that means if you’re evaluating a US-owned infrastructure provider for APAC deployment.

Self-Hosting an AI Agent Code Execution Sandbox on Bare Metal

Jul 27, 2026

We explain why AI agents that execute code need microVM-level isolation, why that isolation requires direct hardware access that public cloud VMs can’t provide, and how self-hosting a Firecracker or Kata sandbox on dedicated bare metal compares to managed platforms like E2B on cost and control.

Running Confidential Computing Workloads in the EU in Amsterdam

Jul 24, 2026

We explain what Intel TDX confidential computing actually protects, confirm which hardware configuration delivers it in our Amsterdam data center today, and walk through why pairing TDX with EU data residency matters for regulated workloads.

Amsterdam vs Other EU Data Center Locations for Latency and Compliance

Jul 22, 2026

We compare Amsterdam against Frankfurt, Dublin, and Paris as EU infrastructure locations, covering network connectivity, latency to key regions, and data residency considerations, then explain why Amsterdam is where OpenMetal actually operates.

EU Data Residency and Data Sovereignty Are Not the Same Thing

Jul 20, 2026

We break down the real difference between data residency and data sovereignty, why many “sovereign cloud” claims from US-owned providers don’t hold up under scrutiny, and what EU-based infrastructure can and can’t actually guarantee.

Migrating Off Azure: Entra ID and Cosmos DB Are the Hard Part

Jul 17, 2026

We look at why Azure’s egress fees are no longer the sharpest lock-in mechanism, and walk through the specific managed services (Azure Functions, Cosmos DB, Service Bus, Logic Apps, Azure AD B2C / Entra External ID) that actually make leaving Azure hard, including the one place Azure is more open than either AWS or GCP, and the one place it’s arguably worse.

Google Cloud’s Real Lock-In Lives in Spanner and Firestore, Not Egress Fees

Jul 15, 2026

We look at why Google Cloud’s egress fees are no longer the sharpest lock-in mechanism, and walk through the specific managed services (Cloud Functions, Firestore, Cloud Spanner, Pub/Sub, Cloud Workflows, Identity Platform) that actually make leaving Google Cloud hard, including where GCP’s lock-in profile is genuinely different from AWS’s.

The Real AWS Lock-In Is Managed Services, Not Egress

Jul 13, 2026

We look at why AWS egress fees are no longer the lock-in mechanism people think they are, and walk through the specific managed services (Lambda, DynamoDB, Step Functions, EventBridge, SQS/SNS, Cognito, API Gateway) that actually make leaving AWS hard.