
The governed API layer for every app, person, and agent
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.
Monospace from Directus is an API layer that provides live, read-write access to enterprise data for developers, business teams, and AI agents, utilizing a granular permissions model without data duplication. It generates interfaces directly from existing databases, allowing for real-time schema introspection and query execution without the need for rebuilding.
A source that found nothing is a measurement. A source that has not run is a gap. Neither means the launch lacks the thing.
Overall excitement for Monospace's launch, highlighting its integration capabilities and performance.
Ben here, CEO of Directus 👋 Years ago, we built Directus because every project started the same way: a database full of data and weeks of work before anyone could safely build on it. That problem hasn’t stood still. The data is spread across more systems and the amount of people who need it keeps growing. Developers shipping apps, business teams who want to build their own tools, and AI agents. Every project adds another integration and another set of permissions to maintain. Monospace is our answer. A governed API layer between your data and everyone who builds on it. Connect any database, API or SaaS system you run, and people, apps and agents get live read-write access under one permissions model. Each caller gets its own key. Row and field-level rules decide what it can see on every request. No data copied or moved, and you self-host it. We would love to hear your feedback and questions. Really appreciate you taking the time to take a look at our launch!
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 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.
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?
After putting Monospace through the ringer over the last 6 weeks - it's impossible to not get excited when building with this tool. There are hard problems and then there are hard problems... And live data federation across databases, APIs, and services that: is self hostable is super performant and memory efficient (thanks Rust! 🦀) doesn't require ETL or data warehouses can allow flexible yet granular access policies for every type of caller scales easily for production workloads and most important - makes life simpler for developers like myself.... is indeed a very hard problem to solve. And as the head cheerleader over here at Directus, I just wanted to pop in and congrats to our freaking awesome team for bringing this idea into reality. There's far too many names to name so I'll just call out the engineering ring leader - @hanneskuettner - massive congrats to the team my friend. 🍻