Persistence

How the Meshtastic app stores data across different mechanisms.

Room KMP Database

Module: core:database

The primary structured data store:

• Node information and history
• Message history
• Waypoints
• Telemetry data
• Channel configurations

Key Points

• Uses Room KMP for cross-platform compatibility
• Migrations managed through Room's built-in migration system
• DAO interfaces live in core:database
• Repository layer in core:repository provides the public API
• Full-text message search is backed by an FTS5 content table (PacketFts) over Packet, kept in sync by Room-managed triggers

What's Stored in Room

Entity	Description
NodeEntity	All known mesh nodes and their metadata
MyNodeEntity	The local node's own info
Packet	Message history (channel and direct), waypoints, and telemetry data
PacketFts	FTS5 virtual table mirroring Packet.messageText for full-text message search (Room-managed INSERT/UPDATE/DELETE triggers keep it in sync)
ContactSettings	Per-contact mute and read-state
ReactionEntity	Emoji reactions on messages
MeshLog	Raw mesh protocol logs
MetadataEntity	Device metadata (firmware version, hardware model)
QuickChatAction	User-configured quick-chat messages
DeviceHardwareEntity	Cached device hardware catalog
FirmwareReleaseEntity	Cached firmware release info
TracerouteNodePositionEntity	Traceroute hop position data

💡 Note: Waypoints, telemetry, and channel data are stored within the Packet entity (using the port_num field to distinguish packet types) rather than in separate tables.

DataStore Preferences

Module: core:datastore

For lightweight key-value preferences:

• Local radio configuration (LocalConfig proto)
• Module configuration (ModuleConfig proto)
• Channel set data
• Local statistics
• Recently connected device addresses

Core Prefs

Module: core:prefs

Higher-level preferences abstraction:

• User-facing settings
• App behavior configuration
• Feature toggles

What Docs Intentionally Skip

The feature:docs module does not use Room or any persistent database:

• Documentation content is packaged as build-time assets
• The docs corpus is versioned with the app binary
• No migration story is needed for docs content
• Optional UX state (last viewed page) could use core:prefs but is not part of the docs data model

This is an intentional design decision to keep documentation:

• Fully offline without database overhead
• Replaceable with each app update
• Simple to validate and test

Best Practices

• Use Room for structured, queryable data that changes at runtime
• Use DataStore for simple preferences and state
• Use bundled resources/assets for static content
• Never store sensitive data (keys, passwords) in plain Room tables
• Always provide migrations for schema changes

---