Let an AI agent query your prodution database safely with read-only SQL

Railyard introduced an architecture that permits autonomous artificial intelligence models to inspect live application databases through the Model Context Protocol without risking accidental record modifications or schema damage. Founder and systems architect Almokhtar Bekkour outlined the guard rails on July 27, 2026, in railyard.run's report, demonstrating how engineering teams can inspect table sizes, diagnose failed migrations, and track signups in plain conversational language. The configuration leverages managed cloud database instances and protocol limitations to ensure model interactions remain observational across sensitive production workloads.

This guide details the five-layer safety model, connection setup steps, schema discovery patterns, query limits, and cloud pricing options. Engineering leads, database administrators, and backend developers maintaining infrastructure across external servers will find the exact operational boundaries needed to grant diagnostic access safely to automated agents.

01Five database guard rails and rollback transactions

Every query issued by an external model passes through five distinct isolation tiers before accessing stored rows. The architecture requires write-scoped permissions for data inspection tools, preventing read-only dashboard connections from exposing raw business records. Furthermore, administrative role checks restrict access so that viewer accounts, deployer profiles, and scoped app members cannot query database clusters outside their explicit application boundaries.

Engine-level transaction rules prevent write bypasses on the targeted host rather than relying on query text filtering. Postgres connections run queries inside a dedicated read-only transaction that always triggers an automatic rollback, while MySQL runs in read-only transactions and ClickHouse enforces native read-only mode. As a result, accidental modifications such as insert, update, delete, or schema alterations fail immediately at the database engine.

Hardware protection mechanisms defend primary database nodes from resource exhaustion and data leakage during complex analyses. A strict statement timeout terminates runaway operations before an accidental cross join can overwhelm database cores. External audit logs also deliberately omit raw query text, protecting personal identifiers like customer email addresses from spilling into shared activity records.

02Write access configuration and connector setup

Administrative teams initialize integration by binding their accounts through Claude connectors or direct command-line commands. Users authenticate inside the Claude interface by navigating to connectors, selecting Railyard, and approving full write consent. Alternatively, operators using Claude Code run the command claude mcp add with the http transport pointing to the official application endpoint before authenticating with write privileges.

Automated background pipelines can establish connectivity without requiring manual browser authorization or dashboard logins. Administrators generate dedicated write tokens with strict expiration dates inside the platform access settings and deliver them through standard bearer authentication headers. This token configuration provides autonomous agents with identical protective boundaries and role caps across scheduled workflows.

Connecting over the Model Context Protocol exposes list_tables and query_database tools directly into the agent conversational context. Because database credentials remain hosted on Railyard, external models execute queries without receiving raw connection strings or server secrets. Sensitive application variables accessible via get_env remain completely masked whenever teams seal confidential environment values inside project settings.

03Schema discovery and live query execution

Orientation begins when the agent calls the table listing tool to map existing database schemas and calculate relative storage burdens. Output displays target tables sorted from largest to smallest, highlighting row tallies and storage footprints like orders with 1.2 million rows consuming 840 megabytes or order items with 3.9 million rows at 610 megabytes. When field definitions are required, the agent issues standard queries against information schema columns.

Applications maintaining multiple storage engines can route operations across heterogeneous systems like Postgres and ClickHouse within the same session. Operators direct analytical questions toward specific engines simply by supplying the engine parameter or specifying the target system in plain English. The agent then crafts optimized structured queries to report signups over seven-day intervals or identify duplicate records across index migrations.

Performance investigations allow engineering teams to inspect query execution pathways without threatening live database stability. Developers run explain statements to evaluate customer indexing without executing heavy operations against production disks. If an agent executes explain analyze, the global statement timeout terminates queries that scan massive tables for too long, protecting production services against unexpected compute spikes.

04Query limits and destructive action boundaries

The query interface returns a maximum of 200 rows per execution to maintain disciplined querying habits and limit bandwidth overhead. Whenever a result set exceeds this ceiling, the engine marks the response with a truncated flag indicating that the returned rows represent a partial sample. Agents adjust to this boundary by shifting toward structured aggregations like count, sum, average, and percentile calculations.

Modifying existing records remains permanently impossible through the read-only query tool. When data corrections are necessary, engineers prompt the model to generate update scripts, which administrators review manually before executing them in the console or applying them through migrations. Prompt injection attacks embedded inside malicious database records cannot force writes because isolation is enforced at the database layer rather than through prompt parsing.

Backup management runs alongside data querying to safeguard infrastructure prior to high-risk production deployments. Agents can list historical backups and initiate immediate snapshots with additive write privileges without waiting for administrative confirmation. Conversely, restoring snapshots requires human verification inside the management console because overwriting active state carries severe production consequences.

05Infrastructure deployment and team plan pricing

Organizations deploy workloads directly into their own accounts across cloud providers including AWS, DigitalOcean, Hetzner, Vultr, OVHcloud, or custom Linux servers over SSH. Infrastructure fees are billed directly by underlying cloud providers without platform markups or resource premiums. The hosting system provisions managed Postgres, MySQL, and Redis setups alongside scheduled, restore-verified backups and point-in-time recovery tooling.

Software releases support push-to-deploy pipelines from GitHub, GitLab, or terminal interfaces, configuring automatic HTTPS certificates and zero-downtime cutovers. Engineers can deploy open-source developer tools, analytics packages, and database software onto private servers using one-click installation templates. This architecture ensures all runtime data remains localized on customer infrastructure rather than routed through third-party multi-tenant databases.

Pricing starts with a 14-day trial followed by flat monthly subscription tiers that support unlimited applications without bandwidth surcharges. The Launch tier costs $29 monthly for two servers and one seat, while Scale costs $69 for five servers and five seats. Larger organizations can select Team at $149 for ten servers and fifteen seats, or Agency at $249 for twenty servers and unlimited team members.