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

Provisioning Bare Metal Through an API Without Opening a Ticket

Oct 02, 2026

The OpenMetal Central public API covers the full bare metal lifecycle: inventory checks, orders with deployment configurations and saved SSH keys, provisioning status, scaling, power control, and decommissioning, with a sandbox for testing before you touch production.

Managing Bare Metal VLANs and IP Blocks as Code

Sep 29, 2026

OpenMetal Central lets you create, assign, and tear down VLANs and IP blocks through the public API. This walks through the object model, a scripted private network between an application cluster and a database cluster, and the rules that prevent accidental deletions.

How to Run Bare Metal Servers That Boot Entirely From Memory

Sep 28, 2026

OpenMetal bare metal can now boot an OS entirely into memory from a kernel and initramfs you host, then configure itself through cloud-init and a node-local metadata service. This covers how it works, image requirements, and where it fits.

Why Growing Businesses Self-Host Odoo ERP on Dedicated Bare Metal

Sep 23, 2026

As Odoo deployments grow in users and modules, shared cloud hosting and managed platforms hit performance and cost ceilings. This article covers why dedicated bare metal changes the picture, how to size hardware against Odoo’s actual resource model, and when to split the application and database onto separate servers.

Running Windows Server and Hyper-V on Dedicated Bare Metal

Sep 22, 2026

OpenMetal bare metal servers support custom OS installs via IPMI, including Windows Server. This article covers the installation path, edition selection and core licensing on dedicated hardware, Hyper-V setup for VM consolidation, and which hardware configurations suit different Windows workloads.

What Air-Gap Infrastructure Requirements Actually Mean for Private Cloud Deployments

Sep 21, 2026

When compliance teams ask for air-gapped infrastructure, they usually mean network isolation: workloads that can’t reach the internet and can’t be reached from it. This article explains the difference between true air-gap and network isolation, how OpenMetal’s private networking architecture enables isolated deployments, and where the honest boundaries are.

Self-Hosting Temporal Is a Postgres and Private Networking Decision Before Anything Else

Sep 17, 2026

How Temporal Cloud’s per-action billing model works and where it compounds, what the official Temporal documentation says self-hosted deployments require, the infrastructure stack a production cluster needs, and where OpenMetal’s bare metal fits into that.

What the EU AI Act’s Article 12 Requires From Your Log Infrastructure

Sep 14, 2026

What Article 12 of the EU AI Act actually requires, why the obligation is an infrastructure problem before it is a software problem, what compliant log storage needs to look like in practice, the current enforcement timeline, and how private cloud in the EU addresses the requirement.

A Technical Guide to Every CPU Generation in OpenMetal’s Lineup

Sep 04, 2026

The four distinct Intel Xeon generations running across OpenMetal’s bare metal and hosted private cloud lineup, what actually changes between them beyond core count, and which generation fits which kind of workload, including where confidential computing eligibility depends on generation and hardware configuration together.

Why Shared HPC Access Gets Unpredictable for Life Sciences Computing

Sep 02, 2026

We look at why shared, allocation-based HPC access becomes a real operational problem for life sciences computational research, what changes on dedicated infrastructure that you administer yourself, and how to structure a transition that scales up gradually rather than requiring a large upfront commitment.