Turn PostgreSQL Into a REST API — and an MCP Server for Your AI Agent
Connect your PostgreSQL database, pick the tables you want to expose, and publish a documented REST API. Every endpoint you publish also becomes a tool your AI assistant can call.
Free plan includes a hosted MCP server — no card required.
PostgreSQL is where a lot of teams keep the data everyone else wants access to — orders, customers, subscriptions, usage. The moment a second system needs that data, someone ends up writing an API in front of it: routing, pagination, filtering, auth, docs, keys. It is a week of work that has been written a thousand times before, and it has to be maintained forever afterwards.
Dataloom removes that step. You connect your database with the same host, port, database name, user and password you would use from any other client, choose which tables or views to expose, and publish. Dataloom reads your schema, generates the endpoints, writes the OpenAPI description and serves interactive documentation — without you writing a line of server code.
Your database stays exactly where it is. Dataloom connects over the network with the credentials you provide, so there is nothing to migrate, no replica to keep in sync, and no copy of your data sitting somewhere else. Read-only credentials work perfectly well if you only want to expose reads.
Connecting your PostgreSQL database
Add a data source with your host, port (5432 by default), database name, username and password, and enable SSL if your provider requires it — managed Postgres services such as Supabase, Neon, Amazon RDS and Azure Database for PostgreSQL generally do. Dataloom tests the connection before saving, so you find out immediately if a firewall rule or credential is wrong rather than after you have built endpoints on top of it.
Once connected, Dataloom reads your schema — tables, views, columns, types, primary keys and foreign keys — and shows you what is available. You choose what to expose. Anything you do not select is simply not reachable through the API, which makes it straightforward to publish one reporting view without opening up the rest of the database.
If the account you connect with is read-only, you get read endpoints. If it can write, you can additionally publish POST, PATCH and DELETE endpoints. The permissions of the database user are the real boundary, and Dataloom never widens them.
What you get with PostgreSQL
- Tables and views both become endpoints
- Schema-qualified names are supported (public.orders, reporting.mrr)
- SSL/TLS connections for managed Postgres providers
- Filtering, sorting and pagination on every list endpoint
- Custom SQL endpoints with named :parameter binding (Starter and above)
- Read-only credentials produce read-only APIs
An example endpoint
List recent orders over R10,000, newest first.
GET /acme-data/orders
?filter={"Status":"shipped","Total":{"gte":10000}}
&sort=CreatedAt&order=desc
&page=1&pageSize=25
X-API-Key: your_api_key{
"data": [
{ "id": 8814, "CustomerId": 42, "Total": 18400.00,
"Status": "shipped", "CreatedAt": "2026-08-14T09:12:00Z" },
{ "id": 8790, "CustomerId": 17, "Total": 12750.50,
"Status": "shipped", "CreatedAt": "2026-08-13T16:44:00Z" }
],
"meta": { "page": 1, "pageSize": 25, "totalCount": 63,
"totalPages": 3, "hasNextPage": true }
}Filtering, sorting and pagination work the same way on every endpoint, whatever the source. See the no-code API builder for how endpoints are put together.
Connect Claude to PostgreSQL
Every endpoint you publish is automatically available as a tool on your workspace’s hosted MCP server. There is no second thing to build and no separate schema to maintain — publish an endpoint and roughly a minute later your assistant can see it, with typed parameters derived from your actual Postgres columns.
That means you can ask Claude questions about your production data in plain language — "which customers in Gauteng spent over R10,000 in the last year?" — and it will call the right endpoint with the right filter rather than guessing. Because the tool schema lists the real column names, the assistant is not inventing fields that do not exist.
The important part is what the assistant cannot do. It only ever sees endpoints you have published, it authenticates through OAuth 2.1 rather than a pasted key, and it inherits whatever limits the underlying database user has. If you exposed three read endpoints, three read endpoints is the entire surface area.
// mcp-config.json
{
"mcpServers": {
"dataloom": {
"url": "https://mcp.dataloom.cloud/w/your-workspace",
"transport": "http"
}
}
}Read more about the hosted MCP server, or follow the step-by-step setup guide.
PostgreSQL questions, answered
Does Dataloom copy my PostgreSQL data?
No. Dataloom connects to your database over the network using the credentials you supply and queries it directly when a request comes in. There is no replica and no stored copy of your rows.
Can I use a read-only Postgres user?
Yes, and it is a good idea if you only need read endpoints. Dataloom can only do what the database user is permitted to do, so a read-only role produces a read-only API.
Do views work, or only tables?
Both. Views are often the better choice, because you can shape exactly the columns and joins you want to expose in SQL and then publish that view as a single clean endpoint.
Does it work with Supabase, Neon or Amazon RDS?
Yes. Any PostgreSQL instance Dataloom can reach over the network works, including managed providers. Enable SSL and make sure the provider firewall allows the connection.