Solutions · Databases

Database appliances — specified for latency, not throughput

A database appliance is a server where the storage layout, the memory sizing and the network were decided for a database. Log on low-latency NVMe, data on NVMe or a mixed tier, capacity on SAS, and HA pairs where downtime costs more than the second machine.

• NVMe tiers — Log, data, capacity
• HA pairs — Two nodes and a witness
• Memory first — Sized to the working set
• Latency, not IOPS — The number that hurts
• Burn-in tested — 24 to 72 hours

The difference

A database is not a workload a general-purpose host happens to run

Most servers are specified for throughput: how much work per hour, on average. A database is specified for the opposite — the slowest response anybody sees, under the load that arrives at the worst moment. An average is a comfortable number and it tells you almost nothing about whether a month-end run finishes before the morning.

That changes what you buy. Memory matters more than cores, because a working set held in RAM is a query that never touches a disk. Write latency matters more than sequential speed, because a committed transaction waits for the log to be durable and nothing else proceeds until it is. And the storage layout matters more than the storage total, because a log fsync stuck behind a table scan is the shape of most database complaints.

A database appliance is simply a machine where those three decisions were made deliberately rather than inherited from a virtualisation template.

The layout

Three tiers, and what each one is protecting

Nearly every database build we ship separates these. The alternative — one pool for everything — works until concurrency arrives.

• Log and WAL on low-latency NVMe — Every commit waits here. This tier is sized for sync write latency and endurance rather than capacity, and it is the one place where the cheaper drive is never the right answer.
• Data on NVMe or a mixed tier — The working set and the indexes. Sized against the data that is actually touched rather than the database's total size, which is usually a much smaller number and a much better buy.
• Capacity and backup on SAS — Archive partitions, older shards, and the local backup landing zone. Cheap per terabyte, and deliberately not sharing spindles with the log.

Availability

HA pairs, and what they actually promise

A pair is the common shape. It is worth being exact about what it covers, because the failures people plan for and the failures they have are rarely the same.

• Two nodes and a witness — Synchronous or near-synchronous replication between a primary and a standby, with a third small vote so a network partition cannot leave both convinced they are primary.
• What it covers — A node failure, a planned patch, a controlled failover for maintenance. Recovery is measured in seconds to a minute depending on the engine and on how honest the health check is.
• What it does not cover — A dropped table, a bad migration or an encryption event. Replication copies those faithfully and immediately. Backups and retention are a separate requirement, and the appliance is sized with one.
• The link between them — Synchronous replication puts the inter-node network in the commit path. It gets its own interfaces and its own switch consideration, not a VLAN on the interface that also carries clients.

Seven questions

The ones a DBA answers in a sentence and a tender never asks

Half of these are questions a DBA answers in a sentence and a procurement document never asks. They are what separate a sized appliance from a large server.

• Which engine, and which version? — Why it changes the build: PostgreSQL, MySQL or MariaDB, Microsoft SQL Server and Oracle have different memory models, different licensing arithmetic and different opinions about storage.
• Dataset size, and working-set size? — Why it changes the build: The second is the one that sets memory, and it is usually a fraction of the first. Buying RAM for the total is the most common way to overspend here.
• Reads or writes, and how concurrent? — Why it changes the build: A read-heavy reporting store and a write-heavy transactional system want different tiers and sometimes different machines.
• What latency is a problem? — Why it changes the build: The number that makes someone complain, not the average. It decides the log tier and often decides the whole layout.
• RPO and RTO? — Why it changes the build: How much data you can lose and how long you can be down. These decide synchronous versus asynchronous, and whether a pair is enough.
• Licence model? — Why it changes the build: Per-core licensing can make a smaller, faster machine cheaper overall than a larger one — the hardware decision and the licence decision have to be taken together.
• Backup window and target? — Why it changes the build: A backup that does not fit its window is a backup that stops happening. The target is sized with the appliance, not after it.

Under the database

What the machine has to get right

• Sized to the workload — Cores, memory, storage tiers and network chosen for the database, not a catalogue tier. Dual socket where the licence allows it and single where it does not.
• What the burn-in is looking for — CPU, memory and storage stress with thermal checks and a SMART review. A marginal DIMM under a database is a corruption report, not a slow afternoon.
• Validated across hypervisors — Bare metal or virtualised — platforms are validated for Proxmox VE, VMware ESXi, XCP-ng, Hyper-V and Nutanix AHV, so the deployment decision stays open.
• Firmware baseline recorded — The BIOS, controller and drive revisions the build was validated on, written down and shipped, so the standby node still matches the primary a year later.
• Backup planned with it — Local landing zone on the appliance, and a separate target beyond it. A pair with no third copy is one bad migration from a very long day.
• Built, tested and supported here — Integrated and manufactured in India, burn-in tested before dispatch, and covered by the warranty and response terms set out on the services page — the same for every machine we build.

Straight answers

Where NVMe pays for itself, and where it does not

• Is an appliance different from a normal server? — Answer: Only in that the decisions were made for a database. Same standard x86 parts, same chassis families — the difference is the storage layout, the memory sizing and the network, and those are the differences that matter.
• Do we need NVMe throughout? — Answer: Rarely. The log tier justifies it almost always, the data tier usually, and capacity almost never. Paying for NVMe on archive partitions is the second most common way to overspend.
• Can it be virtualised? — Answer: Yes, and most are. The tiers and the latency budget do not change; what changes is that you must stop the hypervisor's other guests from competing for the log tier.
• Two nodes or three? — Answer: Two plus a witness for most estates. Three when the engine's own clustering wants an odd number, or when you need to survive losing a node while another is patched.
• Does replication mean we can skip backups? — Answer: No. Replication is for availability. Backups are for mistakes, and the two failures look nothing alike.

Do the arithmetic

Size it before the licence is counted

• VM sizing calculator — Cores, memory and the reserves that decide what a host really holds.
• RAID capacity planner — Usable capacity, redundancy overhead and rebuild exposure across RAID levels.
• All sizing tools — Six calculators running the same arithmetic our engineers do.

The chassis

Where a database appliance usually starts

The chassis, and the storage that sits beside it.

• 2U rack servers — The usual shape — dual socket, NVMe and SAS tiers, redundant power.
• SNS flash storage — All-flash shared storage where the database estate outgrows local disks.
• Dual socket tower servers — The same build for a server room without a rack, at quieter acoustics.