Ceph BlueStore DB and WAL SSD sizing

How much SSD an HDD OSD needs for BlueStore DB and WAL

Size the BlueStore DB device to the whole fleet, share it on purpose, and watch for spillover from the first day of operation. Each HDD OSD keeps its object data on the spinning disk, but its BlueStore DB and WAL hold metadata and write-ahead traffic that benefit from low-latency SSD or NVMe media. The Ceph hardware recommendations advise moving WAL and DB onto shared SSDs for HDD-based OSDs and using enterprise-class SSDs for metadata, which sets the starting point for this decision. Before you buy, confirm the DB sizing guidance for the release you will deploy. The 2.5 percent guideline in the Squid documentation applies from Squid onward, and older guidance for RGW and RBD workloads used different ratios, so take the figure from your target release's documentation and confirm it with your hardware vendor.

Sharing one SSD across several HDD OSDs saves drive bays and cost, but it also concentrates risk. If the shared device fails, every OSD that depends on its DB goes down with it, so the number of OSDs per SSD should follow from your failure domains and recovery plan. Check that the device can absorb the combined write load of its OSDs for its rated life. Ask vendors for endurance ratings under a write pattern that matches your workload, and ask for the power-loss protection specification, which matters for metadata devices. Benchmark a candidate layout before committing, because the ratio that works for a backup target will not suit a latency-sensitive block pool.

Spillover happens when the DB fills and BlueStore places metadata on the slower HDD, which degrades performance without an obvious failure. Check ceph health detail and the OSD metrics your monitoring collects after cluster expansion, large object churn, and pool changes, and treat any spillover warning as a capacity signal for the next hardware order. Bring in an outside partner when the layout must be settled before purchase, because DB device size, sharing ratio, failure domains and the migration of existing OSDs are linked and costly to redo. For RGW, bucket indexes and many small objects add metadata pressure to the DB. For RBD, large images usually place less load on it, though snapshots and clones add metadata. Confirm these effects with a benchmark on your own hardware.

What the DB and WAL hold on an HDD OSD

BlueStore keeps object data on the HDD and moves the metadata and recent write journaling to faster media. Each HDD-based OSD has a data device that holds the object payloads. Alongside it, the DB holds RocksDB metadata, which is the index that maps objects to their locations on disk. The WAL holds recent write journaling, the short-lived record of writes that BlueStore has accepted but not yet committed to the main data device. Before you size anything, you need to know that these are two distinct roles, even though they can share one device or be split across two partitions or volumes.

The Ceph hardware recommendations advise moving WAL and DB onto shared SSDs for HDD-based OSDs. The reason follows from the workload. Small, random metadata operations are the hardest work for a spinning disk, because each one requires head movement and rotational latency. When that metadata lives on flash, the HDD is left to handle the large sequential data transfers it does well. The same guidance calls for enterprise-class SSDs for metadata, so the shared device should be chosen for write endurance and consistent latency, not for the lowest price per gigabyte.

Confirm two things before you turn this into a purchase. First, check the Ceph hardware recommendations for the release you will deploy, since the guidance and any sizing advice are versioned with the documentation. Second, decide whether your use is dominated by small object or metadata-heavy access, or by large sequential transfers, because that determines how much the DB will be asked to hold. Ask your hardware vendor which SSD models they will supply, and confirm their endurance and latency specifications against the Ceph guidance before accepting a quote.

Sizing approaches for DB and WAL on HDD OSDs

This table compares the main ways to place BlueStore DB and WAL for HDD OSDs, from a dedicated SSD partition per OSD to keeping metadata on the HDD. Read each row for when it fits, its main trade-off, and what to check in the Ceph documentation for your release before you size anything. The key takeaway is that sizing guidance has changed across releases, so confirm the current figure for your version first.

Approach	When it fits	Main trade-off	What to confirm for your release
Dedicated SSD partition per OSD	HDD OSDs that need isolated metadata performance and have enough SSD slots	One SSD failure takes down every OSD whose DB it holds	Partition size per OSD and the device layout cephadm creates
One SSD shared by several OSDs	Dense HDD hosts where SSD slots or budget are limited	Larger blast radius per SSD and more contention during recovery	The maximum OSDs per SSD your failure plan can tolerate
DB partition with WAL following it	Most HDD layouts, since WAL placed with DB needs no separate device	Less control over WAL sizing and no dedicated WAL device for commit latency	Whether your release co-locates WAL with DB when only a DB device is given
Squid-era DB sizing (2.5% rule)	Squid (19.2.x) clusters sizing DB from HDD capacity	A fixed ratio can undersize DB for metadata-heavy workloads such as many small objects	The exact ratio and whether it applies to block, file and object pools in current Squid docs
Older RGW guidance	Object storage clusters that inherited sizing from earlier releases	Figures written for earlier RGW layouts may not match bucket index and small object metadata today	Current RGW index pool placement advice and the release the guidance was written for
Older RBD guidance	Block workloads planned from earlier RBD documentation	Older figures may not reflect current BlueStore behavior or spillover handling	Whether the RBD sizing still applies to your release and workload
Keep DB on the HDD	Cold or archive data, or budgets with no SSD for metadata	Metadata lookups and small writes compete with data on the same spindle	Current hardware guidance on separate DB devices for HDD OSDs in your release

Four factors that decide how many OSDs share one SSD

The number of HDD OSDs that can share one SSD is set by four factors that pull against each other. Endurance and capacity set the ceiling, host layout sets the demand, failure scope sets the risk, and workload mix sets how much metadata each OSD generates. Measure the last two on your own hardware before you commit to a ratio.

SSD endurance and capacity

The shared device must hold the DB and WAL partitions for every OSD it serves, and it absorbs all their metadata writes. A higher-endurance enterprise SSD tolerates more OSDs per device before wear becomes a planning problem, while a read-optimized drive does not. Check the drive's rated endurance and the capacity each OSD's DB partition receives, then confirm both with the vendor's write-rate guidance for your workload. Fewer, larger SSDs lower the ratio of devices to manage but raise the cost of losing one.

Number and size of HDDs per host

The sharing ratio is capped by how many HDD OSDs a host carries and how large each one is. Hosts with many large HDDs produce more metadata demand per SSD, which pushes the ratio down. Hosts with a few drives leave room for more OSDs per SSD, but they also spread the hardware budget thinly. Count the OSDs per host, add the DB and WAL partitions each one needs, and check that the SSD slots and PCIe lanes in the chassis fit the plan.

Blast radius of one SSD failure

When a shared SSD dies, every OSD whose DB or WAL sits on it goes down with it. Each of those OSDs then needs to recover its data from replicas or erasure-coded peers, so a high sharing ratio multiplies the recovery load after a single device failure. Decide how many OSDs you can afford to lose at once, and check that recovery traffic fits your network and your failure domain design. A lower ratio limits the damage but costs more SSD slots and money.

Small RGW objects versus RBD block I/O

Workload mix changes how much metadata each OSD produces. Object gateway pools with many small objects generate heavy RocksDB metadata traffic, so they push the DB device harder and reduce the safe ratio. RBD block workloads with large sequential or mixed I/O on fewer, larger objects usually generate less metadata per terabyte. Measure object counts and I/O sizes on a pilot before fixing a ratio, and confirm the figures with a benchmark on the candidate hardware, because the Ceph hardware recommendations advise benchmarking before buying.

BlueStore DB spillover: what happens when the DB device fills

When the DB device behind an HDD OSD runs out of space, BlueStore keeps placing metadata on the HDD, a condition called spillover. The data itself is not lost or corrupted. What changes is speed: metadata lookups that should hit the SSD now go to the slower spinning disk, so operations that depend on metadata, such as small-object writes and recovery, get slower on those OSDs. Spillover is therefore a sizing signal. It tells you the DB device was smaller than the metadata the OSD accumulated, and it should prompt a review of your DB-to-HDD ratio before the condition spreads across the fleet.

Spillover appears in cluster health output as a warning, and the OSD itself reports the condition. Confirm the exact health warning name, the command that lists affected OSDs, and the OSD metric or counter that shows DB usage on your release in the current Ceph documentation, because these names have changed between releases and should not be copied from older runbooks. The Ceph hardware recommendations are the right starting point for the sizing guidance that applies to your hardware. Check spillover on every OSD that shares an SSD, since a single undersized DB partition often shows up first on the OSDs that write the most small objects.

Treat spillover as a trend, not a one-time alarm. Record how many OSDs report it at each capacity review and compare that count as the cluster fills, because metadata grows with the number of objects, not only with raw capacity. If the count rises, plan a rebuild of affected OSDs with larger DB partitions or add SSD capacity, and schedule that work for a maintenance window. Ask any partner or vendor quoting the work to state which OSDs and DB sizes they assumed, and to show how the spillover count will be tracked after handover.

Which DB sizing guidance applies to your release and workload

Squid (19.2.x, first released September 26, 2024) is the release line where the percentage-based DB sizing guidance is most often cited for new HDD OSD planning. Tentacle (20.2.x, first released November 18, 2025) is the newer actively maintained line, so a new cluster may target it instead. Confirm the exact release you will deploy before adopting any figure, because the guidance belongs to the documentation for that release.

Check the release docs first: Read the BlueStore and cephadm sections for the exact release you will install, and record the documentation version you relied on.
Plan for Squid's support window: Squid's estimated end of life is October 31, 2026, so a Squid build needs a dated upgrade path to a later line such as Tentacle.
Model the workload above the percentage: Metadata-heavy use, many small objects or sustained high write rates can push DB needs above a simple proportion of the data device, so test before fixing a ratio.
Confirm how spillover is reported: Ask how the release shows DB usage and spillover onto the slow device, then set monitoring thresholds to match.

Before quoting any percentage, confirm the exact figure, its base (raw or data device capacity), and whether it applies to your target release.

Sizing and deploying BlueStore DB devices with cephadm

This sequence takes you from a host inventory to a deployed set of HDD OSDs with their BlueStore DB on shared SSDs, with a check at each step. Each step produces a written record you can review before any hardware is bought or any OSD is created.

Inventory HDDs and SSD slots per host
Record, for each host, the number of HDDs that will become OSDs, their capacity, and the free SSD slots or bays available for DB devices. Confirm whether all hosts have the same layout. Run ceph orch device ls and lsblk on each host to see which devices are rotational, which are available, and whether any already hold partitions or data. Done when one table covers every host and every HDD is listed as available.
Derive the DB size per OSD
Read the BlueStore sizing guidance in the hardware recommendations for your Ceph release, since the rule for HDD OSDs has changed between releases. Confirm whether the guidance differs for RGW and RBD workloads, and confirm any figure with your release notes before you use it. Multiply the rule by one HDD's capacity to get the DB size per OSD, then multiply by the number of OSDs that will share one SSD. Done when you have a written DB size per OSD and the release it came from.
Choose SSD class and count
Select enterprise-class SSDs, as the hardware recommendations advise for metadata, and check write endurance and power-loss protection on the datasheet. Divide the total DB space needed per host by usable SSD capacity, then add free slots for growth. Ask the vendor how many OSDs one SSD failure takes offline, since each shared SSD is a shared failure point. Done when the per-host SSD count, model and OSD-to-SSD ratio are written down.
Benchmark candidate hardware before buying
The hardware recommendations advise benchmarking before buying because no two clusters behave alike. Build one test host with a candidate SSD and HDDs, deploy a few OSDs with and without a DB device, and measure latency and throughput with rados bench or a block-level test such as fio against an RBD image. Compare results against the workload you expect. Done when measured results for the candidate SSD and OSD ratio are recorded and approved before purchase.
Write the OSD service specification
Create an osd-spec.yaml file that sets service_type: osd, a service_id, a host placement, data_devices filtered to rotational devices, and db_devices filtered to non-rotational devices. Use the sibling topic on Ceph OSD service specifications for the filter syntax and options such as size or model limits. Keep the spec tied to the layout from step one so the preview can be checked against it. Done when the file is saved in version control and reviewed by a second engineer.
Run the OSD spec as a dry run
Apply the spec with ceph orch apply -i osd-spec.yaml --dry-run and read the preview. Confirm that each HDD appears as a data device, that the matching SSD appears as its DB device, and that the DB size per OSD matches your figure from step two. Check that no SSD or HDD is assigned twice. If the preview does not match the plan, fix the spec first and run the dry run again. Done when the preview matches the written plan exactly.
Deploy the OSDs
Apply the same spec without the dry-run flag using ceph orch apply -i osd-spec.yaml. Watch the new daemons with ceph orch ps and the layout with ceph osd tree. Then monitor ceph -s while placement groups settle, since recovery time depends on the data present and the network. Done when every new OSD reports up and in, and the cluster either returns to HEALTH_OK or each remaining warning is explained and assigned.
Verify DB placement and free DB space
For a sample of OSDs, confirm with ceph osd metadata that the DB device is on the intended SSD. Check BlueFS usage with ceph tell osd.<id> bluefs stats, confirming the command for your release first, and record free DB space per OSD. Run ceph health detail and look for BlueFS spillover warnings, which mean DB data has moved onto the HDD. Done when each sampled OSD shows its DB on the SSD, free space is recorded, and no spillover warning is open. Schedule the same check after capacity grows.

Operational risks when one SSD serves many OSDs

A shared SSD concentrates risk: one device failure touches every HDD OSD it serves, and the problems compound if wear, capacity or memory are left unwatched. The cards below name the control to put in place for each risk and what to confirm in your own environment before you commit to a layout.

Losing one SSD takes OSDs down together

Each HDD OSD that uses this SSD for its DB or WAL depends on it, so one failed drive takes all of those OSDs out at once. Your replica or erasure code settings must still tolerate that loss, and the CRUSH rule should keep copies on hosts that do not share the same SSD. Confirm how many OSDs one SSD serves in your layout and whether your pools survive losing all of them in one host.

SSD wear and capacity monitoring

DB and WAL devices absorb heavy small writes, so their wear and free space need their own alerts, separate from HDD health. Track the drive's wear indicator from SMART data and watch for DB usage approaching its partition size, since a full DB spills onto the slow device. Confirm that your monitoring reads SSD wear and per-OSD DB usage, not only overall cluster health.

Replacement procedure that rebuilds affected OSDs

Replacing a failed shared SSD means recreating every OSD whose DB or WAL lived on it, and each of those OSDs must backfill its data again. Write the runbook before the first failure: which OSD specifications redeploy the DB partitions, how recovery traffic is throttled, and the order of replacement. Confirm the rebuild time for your capacity with a test on your own hardware, because recovery duration depends on drive size, network and load.

Encryption of DB devices and key handling

If OSDs are encrypted, the DB and WAL partitions on the shared SSD need the same protection as the data devices. Decide where the encryption keys are stored and who can retrieve them, and make sure a replacement SSD can be unlocked and reused without exposing keys. Confirm that your key management process covers DB partitions, and test an OSD restore on a spare host before you rely on it.

Memory sized for peak use

Each OSD needs memory, and the hardware recommendations say to size for peak use rather than quiet periods. Peaks come during recovery and backfill after a shared SSD fails, when many OSDs rebuild at once on the same host. Confirm the per-OSD memory target you plan to set, and check that the host still has headroom with the affected OSDs recovering together.

Questions buyers ask about DB and WAL sizing

What drives the cost of sizing BlueStore DB and WAL devices for HDD OSDs?

The main cost driver is how many HDD OSDs need a shared SSD and how many hosts those OSDs sit in, because each host has its own drive layout, bays and failure domain to plan. Cost also rises with the number of media types already in the cluster, the amount of existing data that must be moved to rebuild OSDs with new DB devices, and whether the work includes benchmarking candidate SSDs. Ask for a quote that lists the hosts in scope, the OSD count per host, the SSD model and endurance assumptions, and whether the deliverable is a written sizing and layout or the rebuild of live OSDs. Hardware purchases are a separate line item from the engineering work, and they are one-time costs.

Can our own team size the DB devices without outside help?

Yes, many teams can, provided they have someone comfortable reading Ceph's BlueStore documentation, checking drive inventory and running benchmarks on candidate hardware. The sizing itself is arithmetic on the planned HDD capacity and the DB size guidance for the Ceph release you run, so the harder part is usually the operational decisions around it: how many OSDs share one SSD, how a failed SSD takes several OSDs down with it, and how spillover will be watched. An outside team can review your numbers, challenge the failure-domain consequences and document the result. Confirm internally whether you have time to test before buying, because the Ceph hardware recommendations advise benchmarking candidate hardware before purchase.

How long does DB and WAL sizing take, and what sets that time?

The duration depends on the number of hosts, the drive layouts already in place and whether the sizing is a design review or includes rebuilding OSDs. A design-only review of a small cluster is short compared with a plan that covers many hosts, a rolling rebuild and benchmarks of several SSD candidates. Time also depends on your procurement lead time, the availability of maintenance windows and how quickly you can confirm the Ceph release in use. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts, and any figure you see should come from that written scope rather than from a general estimate. Ask for the milestones and the dependencies they rely on.

What do we need to provide for the sizing work?

Expect to supply a current inventory of hosts, HDD models and capacities, OSD counts per host, the Ceph release and the cephadm service specifications in use. You will also need access to a test environment or a spare host for benchmarks, the planned workload profile for block, file or object use, and a named contact who can approve changes. For any rebuild, plan maintenance windows, confirm backup and recovery procedures, and agree how recovery traffic will be limited during business hours. Your team should also own the monitoring that will watch for spillover and SSD wear after go-live. Listing these items in the scope protects both sides when dates are set.

Can the DB size of an OSD change after it is deployed?

This needs to be confirmed against the Ceph release and the procedure you plan to use before you rely on it. In general, a BlueStore OSD's DB device is set when the OSD is created, so changing it usually means draining the OSD and recreating it, which moves data across the cluster. Whether a newer release offers a supported way to resize or migrate DB volumes in place is a question for the Ceph documentation for your exact version and for a tested runbook. Ask any partner to show the procedure for your release, the recovery time it implies and the risk to redundancy while it runs. Plan the initial DB size with growth in mind, since changing it later is operationally expensive.

How is a fixed-scope DB and WAL sizing engagement agreed in writing?

A fixed-scope engagement starts with a written statement of scope that lists the hosts and OSDs covered, the Ceph release, the deliverables such as a sizing workbook, device layout specifications and a runbook, and the acceptance checks. The document also states what is excluded, such as hardware purchase, OSD rebuilds on production hosts or ongoing spillover monitoring. Responsibilities for your staff, maintenance windows and the change process are written down, along with how changes to scope are priced and approved. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the document before signing and check that each deliverable is verifiable.

Limits to confirm before you buy SSDs

The DB and WAL sizing guidance depends on your release, your upgrade timeline, your SSD choice and your hardware. Each card below names one limit to confirm before you order drives, so the layout you buy still fits the cluster you run.

Confirm the guidance for your release

The DB sizing rule in this guide applies to specific Ceph releases, so confirm it covers the exact release you will deploy. Read the BlueStore and OSD documentation for that version before you order drives. If you plan to deploy Tentacle, check that the guidance you are following is written for Tentacle. Match the release number to the documentation version you read. Record that version in your bill of materials so the SSD decision can be traced later.

Plan around Squid end of life

Squid's estimated end of life falls inside the planning horizon of a new build, so the SSD layout you choose now may need to survive a release change. Confirm the estimate on the releases page and compare it with your upgrade window. Decide whether you will move to a newer release first or plan a later upgrade. Treat the estimate as a planning date and recheck it close to purchase.

Check whether DB devices can be resized

A DB device that fills up pushes metadata onto the slow HDD, so growth matters as much as the starting size. Confirm in the documentation for your release whether a BlueStore DB or WAL device can be enlarged in place, or whether the OSD must be drained and recreated. Recreating OSDs moves data and loads the cluster, which changes your maintenance plan. Get the resize procedure in writing before you fix the device size. Test it on a lab OSD first.

Confirm SSD endurance and class

DB and WAL devices absorb frequent small metadata writes, so endurance and sustained write behavior determine how long a drive lasts. Choose enterprise-class SSDs with power-loss protection, and compare the rated endurance with your expected write load and warranty terms. Consumer drives can perform well in a short test and slow down under sustained load. Get the endurance rating and sustained write figures from the vendor datasheet. Use one device class per layout so OSD specifications select the same drives each time.

Revisit the design for all-flash

Separate DB devices exist to place metadata on faster media than the HDD data. In an all-flash cluster the data already sits on SSD or NVMe, so the case for a shared DB device changes. Work through the sibling all-flash NVMe design topic before you buy a second tier of drives. Decide whether DB devices still earn their cost on your media mix. Include the failure impact of a shared DB device, since losing one can take every OSD that depends on it offline, along with the rebuild effect.

Benchmark candidate hardware first

Ceph's hardware guidance advises benchmarking before buying because no two clusters behave alike. Build a test layout with the HDDs, SSDs and shared DB ratio you plan to order, then measure client latency, throughput and recovery behavior under load. Compare results with and without the DB device so the purchase rests on your own data. Run the benchmark on the same release you will deploy. Keep the results with the bill of materials so the decision can be reviewed later.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the sizing of BlueStore DB and WAL devices for HDD OSDs. Engagements are fixed-scope, so the media plan, failure impact and handover material are agreed in writing before any hardware is ordered or configured.

How we scope

Inventory the HDD OSD count per host, drive capacity and planned pool types before choosing SSD sizes.
Confirm the Ceph release and whether the 2.5 percent guidance or older RGW and RBD guidance applies.
Document how many OSDs will share each SSD and the failure impact if that SSD is lost.
Agree deliverables, exclusions and acceptance checks in writing; ongoing support is available as a retainer.

How we build

Create the DB and WAL device layout with cephadm service specifications and verify each OSD's device placement.
Benchmark candidate SSDs and HDDs in your environment, since no two clusters behave alike.
Size memory for peak recovery load alongside the DB devices, not for quiet periods.
Test spillover behavior by filling a staging pool and checking BlueStore usage and warnings.

How we hand over

Deliver a sizing record listing each host, OSD, DB and WAL device, and the reasoning behind the ratio.
Provide the runbook for replacing a failed shared SSD, including which OSDs must be rebuilt.
Document monitoring thresholds for DB usage, spillover and slow requests, with alerts you own.
Walk your operations team through the procedure and record the open items for your sign-off.

How we support

Review DB fill and spillover trends after capacity growth or a Ceph upgrade.
Re-plan SSD layout when you add HDD hosts, change drive sizes or adopt a newer release.
Run retainer-based checks on device health and sizing assumptions at intervals agreed in the contract.
Confirm each change against the release notes for your Ceph version before it reaches production.