Monospace Guarantees Atomic Writes Inside One Database. Your Agents Will Use Two.
Key Takeaway
Monospace from Directus puts one governed API in front of PostgreSQL, MySQL, and other sources, then serves it to agents through MCP. The planner collapses redundant queries inside a request. Permissions resolve per request at the collection, item, and field level. The risk lives in the seams. Cross-source joins run in memory, cross-source references carry no foreign key enforcement, and atomicity stops at the edge of a single data source. Treat every multi-database agent write as a saga, not a transaction.
What is Monospace from Directus, and how do AI agents connect to it?
Monospace is a separate product from the team behind
Directus. You register a data source. It introspects the schema into collections, fields, and relations.
Then it serves that model four ways: a REST API, a typed TypeScript SDK, an MCP server, and a Studio.
Data stays where it lives. The docs describe federation at query time, with no replication and no ETL.
Agents connect through a per-workspace
MCP endpoint with an API key. The agent acts with exactly that key's permissions.
Its tools read the schema, query items, create, update, and delete items, and list data sources. With the right entitlement, they also change the schema. Keep that last tool off agent roles.
Does Monospace from Directus cause N+1 queries across multiple databases?
The N+1 problem is simple. One query fetches a list. Then N more queries fetch each row's related data.
Inside one request, the documented planner works against it. The query engine builds a pessimistic plan first, then runs optimization passes.
It collapses an UPDATE plus SELECT into one statement where the database supports RETURNING. It merges identical SELECT statements with no writes between them. Independent source queries run concurrently.
The planner works on one request at a time. That is where N+1 returns.
An agent that loops over 200 order IDs and calls the MCP query tool 200 times builds its own N+1, one layer above the optimizer. Each call pays for authentication, permission checks, and a connector round trip. No optimizer merges calls it never sees together.
Why are cross-database JOINs slower than single-database JOINs?
The docs state that operations spanning multiple data sources run in memory. A join between PostgreSQL orders and MySQL invoices cannot be pushed into either database. Rows travel to the engine first. Then the join runs.
Cost tracks rows fetched, not rows returned. A lookup keyed on the first result depends on it, so it cannot run concurrently.
When engineering teams deploy this in staging, the number to watch is source queries per agent task. Read it from the database query logs, not from the API response.
Table 1. Enriching 200 orders with invoices from a second database (illustrative arithmetic, assuming 4 ms per source query)
| Pattern |
Agent calls |
Source queries |
Serial latency |
| One MCP call per order | 200 | 400 | 1,600 ms |
| One request, per-row lookup | 1 | 201 | 804 ms |
| One request, batched lookup | 1 | 2 | 8 ms |
These figures are arithmetic, not a benchmark. The docs reviewed here do not say how a cross-source relation batches lookups, so verify it in your own logs.
Fix the pattern at the request. Filter both sides before the join. Select only the fields you need. Apply filter, sort, limit, and offset inside each included relation. Keep tightly joined collections on one source.
Can an AI agent bypass row-level and column-level permissions in Monospace?
Not by design. The failure modes sit in configuration, and parallel agent writes compound them.
Monospace enforces item filters and field lists itself, at request time. None of that reads your database's native row-level security. The introspection docs list RLS policies, triggers, and check constraints among the objects Monospace does not discover.
So two rule sets exist, and neither knows about the other. On PostgreSQL, whether native RLS also constrains Monospace depends on the database role in the connector credentials. Test it with a low-privilege agent key.
Why does a wildcard field grant fail after a schema change?
Wildcard field access covers fields added in the future. Monospace picks up schema changes made outside it when someone re-introspects the data source.
Picture a DBA adding a risk-score column to a client table. After re-introspection, every agent key with a wildcard read grant can read it. Nobody edited a policy. Use specific-field allow-lists, and put re-introspection behind review.
What happens when two policies conflict?
They never conflict. They add up. A permission granted by any policy is granted. A restrictive policy cannot cancel another policy's grant. Validation rules are the exception, because a write must satisfy the rules of every attached policy.
Any policy with admin access gives full access. Stacked roles widen an agent key silently over time. Give each agent one role and one policy, then review the union.
Can simultaneous writes slip past an item filter?
Agents write fast and in parallel. Filters on mutable columns, such as status, open timing gaps. A row can leave the permitted set between an agent's read and its write.
The docs reviewed here do not describe locking semantics, so test two concurrent clients against the same rows. Filter on immutable keys, such as tenant or owner ID.
Delete adds a harder limit. Field permissions cover create, read, and update, but not delete. A permitted delete removes the whole item. The docs also call bulk deletes irreversible.
Table 2. Permission failure modes for agent roles
| Failure mode |
Blast radius |
Control |
| Wildcard field grant | New columns readable after re-introspection | Allow-list fields |
| Stacked policies | Union of grants, no deny rule | One role per agent |
| Mutable filter column | Row leaves allowed set mid-run | Filter on immutable keys |
| Delete permission | Whole-row loss, no field control | Use status updates instead |
| Custom rules not licensed | Filters, field lists, validation rules rejected with a 402 | Confirm entitlement first |
Confirm your plan includes custom permission rules before promising row or column isolation to a compliance team.
What happens when an AI agent updates two databases and one write fails?
The scenario below is modeled from documented behavior. It is not a reported incident.
Orders live in PostgreSQL. Invoices live in MySQL. One workspace holds both sources and a cross-source relation. A support agent holds update access on every collection involved. Its task: cancel unpaid orders older than 90 days, then void their invoices.
How does the failure unfold?
- The agent updates an order and its line items in one nested request. Both tables sit in PostgreSQL, so the docs promise all-or-nothing behavior. A bad key rolls everything back.
- The agent repeats this for 1,204 orders. Each commits.
- The agent then updates the related invoices in MySQL. Under parallel load, a lock wait times out or the connection pool runs dry. MySQL rolls back its own statement. Zero invoices are voided.
- Nothing reaches PostgreSQL. The docs state there are no transactional guarantees across data source boundaries, even inside a single request.
- The agent retries. Its filter, unpaid and older than 90 days, now matches nothing. The first write destroyed the work set.
Isolation fails too. Each source stays consistent by itself. The pair does not. Any reader sees cancelled orders beside open invoices.
Repair makes it worse. A DBA fixes rows directly in the databases. Monospace cannot detect writes made outside it, so cached reads stay stale until the time-to-live expires. The documented default is five minutes. The agent reads stale data and may conclude the repair failed.
An improvising agent may then delete the "orphaned" invoices. Orders that reference them show a null or a shorter list, with no error, because cross-source references carry no foreign key enforcement.
Forensics is thin. The documented audit log covers accounts, authentication, roles, policies, and schema migrations, not item-level writes. Reading it requires a license that includes it. Recovery means the source databases' own logs and backups.
How can teams contain the blast radius?
- Persist the work set before the first write: a batch table of order IDs with a status column.
- Run the step most likely to fail first and the hardest to undo last.
- Prefer status changes to deletes. Remove delete from agent roles.
- Make every step idempotent, keyed on the stored work set.
- Send Cache-Control: no-store on verification reads. The docs say a bypassed request reads live data.
- Weigh workspace-per-agent isolation carefully. The docs warn that a mutation in one workspace does not currently invalidate cached results in another.
Frequently Asked Questions
Q. Does Monospace from Directus support cross-database transactions?
No. The docs guarantee atomicity only within a single data source. Writes across databases carry no transactional guarantees, so design them as sagas with compensating steps.
Q. Can Monospace restrict an AI agent to specific columns?
Yes. Field permissions cover create, read, and update, and you can allow-list specific fields. Avoid wildcard grants, and confirm your license permits custom permission rules.
Q. Does Monospace copy my data into its own store?
Not as a replica. The docs say data stays in the source system and no ETL runs. Query results for reads are cached by default in Redis-compatible storage, so include that cache in your security review.
Q. Which databases does Monospace connect to?
The connector reference lists PostgreSQL, Supabase, MySQL, and MariaDB. Internal APIs and SaaS applications need custom connectors.
⚖️Legal Disclaimer
This article is provided for general informational and educational purposes only. It is not legal, financial, security, compliance, or investment advice, and it creates no professional relationship between you and The Dollar Craft. Product behavior described here reflects the vendor's public documentation, which changes without notice. Query counts, latency figures, and failure scenarios are modeled illustrations, not benchmarks or reports of real incidents.
Verify every claim against current vendor documentation and test in your own environment before deploying agents against client or regulated data. Consult qualified counsel and security professionals for your circumstances. The Dollar Craft disclaims liability for losses arising from reliance on this content. Product names are trademarks of their respective owners.
Comments
Post a Comment