PROFULLSTACK / DB AGENTIC LAYER
Self-hosted · Agent-aware · PostgreSQL first

Your databases.
Useful to agents.
Still under control.

A small, auditable access layer between AI agents and the databases your applications already use. Keep normal SQL for your app. Give agents narrowly scoped, read-only tools with real limits and an audit trail.

Get started Service health Node SDK
Current reference: PostgreSQL 17 + Citus Agent interface: REST API + local MCP Deployment: your own Docker host

One agent layer, more than one database family.

Use the same project, identity, policy, and tool model as database connectors are added. The engine still owns SQL semantics and data behavior.

Available in reference stack
POSTGRESQL

PostgreSQL with upstream Citus

Single-node PostgreSQL 17 reference deployment, persistent volumes, a separate management database, and bounded read-only agent queries.

Connector planned
MYSQL PROTOCOL

TiDB for the MySQL path

Use TiDB as the MySQL-compatible distributed option. One MySQL protocol connector can serve TiDB and MySQL deployments through the same integration path.

Compatibility varies
WORKLOAD FIT

Choose the engine for the workload

TiDB implements much of the MySQL protocol and common syntax, but it is not identical to MySQL. Validate SQL, transactions, and features against the selected version. Read TiDB's compatibility notes.

Scope today: this live reference service is PostgreSQL-backed. MySQL and TiDB are connector targets for the same product and package name; they are not enabled by this instance yet.

A useful boundary between the agent and SQL.

Agents ask for named operations. Your service checks identity and policy, then queries with restricted database credentials.

Keep app access direct

Applications continue to use standard PostgreSQL clients and a separate application role.

Issue scoped agent identity

Operator-managed tokens are tied to a project, database, and allowed operations. Revocation takes effect at the service.

Enforce policy at runtime

Database roles, read-only transactions, schema grants, query deadlines, row and byte caps, and per-token concurrency bound the request.

Six tools. A narrow job.

The same authenticated operation model backs REST, CLI, and local MCP. Agent credentials cannot run operator backup or token-management actions.

POST/v1/list_databasesShow only databases visible to the caller
POST/v1/inspect_schemaRead approved columns and indexes without table rows
POST/v1/query_readonlyRun one bounded query with explicit truncation reporting
POST/v1/explain_queryInspect a plan without running it; ANALYZE is disabled
POST/v1/cluster_healthReturn caller-scoped service and database health
POST/v1/backup_statusShow backup and separate restore-verification status

Start with the local reference stack.

Deploy the service you can inspect. The npm client calls the authenticated API; it does not receive database credentials.

SELF-HOSTED

Run it on your machine

# Clone the repository, then initialize unique local credentials
./bin/agentdb init
./bin/agentdb config-validate
./bin/agentdb start
./bin/agentdb health

Docker Compose · loopback-bound API and database · synthetic sample events · named persistent volumes

NODE SDK

Call the same policy-controlled API

# npm release pending
npm install @profullstack/db-agentic-layer

// Keep the token in your secret manager or environment.
import { createClient } from
  '@profullstack/db-agentic-layer';

const db = createClient({
  baseUrl: process.env.AGENTDB_URL,
  token: process.env.AGENTDB_TOKEN,
});

const schema = await db.inspectSchema();

Preview package target: @profullstack/db-agentic-layer · Node 20.3+ · no SQL driver or database password in the agent process

Operations are part of the product.

Useful agent access depends on the database being understandable and recoverable.

OBSERVE

See what happened

Request IDs, identity, operation, duration, outcome, row counts, limit events, and safe query fingerprints. No result rows or raw SQL in audit records.

RECOVER

Prove a restore

Create an operator backup, restore into a new isolated database, then compare schema, known counts, and deterministic checksums.

GROW

Evaluate distribution

Citus workers and TiDB's distributed architecture are choices to evaluate with representative data and published measurements, not automatic speed switches.

Proof-of-concept limits: one PostgreSQL/Citus node, no high availability, no production recovery objective, and no distributed backup claim. Do not place production data on the reference stack.