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

> Source: https://netray.co/erp-ai/xtuple-ai-integration
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## 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.

## Kind

platform

## Erp Family

other

## Erp Products

- xTuple ERP
- xTuple PostBooks

## Industries

- Manufacturing
- Distribution

## Region

Global

## Persona

IT Director

## Eyebrow

xTuple + on-prem AI

## Intro

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.

## Pain Points

### Business logic lives in stored procedures few people can safely change

**Detail:** 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

**Detail:** 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

**Detail:** 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

**Detail:** 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

**Detail:** 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.

## Use Cases

### Natural-language queries over existing views and stored procedures

**Description:** 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."

**Erp Objects:** 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

**Description:** 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.

**Erp Objects:** wo, woitem, itemsite, bomitem

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

### Purchase order follow-up agent

**Description:** 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.

**Erp Objects:** 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

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

**Erp Objects:** 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

**Description:** 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.

**Erp Objects:** crmacct, quhead, cohead

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

### Stored procedure and customization documentation

**Description:** 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.

**Erp Objects:** 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

**Description:** 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.

**Erp Objects:** wo, itemsite, invhist

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

## Architecture

**Overview:** 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.

**Layers:**

#### PostgreSQL connector

**Detail:** 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.

#### Semantic layer

**Detail:** Maps xTuple's table and column names (wo, itemsite, cohead, poitem, and related tables) to the business terms operations and finance staff actually use.

#### Model serving

**Detail:** 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.

#### Retrieval and agents

**Detail:** 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.

#### Governance and audit

**Detail:** Queries and answers are logged against the requesting user, with access scoped to match roles already defined in xTuple's own security configuration.

## Deployment Options

### Air-gapped on-prem

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

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

### Private or sovereign cloud

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

**Detail:** 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

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

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

## Compliance

### 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.

**Framework:** GDPR / regional data protection

### 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.

**Framework:** Customer flow-down and NDA terms

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

**Framework:** Data continuity and key-person risk mitigation

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

**Framework:** SOC 2 expectations from downstream customers

## Integration Notes

- 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.

## Product Fit

### DataRay

**Why:** 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

**Why:** 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.

## Engagement

### Discovery

**Duration:** 3-4 weeks

**Deliverables:**

- 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

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- 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

### Production

**Duration:** 4-5 weeks

**Deliverables:**

- 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

### Scale

**Duration:** Ongoing

**Deliverables:**

- 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

## Buyer Questions

- 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?

## Faq

### Is xTuple still a reasonable ERP to invest further in?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

xTuple AI, xTuple AI integration, AI for xTuple ERP, on-prem AI for xTuple, xTuple PostgreSQL AI, xTuple copilot, private LLM xTuple, xTuple natural language query, xTuple stored procedure AI, xTuple manufacturing AI, xTuple modernization AI, PostgreSQL ERP AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json