Directus
Instant no-code app and dynamic API for any SQL database
4.9•18 reviews•932 followers
Instant no-code app and dynamic API for any SQL database
4.9•18 reviews•932 followers
The Modern Data Stack 🐰
Monospace is the governed API layer for every app, person, and agent.
Directus is an instant REST+GraphQL API and intuitive no-code data collaboration app for any SQL database.
This is the 5th launch from Directus. View more
Monospace from Directus
Launching today
Monospace sits between enterprise data and everyone who builds on it. Connect any data source, and your developers, business teams, and AI agents get live, read-write access to it. All under the same granular permissions model, with no data copied or moved. Your oldest databases weren't built with AI or modern apps in mind. Monospace generates interfaces directly from them, as they are, introspecting the schema and queries in real time, so they don’t need to be rebuilt.
Free Options
Launch Team / Built With
Does it provide safeguards before an agent makes changes to production data?
Directus
@ethanc44 Yes, absolutely - permissions can be enforced on the action (CRUD) and goes down to row and field granularity for stricter rules. This is more robust than a prompt telling an agent not to do something as it's enforced at the API layer, so there's nothing to leak or misuse.
Is there native support for caching GraphQL queries at the API layer to reduce database strain?
Directus
@andrew_dale2 Full transparency ahead - We currently don't offer a GraphQL API (yet), just an equally powerful REST API and MCP tools that can do full resolution of relations, deep filters and pagination.
But yes, Monospace has a built-in query-level cache backed by Redis that is consulted before we reach out to any downstream databases or other systems to reduce the strain. It is fully permission aware and does field level caching with configurable TTLs. So requests automatically get served by an up-to-date cache, if available and only then hit databases downstream.
Downstream data sources can be GraphQL servers, btw our custom connector extensions.
Any reason you're specifically looking for a GraphQL API specifically? Mostly versatility, query type safety and selective reads?
Feels like a pretty natural direction for Directus especially with more people building on top of existing data.
Directus
@haozhe_li Absolutely! The AI tooling space makes it easier than ever to take an idea to application, but it doesn't solve the problem of getting access to a companies valuable data. That's still stuck behind slow internal processes and often legacy databases nobody wants to touch.
Kilo Code
framing this!
Directus
I'm thrilled that Monospace is finally out for the world to use it!
I've been contributing to its frontend for the past months and it's been hard keeping it internally because it simply rocks!
It's free, it's full of powerful features (extensions and custom connectors, SSO support, Partial Introspection, UI views and builders, Native AI support, ...)
PLEASE let us know if you find anything that still needs fine-tuning, or if you find it awesome!
We've used Directus internally at Directus for years now and have it powering many of our internal teams and systems. It's been amazing to dogfood our own product for so many years and learn, iterate and adapt with both our users and ourselves in mind.
However, these separate systems are just that, separated. I am excited to see Monospace can bring these together as we continue to iterate on both products and see how they work together.
Congrats to the whole team. 👏
Kilo Code
#dogfooding
Directus
Hi all, I'm Hannes, engineer and engineering manager at Monospace.
We've been building Monospace for some time now, and I'm absolutely excited that today it's public. Ben covered why we built it and James covered what it does, so I'll stick to the engineering side.
Every new way of accessing data tends to bring another implementation of roughly the same logic. You build an API with permissions, then internal tooling, then an MCP server for agents, and now several places have to agree on who can do what.
In Monospace those interfaces share one model. You define permissions once, and REST, the generated TypeScript SDK and the built-in MCP server all evaluate them at query time.
The part I most want to see tested is cross-source relations and custom connectors. You can relate a Postgres table to a MySQL table and query both in one request. The data stays where it is; we don't copy it anywhere first. With custom connectors (in Preview!) you can build a small adapter and make Monospace talk to any of proprietary system!
I'd love to hear from anyone trying this against the kind of systems that don’t look good in demos: messy schemas, internal APIs that need custom connectors, and permission models that have accumulated years of exceptions.
I'll be in the comments all day if you hit something odd or want to know how any of it works.
Directus
@hanneskuettner What an immense effort to get here! And only just the beginning - a pleasure to work with you and the talented team on this.
Directus
@hanneskuettner We could have only done it with your dedication Hannes ❤️
Directus
Hey All, James here, VP Product at Monospace 👋
Ben covered why we built this, so I'll share a few decisions we made on purpose, since they're usually the first things people ask about:
We never copy your data. Every request goes live to the source, so reads are fresh and writes land in your system of record. No sync jobs, no stale replicas, all while maintaining traceability of what is hitting your data.
More than a gateway. Gateways see traffic. Monospace understands your data model, so every consumers row and and field-level rules are enforced before data is returned.
For example, an agent can change the shipping address on unshipped orders, but never the payment method. Revoke its key and nothing else is affected. The same rules apply to internal tools and apps.
Self-hosted, bring your own database. We don't host your instance or provision storage. The governance layer should sit inside your boundary, connecting to both on-prem and cloud systems as needed.
Curious to hear: which system would you connect first, and what would you build on it?