Storage

Storage can mean many things in Gecko and Firefox.

Possibilities include:

• mozStorage, the API that lives under storage/ in the source tree. This is a C++ wrapper around SQLite that is also exposed to JS via both XPCOM/XPConnect (API docs) and via a friendlier JS wrapper, SQLite.jsm. For Rust, the presumption of action is that Rust code will use for interacting with SQLite. However, there are prototype rust bindings on Bug 1482608 that could end up making some sense for code that is slowly migrating to rust and has existing mozStorage consumers that are highly coupled.
• The profile "storage/" directory that holds per-origin storage managed by the QuotaManager subsystem and its clients: IndexedDB, the Cache API, and the asm.js cache (which will be removed).

Storage Alternatives

There are many options for storing data in Gecko. The Browser Architecture Group has cataloged many of the existing uses.

If you are looking for a way to store data in Firefox, here are the usual options:

• JSON flat files. This usually is not a viable option from C++ because we don't have convenient ways to manipulate JS objects from C++.
• rkv, a "simple, humane, typed Rust interface to LMDB" available in Gecko since Firefox 63. LMDB is a memory-mapped flat file database.
• SQLite
  • For JS code: Use SQLite.jsm. The XPConnect interface to the mozStorage API used by C++ is also a possibility, but please consider enhancing SQLite.jsm if it's missing something you need.
  • For C++ code: Use mozStorage.
  • For Rust: This hasn't happened yet, but the presumption is that rust code will use Rusqlite as that's what's being used by the application services group and that's what mentat had used. As noted up top, there are prototype rust bindings on Bug 1482608 that could make sense for a legacy consumer like Places, but there's a lot of questions and flux going on here. Please reach out to the Storage Advisory Group to be part of the conversation on this if you're moving towards implementations with Rust and SQLite.