Data Mesh with Enforceable Federated Governance

Data as a product

The data mesh model shifts ownership from a central platform team to the domains that produce the data. Each domain publishes a data product with clear contracts and self-serve access, instead of pushing raw data into a central lake that a separate team has to understand and maintain. That requires storage primitives that map cleanly to independently owned units — which is exactly what Montycat keyspaces are.

The principles of a data mesh

A data mesh rests on four principles. Montycat gives each one a concrete home:

• Domain ownership — each team owns its data end to end (a keyspace per domain).
• Data as a product — data is discoverable, addressable, and trustworthy, with a schema contract.
• Self-serve platform — domains provision and evolve their own keyspaces inside a delegated scope, without a central bottleneck.
• Federated governance — shared standards applied per domain, enforced by the engine rather than by convention.

Federated governance made concrete

On most platforms, "federated governance" means a wiki page and a review process. In Montycat it is a policy the database evaluates on every administrative operation. A superowner — the platform team — remains the root authority: it creates owners, defines governance boundaries, and is the only principal that can change policy. Domain owners receive explicit, scoped administrative capabilities over their own data products.

Governance is deliberately separate from data access. The existing read, write, and store-wide all permissions still decide who can read and write records; governance capabilities decide who can administer a data product. Holding one never implies the other, so granting a domain the authority to run its keyspaces does not hand it the contents of anyone else’s.

Decentralization here is organizational, not necessarily physical. Domains can share one engine and store while owning separate keyspaces, or run separate deployments — the ownership model is the same either way, because it lives in policy rather than in the deployment topology.

Platform team versus domain team

The split of responsibility is explicit rather than cultural:

Capabilities as domain contracts

Authority is delegated as named capabilities, each bound to an owner and a store, and optionally narrowed to a single keyspace:

• provision-keyspace — create new data products in a store.
• remove-keyspace — retire data products within the delegated scope.
• manage-snapshots — control snapshotting for in-memory data products.
• manage-semantic — enable, disable, or configure semantic (vector) search.
• manage-schema — create, change, preview, or remove the product’s schema contract.
• manage-access — reserved for delegating data-access permissions; defined in the policy model, not yet enforced at runtime.

Guardrails without central bottlenecks

A grant is a scope plus optional constraints, so the platform team can be permissive about routine work and strict about the parts that carry cost or risk. Provisioning is store-scoped, because the keyspace being created does not exist yet; every other capability can be pinned to a single keyspace. Optional storage-type constraints keep a domain on in-memory or persistent keyspaces; optional semantic-model constraints limit which embedding models it may enable. Snapshot management carries no storage-type constraint at all — snapshots only ever apply to in-memory keyspaces.

Ownership then does most of the day-to-day work. A domain that creates a keyspace automatically gets read and write access to it, snapshot control when it is in-memory, semantic management within the models policy allows, and the right to remove it. Explicit denials are the counterweight: a denial suspends an automatic or granted capability for one specific resource, so a broad, convenient grant can coexist with a protected data product that stays off-limits.

Auditable, repeatable governance

Delegation is only safe if you can see what it produced. Grants and revocations can be previewed before they touch active policy. Any authorization decision can be explained — allowed or denied, with the reason and the policy responsible. Effective policy can be reviewed per owner and per store, and every change is appended to a policy history you can filter by owner, store, and keyspace.

For teams that manage access as infrastructure as code, policy is also a strict, versioned JSON or YAML manifest: validate the document, plan the changes it would make, review the plan, then apply it — and export the active policy back out for review or version control.

Implementing a data mesh on Montycat

Treat stores as the shared platform boundary and keyspaces as domain-owned data products. Give each domain the narrowest capability set that lets it move on its own: persistent or in-memory storage, an optional runtime schema that encodes the product’s contract, and real-time subscriptions so consumers react without polling. Because every keyspace is independent and every grant is scoped, domains evolve and scale on their own timelines — no central chokepoint, no cross-team migration to ship a change.

Multi-tenant delegation on shared infrastructure

The same mechanics apply when the "domains" are tenants. A keyspace is a namespace boundary, and access to it is decided by credentials, so one tenant’s data is not reachable through another tenant’s credentials. Governance adds the administrative half: a tenant owner can be given authority to run its own keyspaces — provision, snapshot, evolve the schema — while storage-type and model constraints keep its footprint inside what the platform is willing to pay for, and explicit denials keep shared or sensitive resources out of reach.

Beyond a data mesh: AI-ready data products

Because Montycat also ships built-in semantic (vector) search, a data product is not limited to exact-match queries — consumers can retrieve by meaning. That makes domain data directly usable for RAG pipelines and AI-agent workloads, turning each data product into a knowledge source without exporting it to a separate vector store. Which models a domain may enable is itself governed, so AI capability spreads without the embedding footprint getting away from you.

When a data mesh fits

A mesh is not for every team. It pays off when:

• Multiple domains produce and consume data and a central team has become the bottleneck.
• You want clear ownership and contracts instead of a tangled shared schema.
• Domains need to evolve and scale independently — without being handed the whole database.
• You have to prove who can do what, and why, during an access review or audit.
• You want data products that are directly queryable — by key and by meaning.

Delegated governance, end to end (Python)

# 1. Platform team delegates one capability, narrowly scoped.
await engine.policy_grant(
    owner="sales",
    capability=PolicyCapability.PROVISION_KEYSPACE,
    store="analytics",                     # store-scoped: the keyspace does not exist yet
    types=[PolicyKeyspaceType.IN_MEMORY],  # guardrail: in-memory data products only
)

# 2. An explicit denial keeps a protected data product off-limits.
await engine.policy_deny(
    owner="sales",
    capability=PolicyCapability.REMOVE_KEYSPACE,
    store="analytics",
    keyspace="Revenue",
)

# 3. The domain owner works inside its scope — no ticket required.
class Orders(Keyspace.InMemory):
    keyspace = "Orders"

Orders.connect_engine(sales_engine)
await Orders.create_keyspace()   # allowed; a persistent keyspace would be refused

# 4. Any decision can be explained — allow or deny, with the reason.
await engine.policy_explain(
    capability=PolicyCapability.REMOVE_KEYSPACE,
    store="analytics",
    owner="sales",
    keyspace="Revenue",
)

Full governance reference — Python, Node, Dart, Rust · Same reference as Markdown

FAQ

Explore

• Montycat — the NoSQL database for Data Mesh
• Governance documentation — capabilities, scopes, and policy APIs
• Long-term AI memory for agents
• Semantic search, built into your database
• Python client on PyPI
• Documentation