A unified interface to key/value stores.

Version Downloads License Documentation Dependencies


Mnemonix aims to help you:

It encodes the behaviour, lifecycle, and feature set of a key/value store behind a common GenServer interface, normalizes different store APIs to conform to that interface, polyfills stores lacking features, and exposes access to them through a familiar Map API.

Learn more about starting a store and manipulating it with the Mnemonix API in the documentation.

Pronunciation: /nɛˈmɑːnɪks/noo-MAHN-icks

Mnemonic systems are techniques or strategies consciously used to improve memory. They help use information already stored in long-term memory to make memorization an easier task.

Mnemonics, Wikipedia


:thumbsup: Continuous Integration Test Coverage
Master Build Status Coverage Status
Development Build Status Coverage Status


Obviously, Mnemonix gives you Map-style functions to manipulate various key/value stores. However, Mnemonix also offers extra features beyond simple Map functions. Stores that don’t natively support these features have the capability added through an Elixir polyfill, guaranteeing you can use and switch stores without worrying about what features they support under the hood.

Available features are:



Pull requests are welcome and greatly appreciated!

Please submit them against the development branch rather than master––this allows useful changes to be finessed before release. The GitHub UI should do this by default.

Here are some useful commands if you’ve just forked the project and want to contribute:



Some parts of the test suite are contingent upon configration of out-of-memory systems. Detection of these systems can be configured through environment variables. If they can’t be detected, the parts of the suite that rely on them will be skipped.


By default, the test suite omits doctests. This is because, by nature of the library, for full working examples in documentation to act as integration tests, some external state must be stored in an out-of-memory system. Normal tests have the opportunity to correctly configure these systems; doctests do not.

If you wish to run these, use the environment variable DOCTESTS=true. For them to pass, your system must be configured using the defaults in the setup steps specified above.

The CI server fulfills these requirements, so if you can’t, you can always configure your fork to use travis too, to get the same build environment we use to vet all pull requests.