store

store

A named data store within the stores section. Each store block declares a connection to a data backend and contains one or more resource definitions. The source type determines which backend is used: Mashin can create and manage tables automatically, or you can connect to an existing database.

When to use

Use store when you need:

• Persistent structured data that survives across machine executions
• A domain data model with typed fields, relationships, and constraints
• Database-backed CRUD operations governed by policies
• Connection to an existing external database (PostgreSQL, SQLite)

If you only need temporary data within a single execution, use state in the implements section instead. If you need semantic search over unstructured text, combine a store with a vectors block on a resource.

Syntax

stores
  store <name>
    source: <source_type>
      url: env("<ENV_VAR>")
      schema: "<schema_name>"

    resource <name>
      ...

Importing a store from another machine

stores
  store <name>, from: "<namespace/machine>"

Parameters

Parameter	Required	Description
name	Yes	Bare identifier naming this store. Used to reference the store elsewhere in the machine.
source	Yes	Backend type. One of: managed, none, postgres, sqlite, qdrant.
url	No	Connection URL for external databases. Typically wrapped in env("...") to read from environment variables.
schema	No	Database schema name for PostgreSQL (e.g., "public").
from	No	Import a store defined in another machine or krate. Mutually exclusive with source.

Source types

Source	Description	Use case
managed	Mashin creates tables automatically. Uses SQLite on desktop, PostgreSQL in the cloud.	New projects where Mashin owns the database.
sqlite	Explicit SQLite connection.	Local-first applications, embedded databases.
postgres	Explicit PostgreSQL connection. Requires url.	Cloud deployments, shared databases.
qdrant	Vector-only store backed by Qdrant.	Pure semantic search without SQL storage.
none	No database backend. Types only, no persistence.	Validation schemas, shared type definitions.

Examples

Managed store with a single resource

machine task_tracker

stores
  store tasks
    source: managed

    resource task
      id as uuid, is primary_key
      title as text, is required
      status as text, default: "open"
      timestamps

      defaults: [read, destroy]

      create add_task
        accept: [title]

      update set_status
        accept: [status]

External PostgreSQL connection

machine analytics

stores
  store warehouse
    source: postgres
      url: env("WAREHOUSE_DATABASE_URL")
      schema: "reporting"

    resource metric, table: "daily_metrics"
      id as uuid, is primary_key, column: "metric_id"
      name as text, is required
      value as decimal
      recorded_at as datetime, column: "created"

      read recent
        argument days as number, default: 30
        filter: recorded_at >= today() - arg(days)
        sort: recorded_at, desc

Importing a store from another machine

machine dashboard

stores
  store orders, from: "@myorg/ecommerce"

Governance

Store declarations themselves do not require governance approval. However, the actions defined on resources within a store (create, read, update, destroy) are governed effects. Each action:

• Passes through the governance interpreter as a db capability
• Is subject to the machine’s permission declarations in ensures
• Is recorded in the behavioral ledger as a data operation

Stores declared with source: none have no runtime effects and need no governance.

How it works at runtime

The .mashin file is the only source of truth. Users never see generated Elixir code. At runtime:

1. The parser produces an AST with a SchemaSpec for each store
2. Mashin generates Ash Framework resources in memory via Code.compile_string()
3. The migration engine diffs the current schema against the previous version
4. Additive changes (new tables, new columns) apply automatically
5. Destructive changes (dropped columns, type changes) queue for approval in cloud deployments
6. The store is ready for the machine to use

On desktop (SQLite), migrations apply automatically with no approval step. In the cloud (PostgreSQL), destructive migrations require operator approval.

Translations

Language	Keyword
English	store
Spanish	almacen
French	stockage
German	Speicher
Japanese	ストア
Chinese	仓库
Korean	저장소

See also

• stores - The top-level section containing store blocks
• resource - Resource declarations within a store
• field types - Field type reference for store resources
• vectors - Vector search capability on resources