Clarifying the Polkadot SDK database roadmap: RocksDB, ParityDB, and NOMT

Tech Talk
1

As of 13 June 2026, the Polkadot SDK database story looks unclear from the outside. RocksDB remains the effective default in normal SDK builds, ParityDB is supported but not default, and NOMT/binary-trie support exists as design discussion but not a committed integration path.

The goal of this post is to make the current state explicit so stale issues and PRs can be closed, superseded, or resourced.

Current state

RocksDB is still the effective default.

sc-cli and sc-service enable the rocksdb feature by default, and SDK configuration falls back to Database::RocksDb when that feature is present. ParityDB is available through --database paritydb, and auto checks for an existing RocksDB database first before creating/opening ParityDB in the no-existing-db case.

The CLI still accepts paritydb-experimental, but only as a deprecated alias. The current option is paritydb.

ParityDB was proposed as the default, but that effort stalled.

PR #1792 proposed making ParityDB the default and deprecating RocksDB, but it remains open and stale. The discussion raised serious archive-sync and large-state concerns, including reports of Kusama archive sync taking around a month on ParityDB versus one or two days on RocksDB, and a Rococo archive comparison of 13 days on ParityDB versus 40 hours on RocksDB.

The intended fix appears to have been ParityDB tree/multitree storage, tracked in parity-db#199 and SDK PRs #3386 / #4176. Those remain unresolved or unmerged.

ParityDB maintenance and SDK integration.

in 2025, maintainers said in Issue #8149 the previous default switch was blocked by unresolved issues, the status was unclear, and without resources or a committed support plan the SDK should keep the current status quo.

The ParityDB repo is not archived and has recent activity, including a 2026 v0.5.5 commit. However, Polkadot SDK still pins parity-db = 0.4.12, while crates.io has 0.5.5.

NOMT is active upstream, but not integrated into the SDK.

NOMT is an active external project and describes itself as a high-throughput Merklized key-value store / drop-in replacement for RocksDB, MDBX, LevelDB, or ParityDB. In Polkadot SDK, the main discussion appears to be #5614, which proposes moving toward binary tries and NOMT compatibility.

That discussion also shows that NOMT support is not a simple database swap:

  • NOMT depends on the trie layout and node format, not just the underlying key-value database.
  • Substrate’s current trie nodes are SCALE-encoded, which is not directly compatible with NOMT.
  • NOMT currently assumes fixed-size 256-bit keys, while Substrate storage uses arbitrary-length keys.
  • Substrate also relies on prefix iteration and ordered storage access, which many pallets depend on.
  • Hashing all Substrate keys into fixed-size keys could fit NOMT’s model, but would break those prefix and iteration semantics.

JAM context.

JAM’s storage design appears to move in a different direction from today’s Substrate state backend. The Graypaper defines state serialization as a mapping from fixed 31-octet state keys to values, and commits that mapping with a binary Patricia Merkle Trie. It also notes that service storage keys are not directly inspected or enumerated, and that implementations only need the Merklization-ready fixed-size representation.

That is relevant to the NOMT discussion because it avoids some of the current Substrate problems around arbitrary-length keys and prefix iteration. However, it does not mean JAM has adopted NOMT, RocksDB, or ParityDB as a canonical database. The JAM prize rules require trie/DB performance testing, and public discussion says third-party databases are acceptable, but the protocol does not appear to prescribe a specific storage engine.

The current public Rust JAM implementation picture is also incomplete. The official client list includes Rust clients such as PolkaJAM, SpaceJAM, Vinwolf, FastRoll, Grey, Jamers, and JamLiquor, and the conformance dashboard benchmarks several of them. But PolkaJAM source is currently binary-only, and the public Rust client repositories I checked either do not expose a production state DB choice or are too early/prototype-level to draw a strong conclusion.

The problem

The public facing discussion is contradictory:

  • code says RocksDB is the default in normal builds;
  • open issues ask to make ParityDB the default and stop calling it experimental;
  • an old PR tried to deprecate RocksDB but never landed;
  • ParityDB performance/blocker issues remain open;
  • NOMT/binary-trie work has a broad target but no accepted SDK roadmap;
  • operators and parachain teams cannot tell which backend is the right strategic move.

Possible way forward

  1. If RocksDB remains the supported default for 2026, close or supersede #1792 and #8149, update docs to say ParityDB is optional/advanced, and document known caveats for archive nodes and snapshots.

  2. If ParityDB is still intended to become default, assign an owner and acceptance criteria: SDK dependency update, resolution or explicit closure of parity-db#199, resolution of #3386 / #4176, fresh archive-sync benchmarks on Polkadot/Kusama/Rococo, snapshot/recovery guidance, and a staged RocksDB deprecation plan.

  3. If NOMT/binary trie is the strategic direction, create one tracking issue or ADR that supersedes the scattered discussion. It should decide whether the first step is a binary trie in Substrate, direct NOMT integration, or a storage abstraction that can host multiple commitment backends. It should explicitly cover variable-length keys, prefix iteration, child tries, migration, proofs, benchmarking, and operator rollout.

  4. Clean up stale issues and PRs. Close or mark as superseded old PRs and issues that no longer represent the plan. If any DB repo or integration path is legacy-only, say that clearly. If it is still strategic, make ownership and maintenance visible.

Questions for maintainers

  • Is RocksDB still the official production default?
  • Is ParityDB expected to become default, or should it remain optional?
  • Is ParityDB MultiTree still intended to solve the archive-sync issue?
  • Should SDK update parity-db from 0.4.12 toward current 0.5.x?
  • Is the NOMT path “binary trie first, NOMT later”, or should direct NOMT integration be prototyped now?
  • Who owns the database/storage roadmap?

References

2

We’ve been using ParityDb with midnight and it’s been performing fine so far but our datasets are still relatively small. Agreed NOMT isn’t a drop in replacement.