Skip to main content

Give humans and agents safe access to the right data.

Marmot is a data catalog, query gateway and MCP server in one. Your team and your agents read the same definitions and owners, and every query they run is checked and recorded.

Start for freeDeploy it yourself
orders
shop.orders.v2
customersRefused
stg_orders
orders_daily7 rows
customers_dim
Revenue overview
Customer health
finance-agentover MCP · sample data

What was revenue last week, and can I trust the number?

  1. Searched the catalogorders_daily in Snowflake, owned by Analytics Engineering
  2. Read its lineageBuilt by dbt from shop.public.orders
  3. Checked its accesssvc-finance may read orders_daily
  4. Ran a query on orders_daily7 rows in 412 ms, on record
  5. Asked for customer emailsRefused: no grant on customers.email

Revenue last week was £413,180 across 8,615 orders, from orders_daily, the table finance reports from.

“Marmot brings metadata, ownership and lineage into one searchable catalog, making data products easier to discover and understand.”

Manuel Jáñez GarcíaSenior Specialist of Data Governance Services, Telefónica

Reads metadata from the tools you already run, with 70+ plugins

  • PostgreSQL
  • BigQuery
  • Kafka
  • dbt
  • Airflow
  • S3
  • ClickHouse
  • Trino
  • MongoDB
  • and dozens more
Browse plugins

Built in the open by engineers from

HashiCorp, Adidas, Just Eat Takeaway.com and Traefik

More than 600 stars on GitHub

Why a database password isn’t enough

Both maps show a finance agent looking for last week’s revenue in the same six tables.

  • Without MarmotWith only a read-only password, it guesses its way through four look-alike tables and reads customer emails on the way.
  • With MarmotThe catalog points it to orders_daily, the table finance reports from, and its query for customer emails is refused.
finance-agentRead-only database password
orders
orders_v2
orders_final
revenue_tmp
orders_daily
customers
finance-agentOver MCP
orders
orders_v2
orders_final
revenue_tmp
orders_daily
customers
Personal data · needs a grant

Two maps of the same tables. Without Marmot, the agent guesses between look-alike order tables with a database password, and ends up reading customer emails. With Marmot, it takes one logged route to the orders_daily table finance reports from, and its query on the customer table is refused.

Start for freeDeploy it yourself

Find the right table without asking in Slack

Search every connected source in plain words, from the browser, the CLI or an agent over MCP.

  • Tables, topics, dashboards and models in one list
  • Filter by type, owner, tag or any metadata
  • Kept current by 70+ plugins
See the plugins

Discover lists tables, topics, dashboards and models together, is narrowed to finance tables with the Type and Tags filters, and previews ORDERS_DAILY from Snowflake, showing when it last synced. Sample data.

Know what a column means before anyone trusts it

Owners, descriptions and glossary terms sit with every asset, so humans and agents answer from the same facts.

  • Owners and teams on every asset
  • Glossary terms that explain each field
  • Certified fields marked as the ones to use
How the glossary works

The page for orders_daily shows Analytics Engineering and Jane Doe as its owners. In the schema, net_revenue_gbp opens with the glossary term Net revenue, and is then marked as certified. Sample data.

Let humans and agents query your data without sharing passwords

Humans and agents run queries through Marmot under the same rules. Each query is checked against the caller’s permissions before it reaches the database, and logged with who ran it and whether it was allowed. Access rules per table, data product and glossary term come with Marmot Cloud.

  • Read-only queries against the sources you connect
  • Refused before it reaches the database
  • Who ran what, when and whether it was allowed
How access control works

A query on orders_daily runs and returns 7 rows. The next query reads customers_dim, a table the caller has no access to, and is refused. Both land in the query audit. Sample data.

See what breaks before you change it

Lineage follows data from source tables through every model to the dashboards that use it.

  • Upstream and downstream, across tools
  • From plugins and OpenLineage runs
  • The dashboards a change would break
How lineage is collected

The full-screen lineage of orders_daily follows orders from the PostgreSQL table through the Airflow load and the dbt models to the Revenue overview dashboard. An edge declared by the dbt-analytics pipeline and a Spark job reported through OpenLineage open in the blade, then the two dashboards downstream of orders_daily and who to ask about them. Sample data.

Questions

Anything else, email support@marmotdata.io.

A read-only user can read every table it has been granted, personal data included, and nothing ties its queries back to the question the agent was asked. It also tells the agent nothing about which orders table finance reports from. Through Marmot the agent picks from the catalog, each query is checked against what that agent may read, and every query is logged with who ran it and whether it was allowed.

A catalog tells people what exists. Marmot also serves that context to agents over MCP and runs their queries, so the system that knows a table holds personal data is the same one that decides who may query it. That is why we think of Marmot as a context layer for humans and agents, with the catalog as one part of it.

Only what you grant them. People sign in as themselves and agents connect with their own service accounts, and Marmot checks every query against that identity’s roles before it reaches your database. Anything they may not read is refused, and every attempt is recorded.

No. Plugins read metadata from the systems you already run, and queries go to those systems in place. Your data stays where it is.

It is the same project. Cloud instances run the version we maintain for customers: fixes land there first, and many flow back into the MIT-licensed releases on GitHub. Nothing locks you in, and you can export your catalog and self-host the open source edition at any time.

Only metadata: schemas, ownership, descriptions, lineage and run status. Plugins never send rows, messages or payloads to your instance.

No. Register where the secret lives in Google Secret Manager, AWS Secrets Manager, Azure Key Vault or HashiCorp Vault, and your instance reads it when a run starts, over a five-minute OpenID Connect token your cloud trusts. The run record keeps a mask.

You choose the region when you launch, and your catalog stays there. Every instance runs its own Marmot with its own database, so catalogs are never shared between customers.

You upgrade Marmot when it suits you, and fixes reach Cloud before the open source releases. Everything underneath is patched continuously, with nothing for you to do.

The people who build Marmot. The team includes engineers from HashiCorp, Adidas, Just Eat Takeaway.com and Traefik, who help maintain Kubernetes, Terraform, Redpanda and Cloud Native Computing Foundation projects.

Give your team and your agents one safe way in to your data

Run it yourself or let us run it. It’s the same catalog and the same MCP server either way, so you can move between them.

Marmot Cloud

We run it for you and add access control on top.

  • Access control per table, product and term
  • Governed queries, with an audit log of every one
  • Upgrades, nightly backups and support from the team

Free to start with no card, and unlimited users on every plan.

Start for freeSee pricing

Open source

MIT-licensed and free, on your own infrastructure.

  • The catalog, lineage, glossary and MCP server
  • One binary, or on Kubernetes with the Helm chart
  • Help from the community on Discord and GitHub
Deploy it yourselfView on GitHub