Database Dedicated Server

A database dedicated server is the machine you build when the database is the thing that matters and consistency is non-optional. Databases are unlike most workloads in what they demand from hardware: not raw core count, but enough memory to keep their hot data in cache, storage fast and predictable enough to serve random reads and writes in microseconds, and latency that stays steady under load rather than spiking when a neighbor gets busy. That combination is exactly what single-tenant hardware with local NVMe delivers and what a shared, network-storage environment struggles to guarantee. This page covers how to think about a database server — sizing memory to the working set, choosing storage that databases actually reward, matching CPU to the workload, the genuine advantage bare metal holds over cloud database services, and how to design replication and backups so the data survives.

What is a database dedicated server?

A database dedicated server is a single-tenant physical machine configured specifically to run databases, built around the three resources databases lean on hardest: memory, storage I/O, and consistent low latency. Rather than being sized by general rules of thumb, it is sized by how the database behaves — how much of the data is read constantly, how many queries run at once, how latency-sensitive the workload is, and how serious data loss would be. The hardware follows from those answers: enough RAM to cache the active working set, enterprise NVMe arranged for fast random access and redundancy, CPU matched to the concurrency and query type, ECC memory for integrity, and a replication and backup design built in from the start.

It runs the databases you already use — PostgreSQL, MySQL and MariaDB, SQL Server, MongoDB, Redis, ClickHouse — with full control over configuration, tuning, and extensions that managed services restrict. The reason to put a database on dedicated hardware rather than a shared or virtualized platform comes down to one word: predictability. Databases punish variability harder than almost any other workload, because a query that is usually fast but occasionally slow makes the whole application feel unreliable, and single-tenant hardware with local storage is what delivers the steady latency that keeps a database responsive. This page is the workload-specific companion to our general dedicated server hosting guide, focused on the choices a database in particular forces.

Start from the working set, not the database size

The most important number in sizing a database server is not the size of the database. It is the size of the active working set — the portion of the data the database touches constantly: the tables read every day, the indexes used on nearly every query, the rows pulled into concurrent sorts and joins. That set, not the total on disk, is what wants to live in memory. When it fits in cache, the database answers most requests from RAM and stays fast even on modest hardware; when it does not, requests fall through to disk and performance degrades sharply regardless of how many cores the machine has.

This reframes the memory question entirely. A one-terabyte database whose hot working set is forty gigabytes does not need a terabyte of RAM; it needs enough to cache those forty gigabytes comfortably, with headroom for growth and for the temporary memory that sorting and reporting consume. Getting this right is the difference between a fast database and a slow one far more often than CPU is. As practical baselines for 2026, 32 GB is the floor for any production server, database-heavy workloads should start at 64 GB, and serious PostgreSQL or MySQL deployments commonly run 64 to 128 GB or beyond — always with ECC memory, so a bit error is corrected rather than left to corrupt data or crash the engine. The discipline is to measure the real working set, size memory to it with headroom, and avoid both starving the cache and paying for memory the workload will never touch. In 2026 that discipline matters more than usual, because memory prices have risen steeply, which makes over-buying RAM genuinely expensive and right-sizing it genuinely valuable.

Why is storage the make-or-break component?

Storage is where most database performance problems are won or lost, because a database’s access pattern is the one that exposes weak storage most brutally. A database does not stream large files sequentially; it scatters small random reads and writes across the data, and what matters is not megabytes per second but random IOPS, the latency of each operation, sustained performance under a long mixed load, write endurance, and protection against data loss on a power failure. Enterprise NVMe is the right answer because it delivers low, consistent latency under parallel load — roughly a hundred times the random I/O of older SATA drives — and because, crucially, it does so predictably.

That word, predictably, is why drive class matters as much as drive type. Consumer SSDs can post impressive headline numbers and then throttle or stall under sustained heavy use, producing exactly the unpredictable query latency a database cannot tolerate, so a serious database server uses enterprise drives with high endurance and power-loss protection rather than consumer parts that are cheaper per terabyte. The arrangement matters too: RAID 10 is the standard for databases because it stripes across mirrored pairs, giving the strong random read and write performance the workload generates while surviving drive failures. RAID 5 and RAID 6 save capacity but carry a write penalty and dangerously long rebuild times on large drives, which is a poor trade for a database. A common refinement is to keep the write-ahead or transaction log on separate NVMe from the main data, so that constant log writes and periodic checkpoints do not contend with query I/O — a small structural choice that smooths out write-heavy workloads considerably.

CPU, concurrency, and the kind of database

CPU matters for a database, but less universally than memory and storage, and how much depends on the kind of database and its concurrency. The first axis is the workload type. A transactional database — an e-commerce backend, an application’s operational store — runs many small, fast queries where low-latency disk I/O and quick CPU response dominate, and every millisecond is felt by a waiting user. An analytical database — a data warehouse, a ClickHouse deployment running large batch queries — instead wants large memory caches, wide parallelism across many cores, and high storage throughput, because it scans big datasets rather than fetching single rows. An in-memory store like Redis is a third shape again, bounded almost entirely by RAM. The right CPU follows from which of these you are building.

The second axis is concurrency, which is simply how many things hit the database at once. Ten simultaneous connections and ten thousand microservices hammering the database concurrently are completely different problems: the latter demands strong multi-threaded CPU performance, careful connection pooling, and sometimes dedicated query-routing layers. Sizing the CPU means knowing both the query mix and the connection count, then providing cores for the real concurrency with headroom rather than guessing high. The trap to avoid is buying cores to solve a problem that is really about memory or I/O — a database that is slow because its working set spills to disk will not be rescued by more cores, only by more RAM or faster storage, which is why the bottleneck-first habit matters as much here as anywhere.

It is worth adding that modern server CPUs bring database-relevant acceleration beyond raw core count. Recent Intel and AMD generations include vector extensions that speed up the vectorized query execution analytical engines like ClickHouse and PostgreSQL rely on, so a newer CPU can outperform an older one with more cores on the right workload. This is another reason to describe the workload before choosing the chip: the best database CPU is the one matched to the query pattern, not the one with the highest core count on the page.

Bare metal or a cloud database service?

This is the decision that defines a database deployment, and bare metal has an unusually strong case for databases specifically. The reason is the one the storage diagram showed: a database’s data on local NVMe is read in tens of microseconds and stays on the machine, whereas a cloud instance’s block storage is network-attached, sending every I/O across the data center to a shared storage cluster and adding half a millisecond to two milliseconds per operation, with IOPS capped at the provisioned tier. Across millions of small operations that compounds, and it is worst at the tail, where p99 latency stays near median on bare metal but spikes on cloud from noisy-neighbor steal time and storage-network variability. Memory bandwidth, frequently the real bottleneck for databases, follows the same pattern, since cloud VMs share memory channels and receive only a fraction of the hardware’s bandwidth.

The cost gap reinforces the technical one, often dramatically. A dedicated machine with 64 GB of RAM and local NVMe can cost a small fraction of an equivalent managed cloud database, and the IOPS that a few hundred dollars of local NVMe delivers can cost orders of magnitude more through a premium managed service. The table sets the trade-off out.

None of this makes cloud wrong for every database — for variable or small workloads its elasticity and managed operations are real value, covered below — but for steady, performance-sensitive, or cost-sensitive databases, a dedicated server is usually both faster and cheaper, which is why so many teams running databases at scale keep them on bare metal.

High availability, replication, and backups

A database server has to be designed for recovery from the first day, not bolted onto later, because the data it holds is usually the most valuable and least replaceable thing an organization owns. On bare metal that means deliberate redundancy, since a hardware failure is repaired by replacing hardware, which takes time. The standard pattern is replication: a primary database streaming changes to one or more standby replicas, ideally over a private network, so that if the primary fails a standby can take over with minimal data loss and a clear, tested failover procedure. For workloads that cannot tolerate downtime, that replica is not optional; it is the difference between a brief failover and an outage measured in hours.

Backups are a separate discipline from both RAID and replication, and conflating them is a classic, expensive error. RAID survives a dead drive and replication survives a dead server, but neither protects against the deletion, corruption, or bad write that propagates to every copy — only a real backup does. For PostgreSQL and similar engines, the strong approach is continuous archiving of the write-ahead log combined with periodic base backups, which together allow point-in-time recovery — the ability to restore to a precise moment before a problem occurred, rather than only to the last full backup. That scheme needs planning — space for the WAL archive with headroom, since a lagging replica or a broken archive process can pile up log files and fill a disk, plus the network and IOPS to take backups without starving the live workload. And it needs testing: a backup is only real once you have restored from it on a separate machine, because an untested backup is a hope, not a recovery plan.

A worked configuration

It helps to make this concrete. Consider a high-traffic transactional PostgreSQL database of around half a terabyte, serving many thousands of concurrent connections with sub-millisecond query expectations. A sound build pairs 16 cores and 32 threads for the concurrency with 128 GB of ECC RAM to keep the working set cached, on four 2 TB enterprise NVMe drives in RAID 10 for fast, redundant random I/O, with the write-ahead log isolated on separate NVMe so log writes do not contend with query I/O. The snapshot below sketches the shape, including the replication and backup design that makes it survivable.

# database dedicated server · sized to the working set · mcsnet
# example: high-traffic PostgreSQL, OLTP, approx 500GB
cpu      = 16c / 32t              # concurrency: many connections at once
memory   = 128 GB ECC DDR5       # hold the active working set in cache
storage  = 4x 2TB NVMe RAID10    # random IOPS + low latency + redundancy
wal_disk = separate NVMe         # keep WAL/checkpoint I/O off the data disk
replica  = primary to standby, private 10G  # failover ready
backup   = base backup + WAL archive        # point-in-time recovery
restore  = tested on a throwaway box, quarterly  # an untested backup is a hope

Two tuning details round it out. Isolating boot and data so that operating-system activity does not touch the database drives keeps I/O clean, and on dual-socket machines, NUMA-aware placement — pinning the database to the memory local to its cores — avoids cross-socket latency that can quietly degrade performance. These are the kinds of adjustments that are straightforward on hardware you control and impossible on a managed platform that hides the machine.

When does a managed database service fit better?

Honesty requires saying that a dedicated database server is not always the right answer, because managed cloud databases earn their premium in specific situations. The clearest is a variable or unpredictable workload: a managed service lets you scale storage and compute independently and on demand, which is real value when your needs fluctuate rather than holding steady. The second is operational capacity — a managed service handles backups, failover, and patching, so a team with no database operators is not responsible for them, and it gets a small database running in minutes. For an early-stage project, a small application, or a team that simply does not want to run databases, those conveniences can outweigh the cost.

And the cost is the trade. A managed service charges a significant premium over equivalent dedicated hardware, bills separately for storage, provisioned IOPS, and data egress in ways that make the total hard to predict, restricts superuser access and the extensions you can install, and imposes instance-size ceilings and a degree of lock-in. So the decision turns on the workload’s shape: small or variable, or a team without database skills, points toward managed; steady, large, latency-sensitive, or cost-sensitive, or a need for full control, points toward dedicated. There is also a middle path worth naming — a managed dedicated server, where you get the bare-metal performance and control and we run the database operations for you — which is the option we most often recommend to teams that want the dedicated advantages without the staffing.

Databases for email infrastructure

Databases sit underneath email infrastructure more than people expect, and they have the demanding shape this page describes. A sending platform’s database holds accounts, domains, sending configuration, queues, suppression and bounce lists, and the event tracking that records every send, open, and click — and at volume that is a high-write, latency-sensitive workload that benefits from exactly the fast NVMe and consistent latency a database server provides. A slow or contended database behind a mail platform shows up as sluggish queue processing and laggy reporting, which is why we put the database behind our own sending infrastructure on storage built for it.

This is the same discipline applied to our own domain. We size the database to its working set, keep it on enterprise NVMe in a redundant layout, replicate it for failover, and back it up with point-in-time recovery, because the platform’s reliability depends on the database underneath it as much as on the mail transfer agents in front. When we build a database server for a customer, it is informed by running databases under production sending load ourselves rather than from a specification sheet.

It also shapes how we separate concerns. Just as a heavy sending campaign is best isolated from the mailboxes it could affect, a reporting query scanning millions of tracking events is best kept from contending with the live queue writes that keep mail flowing — which in practice can mean a read replica dedicated to analytics, so the operational database stays responsive while the reporting runs against a copy. That is the same replication discipline described earlier, put to work for a specific email workload.

Spec’d and run from Toronto

A database server is a build-to-the-workload machine, so we start from your database rather than a catalogue: the working-set size that sets the RAM, the access pattern and concurrency that set the storage and CPU, and the recovery requirements that set the replication and backup design. Our home data center is in Toronto, giving Canadian data residency and a stable North American base, and we run servers in Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami, with private networking between machines in a location so a primary and its replica can stream over a fast private link rather than the public internet.

For databases that should be run as well as hosted, our managed hosting covers the operations — replication, backups, monitoring, tuning, and recovery testing — so you get the performance and control of dedicated hardware without owning the day-to-day database administration. You can start a configuration in our configurator and we build out the database server, including the replica and backup design, from there. For workloads that need the scale of our top tier, the same approach extends to an enterprise dedicated server sized for very large databases.

Why work with us?

We size database servers the honest way: to the working set and the access pattern, not to the most impressive spec sheet. That means putting the budget where a database actually benefits — memory to cache the hot data, enterprise NVMe in RAID 10 for consistent low-latency I/O, a replica for failover, and tested point-in-time backups — and not over-buying cores to solve a problem that is really about memory or storage. When a managed cloud service would genuinely serve you better, for a small or variable workload, we will say so rather than sell hardware you do not need.

The perspective comes from running databases under real production load for our own sending infrastructure, where a database that stalls under write pressure or loses data to a confused backup is a failure we feel directly. We would rather build the database server your workload actually needs — and run it for you if you want — than quote a machine that benchmarks well and serves the database poorly. A database that stays fast and survives failure is the service.

Who this is for, and who it is not

A database dedicated server is for steady, performance-sensitive, or large database workloads: transactional systems where latency is felt by users, analytical databases scanning big datasets, high-concurrency operational stores, and any database where consistent low latency and full control over configuration and recovery matter. If that is your workload, a server sized to the working set, on enterprise NVMe in RAID 10, with replication and tested backups, is the right foundation — and on steady load it will usually cost a fraction of an equivalent managed cloud database while performing better.

It is not for a small or genuinely variable database that a managed service would run more conveniently, nor for a team with no appetite for database operations that would rather not run one at all — though our managed option closes that gap for teams that want the performance without the administration. Read this page as a guide to a workload-shaped decision: if your database is steady, large, or latency-sensitive, talk to us about a server built around its working set; if it is small or spiky, we will tell you honestly that a managed service may fit better. A database that is fast, consistent, and recoverable is what we are actually offering.