Use persistent storage

Move NRF, DPF, DMF, NSSF, and SMSF off in-memory storage onto SQLite or PostgreSQL so registrations, subscribers, and UE context survive a restart.

By default every NF that has a store keeps it in memory: fast and zero-setup, but everything is gone on restart. When you want NF registrations, subscriber data, or UE context to persist across restarts — or to share a database — switch each to a SQLite or PostgreSQL backend.

The UPF has no subscriber store

The UPF keeps no database of sessions. PFCP sessions are re-established by the SMF. It can persist a GTP-U Recovery counter with -recovery-path (userspace/DPDK datapath) so peers detect a restart; that is a file, not a SQL store.

Flag names differ per NF

NRF, DMF, NSSF, and SMSF use -db-driver / -db-dsn. The DPF uses -store / -db. That is the CLI's shape, not a typo.

NRF storage

The NRF picks its backend with -db-driver (memory, sqlite, or postgres; default memory), -db-dsn for the connection string, and -db-migrate to run schema migrations on first start against a durable backend.

Bash

DPF storage

The DPF holds your subscribers (UDM/UDR data). It uses -store ( memory, sqlite, or postgres; default memory), -db for the DSN, and -db-migrate to run migrations. Add -seed to install five test subscribers on any backend.

Bash

DMF storage

The DMF can persist UE context with -db-driver (memory, sqlite, or postgres; default memory) and -db-dsn. Pass -db-migrate on first run against a durable backend. At-rest encryption of NAS session keys needs a master key file; see d3x-core-dmf --help.

Bash

NSSF and SMSF storage

Both optional NFs take -db-driver (memory, sqlite, postgres; default memory) and -db-dsn. SMSF stores SMS contexts; NSSF stores slice-availability state. Pass -db-migrate on first run against SQLite or Postgres.

Bash

Migrations

For SQLite and PostgreSQL the schema must exist before the NF serves requests. Pass -db-migrate on first run to create the schema. If you start an NF against an un-migrated database without that flag, it aborts at startup with a clear error rather than failing requests later. Treat migration as a run-once admin step, not something every replica does on every boot.

Tip

Run -db-migrate once when you first point an NF at a fresh database (and after upgrades that add schema).

When to move off in-memory

You want subscribers, NF registrations, or UE context to survive a restart.
You are running a longer-lived lab rather than a throwaway demo.
You want to inspect or edit the data directly in a database.

For quick experiments, in-memory is still the simplest path — there is nothing to set up and nothing to clean up.

Where to go next

Load subscribers into a persistent DPF in Provisioning subscribers, or see all the flags in the d3x-core-nrf CLI reference and d3x-core-dpf CLI reference.