Backends

ModeratorIM stores its data through a backend-agnostic port: the core and apps read and write via a datastore interface, and a backend adapter maps that interface onto concrete storage. This keeps the platform portable and avoids lock-in — a new backend is an adapter, not a rewrite.

Shipped backends

Postgres (the first backend)

The first production backend. It implements the datastore port against PostgreSQL, materializing each unit’s declared tables (prefixed by the unit name) and enforcing access at the data layer. This is the backend to use for a real deployment.

Memory

An in-memory backend used for development and tests — no external database to run. Data does not persist across restarts, so it is not for production use; it exists so an app can be built and exercised quickly against the same datastore interface.

Choosing a backend

Both backends implement the same datastore port, so an app is written once against the interface and runs on either. Develop against the memory backend for speed, then point the same app at Postgres for a real deployment — no app code changes.

Adding a backend

Because the datastore port is the only contract, additional backends can be added as adapters that satisfy it. Backends are organized as their own units; a new one is documented here once it ships.