How to choose a dedicated server in 2026

A dedicated server is a decision you live with for a while. You tune your stack around it, and moving later costs engineering time. This guide works through the choices in the order they usually matter, explains the trade-off behind each one, and ends with a table that maps common needs to FlexDedi configurations.

If you are still deciding whether you need a physical server at all, read bare metal vs VPS vs cloud first.

Start from the workload

Most sizing mistakes come from buying a spec sheet instead of removing a bottleneck. Before comparing servers, write down what limits your application today: one busy core, total CPU, memory capacity, memory bandwidth, disk latency, disk capacity or network throughput.

If the workload already runs somewhere, measure it at peak instead of guessing. On Linux, a handful of standard tools answer most questions:

mpstat -P ALL 1 10   # per-core load: one core near 100% means single-thread bound
vmstat 1 10          # run queue, memory pressure, swap, and steal time on VMs
iostat -x 1 10       # per-disk utilization, latency (r_await, w_await) and queue size
sar -n DEV 1 10      # network throughput per interface
free -h              # memory used by applications versus page cache

mpstat, iostat and sar come from the sysstat package. Record the peak, not the average, and note which resource runs out first. That resource drives the choice; everything else only has to be adequate.

CPU: single-thread speed or core count

When per-core speed wins

Some work cannot be spread across cores. A game server's simulation tick, a Redis instance, a single PostgreSQL query without parallel workers, one PHP or Node.js request, and the link step of a build all run largely on one thread. For these, the speed of one core sets the latency, and extra cores sit idle.

Per-core speed is instructions per clock (IPC) times frequency, helped by cache. Every server in the FlexDedi lineup uses AMD Zen 5 cores, so IPC is comparable and the differences come from clocks and cache. The EPYC 4545P in Core 16 boosts to 5.4 GHz and the EPYC 4585PX in Core 16X to 5.7 GHz, while the EPYC 9005 processors in the Pro, Max and GPU series boost to 4.4 or 4.5 GHz.

When core count wins

Throughput work scales with cores: virtual machines, container platforms, CI runners executing many jobs at once, analytics engines, video transcoding, and web tiers handling thousands of concurrent requests. Here 32, 64 or 96 cores at a lower clock beat 16 fast ones.

Read the clock speeds correctly

Boost clocks apply when a few cores are busy. Base clock is the frequency the processor sustains with all cores loaded within its power limit, and real all-core clocks usually land between the two. That is why the 4.3 GHz base clock of Core 16X matters as much as its 5.7 GHz boost on a machine whose 16 cores are all busy.

Threads are not cores. Simultaneous multithreading (SMT) adds throughput on some workloads, but plan capacity, and any per-core software licenses, on physical cores.

EPYC 4005 vs EPYC 9005

FlexDedi servers sit on two AMD platforms, and the platform decides more than the core count.

EPYC 4005 is AMD's server line for the AM5 socket. It delivers the highest per-core speed in the lineup at the lowest price, with ECC memory. Its limits are two memory channels and far fewer PCIe lanes, which cap memory size, memory bandwidth and the number of fast devices.

EPYC 9005 (Zen 5, known as Turin) is AMD's full server platform: 12 DDR5 channels per socket, up to 128 PCIe 5.0 lanes in a single-socket system, and core counts that consolidate many smaller machines. Per-core boost is lower, but memory bandwidth and capacity are in a different class.

A practical rule: if the workload fits in 16 cores and 192 GB of RAM and is not limited by memory bandwidth, EPYC 4005 is usually the better buy. If you need more memory, more bandwidth, more cores or Gen5 storage, move to EPYC 9005.

Memory: channels first, then capacity

Bandwidth comes from channels

Each DDR5 channel moves 8 bytes per transfer. At DDR5-6000 that is 6,000 MT/s × 8 bytes = 48 GB/s per channel, so a fully populated 12-channel EPYC 9005 socket has a theoretical peak of 576 GB/s, and the two sockets of Max 192 twice that. Two channels at the same transfer rate give one sixth of a single socket's figure. Measured bandwidth always lands below these theoretical peaks, but the gap between 2 and 12 channels does not close.

This is also why the Pro and Max memory sizes look unusual. 384, 576, 768 and 1,152 GB are 12 DIMMs of 32, 48, 64 and 96 GB, one per channel, and Max 192 uses 24 DIMMs of 64 GB. Leaving channels empty would cut bandwidth even if the capacity looked fine. Our post on DDR5 memory channels and server sizing goes deeper.

Workloads that live on memory bandwidth include analytics scans, in-memory databases, scientific computing and hosts running many busy VMs.

Capacity: size for the working set

• Databases: keep the hot working set, the tables and indexes you read constantly, in RAM. Every miss becomes an NVMe read.
• Virtualization: add up guest allocations, then add host overhead and, if you use ZFS, its ARC cache.
• Application servers: measure resident memory per worker and multiply by peak concurrency.

Leave headroom. Linux uses spare memory as page cache, so a server that shows little free memory is often healthy; a server that swaps is not. Every FlexDedi server uses ECC memory, which corrects single-bit errors instead of passing them on to your data.

Storage: NVMe Gen4 vs Gen5, and RAID

Gen4 or Gen5

A PCIe 4.0 x4 link tops out near 8 GB/s in each direction and a PCIe 5.0 x4 link near 16 GB/s, so Gen5 drives can roughly double sequential throughput. That helps backups and restores, bulk imports, analytics scans, loading AI models and anything else that streams large files.

Latency for small random reads at low queue depth, which dominates many OLTP databases and web applications, improves far less between generations. If iostat shows small I/O at shallow queues, Gen5 will change little; capacity, and RAM for caching, matter more.

Capacities in the lineup range from 2 × 1.92 TB Gen4 on Core 16 to 4 × 7.68 TB Gen5 on Max 96 and Max 192. For bulk data, Storage 264 pairs 12 × 22 TB hard drives (264 TB raw) with two NVMe drives.

RAID

Two drives usually mean RAID 1: usable capacity equals one drive, and the server keeps running through a drive failure. Four drives usually mean RAID 10: half the raw capacity, better write performance than parity RAID, and survival of one failure per mirror pair. On NVMe, software RAID with Linux mdadm or ZFS mirrors is the norm; see software RAID 1 on NVMe with mdadm.

For the hard drives in Storage 264, double-parity layouts such as RAID 6 or ZFS RAIDZ2 fit better. As an estimate before filesystem overhead, two 6-drive RAIDZ2 groups leave 8 data drives, about 176 TB, while a single 12-drive RAIDZ2 leaves 10, about 220 TB, but tolerates only two failures across all 12 drives.

RAID protects against a failed drive. It does not protect against deletion, corruption written by software or a compromised server, so keep backups on another machine.

Network: port speed and unmetered traffic

Port speed caps how fast you can move data at any moment. Monthly transfer is the other half of the question, and on metered plans it becomes a line item that grows with your traffic. On FlexDedi, traffic is unmetered on every server, inbound and outbound, with no monthly cap and no overage fees, so the only sizing question is whether the port covers your peak. The details are in unmetered bandwidth explained.

To translate port speed into volume: 10 Gbps is 1.25 GB/s, or about 108 TB per day if saturated around the clock. Real traffic has peaks and troughs, so size the port for the busiest few minutes, not the monthly average. As an example estimate, 1,000 concurrent viewers of an 8 Mbps video stream need about 8 Gbps at peak, which nearly fills a 10 Gbps port.

Two ports add aggregate capacity across many concurrent flows; a single TCP stream does not exceed one link. Traffic between your own servers in the same location can use free private networking (VLANs), which is not billed and keeps database and replication traffic off the public interface.

Location and latency

Light in fiber covers about 200 km per millisecond, so every 100 km of fiber path adds roughly 1 ms of round-trip time. Cables rarely follow straight lines, so treat great-circle distance as a floor. As an estimate, New York to London is about 5,570 km, which puts the physical minimum near 56 ms round trip before any routing detours.

Put the server close to most of your users, or close to the systems it talks to most, such as a payment API or your office. For a global audience, run servers in several regions and steer users with DNS or a CDN. If data must stay in a jurisdiction, location settles it: Amsterdam and Frankfurt for the EU, London for the UK.

FlexDedi has 10 locations: New York, Ashburn, Dallas and Los Angeles in North America; Amsterdam, Frankfurt and London in Europe; Singapore, Tokyo and Sydney in Asia-Pacific. Core 16 and Core 16X are available everywhere, while the larger and GPU configurations are in a subset, so check availability early. To test paths from a location toward your users' networks, run ping and traceroute from the looking glass.

Delivery time

Configurations marked "Ready in minutes" (Core 16, Core 16X, Pro 32, Pro 48 and Pro 64) are pre-racked and burn-in tested, and usually delivered within 15 minutes of payment with the OS installed. Storage 264, GPU L40S, GPU RTX PRO, Max 96 and Max 192 are assembled to order and usually delivered the same day.

If you scale for launches or seasonal peaks, order same-day configurations ahead of the date. Every control panel action is also available through a REST API and a Terraform provider, so new servers can join your automation instead of a manual checklist.

Managed or unmanaged

FlexDedi servers are unmanaged by default. You get full root or administrator access and are responsible for the operating system, software, security and backups. The platform side covers the hardware, the network, always-on DDoS protection, spare parts on site, an IPMI and HTML5 KVM console on every server, and 24/7 support by engineers.

Unmanaged works well if you already run servers in production, use configuration management and have someone on call. If you do not, budget for that time, or for an outside managed-services partner, before comparing prices. Either way, the first hour on a new machine should follow a baseline such as securing a new Linux server.

Budget: compare total cost, not list price

The monthly price is the easy part. A realistic comparison adds traffic charges, backup storage, software licenses and engineering time. FlexDedi has no setup fees, no traffic charges and no long-term contract, so the server price is the main line item; backups and your own time are not included.

Price per resource helps compare configurations within the lineup:

These ratios ignore per-core speed, storage and network, so use them to sanity-check a shortlist, not to decide. Two more rules help:

• Buy for the next 12 months, not the next three years. Billing is monthly with no contract, so you can move up when the load arrives. A cancelled server stays active until the end of its paid period.
• Price redundancy explicitly. Two Core 16 servers ($598/mo) give you failover that one Pro 32 ($749/mo) cannot, while the Pro 32 gives a single workload more cores, memory and bandwidth. The right answer depends on whether your application can run on two nodes.

Run it on FlexDedi

The table maps common needs to the configuration we would start with. Prices are monthly in USD, excluding taxes, and every server includes unmetered traffic, DDoS protection and IPMI access with no setup fees. The full lineup is on the dedicated servers page, and other CPU, RAM, disk or GPU combinations are available as a custom build.