Specialist ERPsERP Platform

xTuple + on-prem AI

AI for xTuple ERP, Grounded Directly in the PostgreSQL It Already Runs On

Short answer

AI for xTuple connects a private LLM directly to xTuple's PostgreSQL database, including the stored procedures and views that hold most of its business logic, so operations and finance staff can ask plain-English questions and get answers grounded in live manufacturing order and inventory data. Because xTuple already keeps its core logic in the database rather than a separate application tier, this is often a more direct integration than with ERPs that hide logic behind a proprietary API.

ERP: xTuple ERP, xTuple PostBooks
Industries: Manufacturing, Distribution
Written for: IT Director

Discuss your xTuple ERP environment See use cases

xTuple, built on the PostgreSQL-native architecture that traces back to OpenMFG, is unusual among mid-market ERPs in how much of its actual business logic lives in the database itself: stored procedures, views, and triggers do real work that in most other ERPs would sit in an application server or middleware layer. For a company that wants AI grounded directly in its data, that is an advantage most ERPs do not offer, because the meaning of the data is already partly encoded in SQL rather than buried in undocumented application code.

The reality most xTuple customers are managing today is a smaller, more specialized ecosystem than it was a decade ago. New development activity and the pool of consultants who know xTuple deeply have both narrowed, which means the risk of losing the one person who understands a given customization is higher than with a more actively developed platform. Companies still running xTuple typically do so because it fits their manufacturing or distribution process well and migrating is expensive, not because the vendor ecosystem is thriving.

That makes the practical question less about vendor AI features (xTuple has not built a significant generative AI layer) and more about how to extract value from a stable, well-understood, PostgreSQL-based system without betting the company's data on a platform with an uncertain roadmap. A private AI layer that reads the existing database, including the stored procedures that already encode business rules, is a way to get modern question-answering capability without waiting on the vendor.

This page covers how that AI layer connects to xTuple's schema, what a realistic set of use cases looks like given the smaller support ecosystem, and the honest trade-offs worth weighing before investing further in a platform with reduced active development.

What usually gets in the way

The problems we hear most from it director teams running xTuple ERP.

Business logic lives in stored procedures few people can safely change

Costing, order processing, and inventory logic are implemented as PL/pgSQL stored procedures and triggers; modifying them without a deep understanding of the existing logic risks breaking behavior that has worked correctly for years.

The consultant and partner ecosystem has shrunk

Fewer active xTuple implementers and a smaller community mean that finding help for anything beyond routine administration takes longer and costs more than it would for a more actively supported ERP.

OpenRPT reporting requires a specialized skill

xTuple's native reporting tool, OpenRPT, is capable but has its own report-definition format that few staff outside the original implementer know how to modify, so most ad hoc questions still go through someone exporting data manually.

Vendor roadmap visibility for modern needs is limited

With reduced active development, there is little public signal about how or whether xTuple plans to address integration with modern AI, cloud, or mobile expectations, leaving customers to solve those gaps themselves.

Shop-floor data capture is often disconnected from the core system

Many xTuple shops still rely on paper travelers or spreadsheets for shop-floor status because the native manufacturing order screens were not built with today's mobile or tablet-based workflows in mind.

Where AI earns its place in xTuple ERP

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Natural-language queries over existing views and stored procedures

Because xTuple already encodes business logic in views and stored procedures, the assistant can reuse that existing logic directly rather than reverse-engineering it from application code, answering questions like "which manufacturing orders are short a component."

Touches: PostgreSQL views, stored procedures, wo (work order) and itemsite tables

Outcome: Turns existing, already-correct database logic into a question-answering layer without rebuilding the business rules elsewhere.

Manufacturing order status query

Planners ask which work orders are open, late, or waiting on material, with the answer built from the same tables the native xTuple screens use.

Touches: wo, woitem, itemsite, bomitem

Outcome: Replaces manual navigation through xTuple's manufacturing screens for a quick status check.

Purchase order follow-up agent

The agent reviews open purchase order lines against promised dates and drafts a follow-up for a buyer to review before it goes to the supplier.

Touches: poitem, pohead, vendinfo

Outcome: Turns a manual review of overdue POs into a queue of drafted follow-ups ready for approval.

Inventory and item-site query

Staff ask about on-hand, allocated, and available quantity by site without navigating multiple inventory screens.

Touches: itemsite, invhist, itemloc

Outcome: Reduces the number of ad hoc requests to whoever historically ran the inventory report.

CRM-to-quote history for a quoting agent

Sales staff ask for a customer's order and quote history to speed up a new quote, drawing on data the CRM module already holds.

Touches: crmacct, quhead, cohead

Outcome: Cuts the time to assemble quote context from prior orders for a repeat customer.

Stored procedure and customization documentation

The assistant reads existing stored procedure and view definitions to explain what a given piece of custom logic actually does, addressing the key-person risk directly.

Touches: pg_proc definitions, custom views, triggers

Outcome: Turns undocumented database logic into a searchable explanation, reducing dependence on any one remaining expert.

Exception triage on stalled manufacturing orders

When a manufacturing order stalls, the assistant checks linked inventory shortages and prior similar cases to summarize a likely cause before a planner investigates further.

Touches: wo, itemsite, invhist

Outcome: Shortens the time between a stall being noticed and a planner understanding why.

Reference architecture

The AI layer connects to a read-only replica or scoped role on the existing PostgreSQL database, reusing xTuple's own views and stored procedures wherever they already encode the correct business logic, rather than duplicating that logic in a separate layer.

1
PostgreSQL connector
Connects through a dedicated read-only PostgreSQL role, ideally against a replica, and calls existing views and stored functions directly rather than reimplementing xTuple's business rules.
2
Semantic layer
Maps xTuple's table and column names (wo, itemsite, cohead, poitem, and related tables) to the business terms operations and finance staff actually use.
3
Model serving
An open-weight model served with vLLM or Ollama on customer-owned or customer-controlled GPUs, sized modestly given the typical scale of xTuple deployments.
4
Retrieval and agents
Retrieval-augmented generation grounds answers in live SQL queries against the existing schema; any agent that drafts a purchase follow-up or other outbound communication requires human approval.
5
Governance and audit
Queries and answers are logged against the requesting user, with access scoped to match roles already defined in xTuple's own security configuration.

Integration notes for your ERP team

Connects via a dedicated, read-only PostgreSQL role, ideally against a streaming replica rather than the primary transactional database.
Reuses existing xTuple views and stored functions wherever they already implement correct business logic, avoiding duplicate or divergent logic.
Schema mapping is done directly against the PostgreSQL catalog (pg_class, pg_proc) rather than relying on xTuple documentation, which is thinner than for more actively maintained ERPs.
Write-back actions (draft POs, follow-up emails) go through a reviewed queue a human approves, never a direct write to the transactional database.
OpenRPT report definitions can be used as an additional documentation source for what a given report or field is intended to show.
Given the smaller support ecosystem, extra discovery time is budgeted for tracing undocumented custom stored procedures before building the semantic layer.

Deployment options

Air-gapped on-prem

The most common fit for xTuple customers, who are typically running the application on their own servers already.

The model and connector run on customer-owned hardware alongside the existing PostgreSQL server, with no outbound network path required.

Private or sovereign cloud

Companies that have already migrated their PostgreSQL database to a managed cloud instance.

Deployed in a dedicated tenant or VPC under the customer's own cloud account, connecting to the managed database through a scoped, read-only role.

Hybrid

Distributors or manufacturers with one xTuple instance per site after growth through acquisition.

A central retrieval layer connects to each site's PostgreSQL instance separately, preserving per-site data residency rather than merging databases.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

GDPR / regional data protection

On-prem deployment keeps personal data in CRM or HR-adjacent tables inside infrastructure the customer already controls, with no third-party AI API in the data path.

Customer flow-down and NDA terms

For xTuple customers supplying larger manufacturers with restrictions on cloud AI, an on-prem deployment gives a concrete answer without needing a new compliance program.

Data continuity and key-person risk mitigation

Documentation use cases that explain existing stored procedures directly address one of the platform's biggest practical risks, independent of any formal compliance framework.

SOC 2 expectations from downstream customers

Read-only, scoped database access and full query logging give a concrete answer for a customer vendor-security questionnaire, even on an older platform.

Where Netray fits

DataRay

xTuple's PostgreSQL-native architecture, where business logic already lives in views and stored procedures, is a strong fit for DataRay's approach of chatting directly with an existing data source.

Custom build

The combination of a narrower support ecosystem and business-critical logic embedded in stored procedures usually calls for a bespoke connector and careful discovery rather than a generic template.

How an engagement runs

Phase 1 . 3-4 weeks

Discovery

-Inventory of stored procedures, views, and triggers that encode business logic
-Schema mapping directly against the PostgreSQL catalog
-Priority use cases ranked by planner, buyer, and finance pain
-Risk assessment covering key-person dependencies on custom logic

Phase 2 . 6-8 weeks

Pilot

-Working connector against a replica or staging PostgreSQL instance
-3-5 use cases live for a pilot group
-Accuracy review against known correct answers
-Documentation of previously undocumented stored procedures uncovered during the pilot

Phase 3 . 4-5 weeks

Production

-Cutover to a read-only replica of the production database
-Full audit logging in place
-Runbook for adding use cases without new development each time
-Handoff documentation reducing dependence on any single internal expert

Phase 4 . Ongoing

Scale

-Expansion to additional sites for multi-site deployments
-Additional agent use cases with approval workflows
-Model refresh as open-weight options improve
-Periodic review given the platform's slower pace of vendor-driven change

Questions to ask any vendor, including us

A short list that separates real xTuple ERP AI work from a chatbot demo.

Does the connector reuse our existing stored procedures and views, or does it duplicate business logic in a new layer that could drift out of sync?
Is the AI layer reading from a replica or a scoped, read-only role, never the primary transactional connection?
How much discovery time is budgeted for tracing undocumented custom stored procedures before anything goes live?
Where does the model run, and can the network path be confirmed to show no data leaving our environment?
Given the smaller xTuple ecosystem, does the team doing this work have direct PostgreSQL and PL/pgSQL experience, not just generic ERP experience?
What happens to the documentation this project produces if we eventually decide to migrate off xTuple?
Can we start with read-only question answering only, with no write-back to the production database?
What GPU hardware is actually required for a deployment at our scale?

Frequently asked questions

Is xTuple still a reasonable ERP to invest further in?

That depends on your own roadmap. xTuple's active development and consultant ecosystem have narrowed, so companies planning a multi-year future on the platform should weigh that honestly against the cost of migration. For companies staying on xTuple regardless, adding a private AI layer is a lower-risk way to modernize than waiting on the vendor.

Why does xTuple's architecture matter for AI integration?

Because so much of xTuple's business logic already lives in PostgreSQL views and stored procedures rather than a separate application tier, an AI layer can reuse that existing logic directly. That is often a more direct integration path than with ERPs that hide their business rules behind a proprietary API.

Does this require changes to the production xTuple database?

No. The connector uses a dedicated read-only role, ideally against a replica, and does not require schema changes or new tables in the production database.

How do you handle undocumented custom stored procedures?

Discovery time is budgeted specifically for this, since xTuple's documentation is thinner than for more actively maintained platforms. The team traces logic directly from the PostgreSQL catalog and existing procedure definitions rather than relying on vendor documentation alone.

Can the AI write data back into xTuple?

It can draft a document such as a purchase order follow-up, but any write to the production database goes through a reviewed queue a human approves. Nothing writes directly to the transactional database.

Is this only useful for large xTuple deployments?

No. Most xTuple customers are small to mid-sized manufacturers or distributors, and a right-sized deployment, focused on two or three high-value use cases with modest GPU hardware, fits that scale.

What if we eventually migrate off xTuple?

The documentation and semantic mapping produced during this work, particularly the explanations of existing stored procedures, are useful independent of the AI layer itself and can inform a future migration project even if the AI deployment changes.

Related guides

RAG + SQL + permissions

A Private LLM Grounded on Your ERP Data

How a private LLM answers questions on your ERP data: RAG plus text-to-SQL, role-based permissions inherited from the ERP, and where each fits.

Ask your ERP anything

Natural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English

See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.

Agents + approval gates

AI Agents for ERP, Running On-Prem

A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.

ERP migration + on-prem AI

AI-assisted data migration for ERP implementations

AI speeds ERP data migration by profiling legacy data, proposing field mappings, and flagging cleansing issues before cutover, with a human validating every rule.

ERP AI Buyer Guide

How to Choose an ERP AI Implementation Partner

A CIO checklist for picking an ERP AI implementation partner: the architecture questions to ask, red flags, pricing models, and what to demand in the SOW.

QAD + on-prem AI

AI for QAD Adaptive ERP in automotive and industrial manufacturing

Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows xTuple ERP

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides