Entities (Neon)

There are two ways to work with relational (Neon Postgres) data from a PRISM app:

1. defineEntity — a config-driven admin generator that maps one entity to full CRUD screens, backed by the company-manager tRPC procedures.
2. Direct Neon access — the framework's sql tagged template for hand-written queries.

defineEntity

defineEntity maps a single entity to list / detail / new / edit screens plus CRUD, backed by the company-manager tRPC procedures. It is generic over the tRPC procedure names — a typo in a procedure name is a compile error.

Transport and configuration

The tRPC transport is cmQuery (GET) / cmMutate (POST), from the kit's cm.ts. Base, tenant, and site come from configureManage(...), called once as a side-effect import:

import { configureManage } from "@bext-stack/manage";

configureManage({
  appId: "<app-id>",
  cmBase: "…",
  host: "…",
  origin: "…",
  tenantId: "…",
  siteId: "…",
});

Thin re-export pattern

Host a generated entity by re-exporting the kit's entity module from a route file — the route stays a thin shim:

// src/app/manage/posts/page.tsx
export { loader, default } from "@bext-stack/manage/entities/posts";

Example: helpdesk knowledge base

The helpdesk KB entity is a real defineEntity config wired to these procedures:

Because defineEntity is generic over these names, renaming or mistyping one is caught at compile time. See Helpdesk.

Direct Neon access

For hand-written queries the framework exports a tagged-template SQL helper:

import { sql, database, POSTGRES_DIALECT } from "@bext-stack/framework";

const posts = await sql`SELECT id, title FROM posts WHERE tenant_id = ${tenantId}`;

The Neon connection string is fetched once via a loopback KV read of the key cm:database_url, so you do not configure it in the app.

Where to next