Connect an Industrial SQL Database to OpenAI
You're building an OpenAI Assistants agent or a Custom GPT that should answer questions about production — and the data lives in a SQL database on a plant or corporate network: batch records, quality results, downtime logs, production counts. SQL databases are everywhere in manufacturing, but the SQL Server or SQL Express instance that holds your operational data is rarely accessible from OpenAI's cloud. Getting an OpenAI agent to surface live production data from a SQL source requires solving problems that go beyond writing a function definition.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting an OpenAI agent to an industrial SQL database is harder than expected.
Function calls need an HTTPS endpoint — SQL Server doesn't expose one
OpenAI Assistants and Custom GPT Actions retrieve data by calling HTTP endpoints defined in function schemas or OpenAPI specs. A SQL Server instance exposes a TDS protocol port — not an HTTP interface. Getting data from SQL Server into an OpenAI function call requires a REST API layer that queries the database and exposes results over HTTPS. That layer has to be built, deployed, and maintained separately.
SQL databases sit on restricted plant or corporate networks — OpenAI calls from its own cloud
Production SQL databases sit behind firewalls on plant or corporate LANs. OpenAI's function calling infrastructure makes HTTP requests from OpenAI's servers — it has no direct path to SQL Server on a restricted network. Getting there requires either a relay service that bridges the OT/IT network to the internet, or a network path change — both of which involve IT and often a security review.
Shared or service credentials — risky to expose in a function schema or API config
Industrial SQL databases often use shared credentials or a single service account. Wiring these credentials into a function endpoint means they're stored in API configuration and used for every agent request. If the API is misconfigured or credentials rotate without updating the function definition, the agent breaks or the credentials are exposed. Least-privilege and per-user access are rarely configured in OT-adjacent databases.
The model doesn't know which tables or columns are relevant
Industrial SQL databases evolved organically — table names like tblBatchHdr, T_QualEvents, or PROD_LOG_01 are meaningful only to the team that built them. Without a curated semantic layer — descriptions of what each table means, which columns matter for operational questions, what joins are required — the model can't generate meaningful queries even if it has database access. Freeform SQL generation from an undocumented schema produces unreliable results.
Raw query results fill the context window and drive up token costs
A raw SELECT against a production database can return thousands of rows. Sending that result back to the model fills the context window rapidly and drives up token costs. The model has to process an enormous flat result set to extract the answer to what may be a simple question. Aggregation and result shaping have to happen server-side before the function responds.
Agent queries can add unexpected load to production databases
Industrial SQL databases often run on shared infrastructure — the server writing production data is also being queried. Poorly optimised agent-triggered queries, repeated calls from multiple users, or inefficient aggregation over large tables can add unexpected load. DBA teams reasonably push back on any new query source they don't control or that can issue arbitrary SQL against production tables.
Custom GPT Actions require a public OpenAPI spec — hard to maintain against evolving schemas
Custom GPTs retrieve data using Actions defined by an OpenAPI spec hosted at a public URL. Industrial SQL schemas change over time — tables get renamed, columns get added, joins change. Keeping the OpenAPI spec and function descriptions aligned with the underlying schema as it evolves adds ongoing maintenance overhead. A spec that drifts from reality produces unreliable agent behaviour.
What teams usually try
REST API wrapper on the same network as the database
Build a service that queries SQL Server and exposes an HTTPS API. Deploy it on a machine with network access to the database and an internet-facing path for OpenAI to call.
The catch: The service needs an internet-accessible path from inside the plant network — a firewall change that IT has to approve. Credentials still have to be managed. Without a semantic layer, query results still lack business context. The service adds ongoing infrastructure overhead.
Replicate to a cloud database
Set up replication or ETL from the on-premise SQL database to Azure SQL or another cloud database. Point the function schema at the cloud target. OpenAI can reach it directly without a plant network path.
The catch: The agent answers questions about a replicated snapshot — not live production data. Replication adds infrastructure complexity and latency. Schema mapping between source and cloud target requires design and maintenance. Token costs still scale with unshapeded query results.
Upload SQL exports as Assistants files
Export SQL query results to CSV files and upload them as Assistants file attachments. The model reads file content to answer production questions.
The catch: The agent answers questions about the last export. Large files from production databases chunk poorly for operational time-range queries. Manual export steps add operational burden. There is no live data access.
How TrendOps solves it
TrendOps Edge connects to SQL databases on the plant or corporate network — querying production tables, applying context mapping, and aggregating results — then forwards structured data to TrendOps Platform in the cloud over a single outbound connection. Your OpenAI agent calls TrendOps Web API as a function endpoint or Custom GPT Action. No direct SQL Server access from OpenAI's cloud, no credential exposure, no raw query results filling the context window.
The function schema points to TrendOps Web API — a cloud-accessible HTTPS endpoint. No SQL Server credentials in the function definition, no database port open to the internet, no direct connection from OpenAI to production infrastructure.
TrendOps normalises SQL query results into structured, labelled responses. Function results include field names and values the model can reason about — not cryptic column identifiers from an organically-grown production schema.
TrendOps handles aggregation server-side. Function responses return summarised, filterable data — not thousands of raw rows that exhaust context budget and drive up token costs.
TrendOps executes defined queries — the model calls parameterised endpoints, not freeform SQL against production tables. DBAs retain control over which queries run and which tables are exposed.
TrendOps Edge queries SQL Server continuously. Function responses return current production values — not a snapshot from a replication pipeline with built-in latency.
TrendOps normalises SQL data alongside AVEVA PI, FactoryTalk, DeltaV, and MQTT sources. One function endpoint gives the agent a unified view across production data sources.
What you end up with
No SQL Server connection from OpenAI's cloud — the agent calls a cloud API.
Current production values — the agent knows what's happening right now.
Aggregated, context-rich results — not raw rows filling the context window.
One endpoint, every OT and production source — not just SQL.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your production SQL database in plain language and get answers instantly, deployed directly in Microsoft Teams. No function definitions to write, no OpenAPI spec to maintain, no token costs to manage.
Learn about TrendGuru →Your OpenAI agent shouldn't need direct SQL Server access to answer a question about production data
TrendOps gives your OpenAI agent a clean function endpoint for your industrial SQL database — contextualised, aggregated, and available without opening database ports to the internet.
Book a Demo