Kaspa RocksDB presets arrived in Rusty Kaspa on January 8, 2026, through merged pull request #771. The change retained the existing SSD/NVMe behavior, added an archive profile tuned for HDD storage, and let operators place write-ahead logs on a separate device. It expanded deployment options, but did not make every disk layout equally fast or durable.

Key takeaways

• Rusty Kaspa PR #771 merged nine commits, changing nine files with 816 additions and seven deletions.
• --rocksdb-preset=archive selected HDD-oriented buffers, compression, file sizes, cache settings, and rate limiting; no preset flag preserved default SSD/NVMe behavior.
• --rocksdb-wal-dir allowed write-ahead logs to live on faster storage while the main database remained on an HDD.
• The PR explicitly warned that volatile RAM-backed WAL storage could cause database corruption after restart.
• Reported compression and file-count benefits were contributor claims tied to the tested configuration, not universal benchmarks for every node.

What did the Kaspa RocksDB presets change?

PR #771 added a RocksDbPreset configuration layer, CLI parsing, database-connection wiring, consensus-factory plumbing, integration-test updates, and an archival-node guide. GitHub records the merge into master at 15:42 UTC on January 8.

The default profile remained aimed at SSD or NVMe storage and required no new flag. The new archive profile was designed for the different access pattern and seek cost of spinning disks. Operators could start an archival node with kaspad --archival --rocksdb-preset=archive, subject to the release and command syntax available at that date.

This was a storage-engine configuration feature, not a consensus-rule change. Nodes still validated the same network data; the preset changed how RocksDB organized and wrote local data.

How did the HDD archive preset differ from the default?

The pull request described a 256 MB write buffer for the archive profile, four times its stated 64 MB default. It configured 256 MB SST files, LZ4 compression for normal levels, Zstandard compression at the bottom level, a 2 GB block cache, larger sequential-read settings, BlobDB for values above 512 bytes, and a 12 MB/s background-write limit.

Those choices target common HDD constraints. Larger batches and files can reduce the number of small random operations, compression can lower capacity requirements, and rate limiting can smooth write bursts. The trade-offs include more memory use, CPU cost for compression, longer compactions, and results that depend on the drive, filesystem, workload, and database state.

The PR stated that 256 MB SST files could reduce a modeled four-terabyte deployment from roughly 500,000 files to 16,000. Treat that as a configuration rationale, not a guarantee that every archive will have the same size or file count.

What is a RocksDB write-ahead log directory?

RocksDB records pending changes in a write-ahead log, or WAL, before durable database structures are fully updated. The new --rocksdb-wal-dir option let operators place those logs on a different path. A hybrid machine could keep bulk database files on an HDD while sending latency-sensitive WAL writes to NVMe.

The implementation generated separate subdirectories for consensus, metadata, and UTXO-index databases. According to the PR, this avoided path collisions observed during testing. The option worked with either preset and remained optional; without it, WAL files stayed with their database.

Separating paths also adds operational dependencies. Both devices need adequate space, correct permissions, monitoring, and a recovery plan. Moving only the WAL does not remove HDD limits affecting compaction, scans, reads, or the rest of synchronization.

Why is RAM-backed WAL storage risky?

The PR mentioned tmpfs on Linux and a RAM-disk approach on Windows as possible ways to reduce SSD writes or gain small performance improvements. It also placed a direct warning beside that idea: volatile WAL storage could lead to database corruption on restart.

A WAL exists specifically to help recover acknowledged changes after a crash. If it disappears when power is lost, the main database may not contain everything needed for consistent recovery. Operators should not copy a performance experiment into production without understanding RocksDB durability semantics, testing unclean shutdowns, and maintaining a verified resynchronization or backup procedure.

For most users, a persistent SSD or NVMe WAL is the more conservative hybrid design. The software option enables a topology; it does not certify the reliability of the selected device.

What did the PR claim about performance?

The contributor reported production testing by a community operator, several days of local HDD testing, 30-50% better compression, 96% fewer files, smoother I/O, and reduced write amplification. Those figures are useful leads, but the PR did not publish a standardized benchmark matrix covering hardware models, initial database size, sync height, RAM, operating system, failure tests, and repeat runs.

A reproducible evaluation should compare default and archive profiles on the same node build and dataset. Measure wall-clock sync time, peak and final disk use, read/write throughput, IOPS, CPU, memory, compaction backlog, restart recovery, and errors. Report median results across multiple runs rather than a single best outcome.

How should an existing archive node migrate?

PR #771 said the change was backward compatible: existing deployments without flags kept the default behavior. It also noted that compression settings are not retroactive. Switching presets affects newly written data, so a fresh synchronization is needed to receive the full layout and compression benefits.

That makes migration a capacity and availability decision. Before rebuilding, confirm free space, expected sync time, access to a known-good node binary, and whether another service depends on the archive. Preserve configuration and keys separately from disposable chain data, and test the exact procedure on non-critical infrastructure first.

Node operators interested in adjacent mining infrastructure can read our Kaspa Stratum Bridge binary guide. A later release-focused overview is available in Rusty Kaspa v1.1.0 RC1.

Frequently asked questions

Should every Kaspa node use the archive preset?

No. It was designed for HDD-oriented archival deployments. The default remained the intended no-flag profile for SSD/NVMe and existing installations.

Does a separate WAL directory make an HDD node as fast as NVMe?

No. It can accelerate one write path, while compaction, reads, scans, and bulk data still depend on the HDD and the rest of the system.

Can an operator safely put the WAL in tmpfs?

The PR warned that a volatile WAL could corrupt the database after restart. It should be treated as an expert experiment, not a safe default.

Source and verification note

All feature, flag, configuration, migration, and warning details are drawn from primary source kaspanet/rusty-kaspa PR #771, merged January 8, 2026, plus its reviewed docs/archival.md change. Diff statistics are GitHub metadata. Performance percentages remain attributed to the PR because no independent benchmark was reproduced for this article. Operators should verify commands against the exact node release they deploy and test durability before changing a production database layout.