The control plane is a schema

There is a piece of infrastructure that every serious team building on large language models ends up writing twice. The first time, it does not look like infrastructure at all: a function that calls a provider, a retry loop, an environment variable holding a key. Six months later it has become a small, undocumented operating system, with prompt strings scattered across the codebase, per-customer usage limits enforced by hope, provider keys in plaintext configuration, and no reliable answer to the simplest operational question of all: what did we send, to whom, and what did it cost?

The market's dominant answer to this problem has been the network-level gateway: a proxy that sits between the application and the model providers, terminating requests, applying policy, and keeping its own state in its own store. It is a reasonable answer, and for large heterogeneous estates it is often the right one. But it moves the state that matters, prompts, quotas, call history, embeddings, spend, to the wrong side of the wire: away from the application's own data, into yet another system to deploy, secure, back up and reconcile.

AYXZA Relay takes the opposite position: the gateway is a library, and the control plane is a database schema. It is a self-hosted Python SDK that embeds an application-level LLM gateway directly in the consumer process, with PostgreSQL as its single stateful dependency. No sidecar, no proxy tier, no Redis, no external control plane. The application already has a database; the Relay argues that this is precisely where LLM operations belong.

One process, one schema

The Relay installs its entire operational surface as a dedicated PostgreSQL schema, versioned through explicit, strictly additive migrations. Inside that schema live the objects that ad-hoc integrations never quite formalise: a model registry that declares each model's provider, cost profile and capabilities; versioned meta-prompts, so that prompt changes are data changes with history rather than code deployments; per-user quotas that block at the gateway before money is spent; a full call ledger with token usage, cost and latency per invocation; and a job-tracking substrate for long-running work, with three strict states, immutable terminal transitions, staleness detection and resumption chains in which a resumed job references the job it continues.

Provider credentials are encrypted at rest with symmetric authenticated encryption; they are the customer's keys, stored in the customer's database, decrypted only inside the customer's process. The vendor never sees a request, a key, or a byte of data. The licensing mechanism is coherent with this stance: an offline-verified, Ed25519-signed license token, checked against a public key embedded in the SDK. No phone-home, no telemetry, fully functional in air-gapped deployments.

Provider plurality without adapter sprawl

The Relay speaks natively to Gemini, Anthropic's Claude, OpenAI and Vertex AI, and to the long tail of the 2026 landscape through a single generic OpenAI-compatible adapter: point it at a base_url, supply a key and optional headers, and the same code path covers aggregators, low-latency inference clouds, open-weight hosts, and local engines such as Ollama, vLLM or llama.cpp. Adding a provider is configuration, not development.

More interesting than the breadth is where the intelligence sits. Capability enforcement lives in the gateway, not in the adapters: a multimodal request against a model not registered as multimodal fails typed and fast, before any network call. Structured output goes through a normalisation layer that reconciles each provider's JSON-schema dialect, stripping and adjusting the constructs that individual backends reject, so that one schema definition works across the fleet. A pre-call context-window check rejects oversized requests locally, with a conservative heuristic, rather than paying a provider round-trip to learn the obvious.

Around this core, the Relay builds a resilience layer designed as one coherent notion of provider health: synthetic health probes that exercise the real path (key, throttle, network, model) while marking themselves for exclusion from cost reporting; per-provider circuit breakers; key pools with rotation and per-key cooldown on authentication failure; and declarative fallback, so that an unavailable provider can degrade onto an equivalent, including a local engine. Token streaming is specified once, as a single event contract across the whole provider family, with usage and finish state consolidated at close, and exposed both to the embedding application and through a token-authenticated HTTP service layer for non-Python consumers. Provider batch APIs ride on the same job substrate as everything else.

Knowledge, residency, and the ledger

The Relay ships with a knowledge base built on pgvector, in the same schema as everything else: sources, chunks, embeddings, retrieval. The retrieval design extends from pure vector search to hybrid retrieval, combining vector similarity with PostgreSQL full-text search and an optional reranking stage, with selectable chunking strategies and a deliberately fail-soft posture: knowledge augments answers, it must never take the application down.

Data residency is treated as an engineering requirement rather than a slide. The embedding and inference path supports pinning to EU multi-region endpoints, so that a European deployment can keep its vectors and its traffic on European infrastructure, verified live rather than assumed. On the accountability side, every administrative action lands in an audit log written in an independent transaction, so the record survives even when the operation it records is rolled back. Above the raw ledger sit cost budgeting and reporting views, aggregating spend by provider, period and application feature, and a GDPR-aligned retention and purge facility with dry-run execution. Observability is an optional extra built on OpenTelemetry, with spans around calls, providers, retries and retrieval, and strictly zero overhead when disabled.

Verifiability as a feature

A design principle runs through all of this: every capability must be provable through an accessible surface, including against production data. The Relay's administrative console, protected by dual authentication and CSRF discipline, includes a test portal: a chat playground, an embedding tester, a structured-output validator, live streaming inspection, provider-health and circuit-breaker panels, batch status, retention dry-runs. Internally, the same philosophy takes the form of decision sentinels: append-only contract tests that crystallise every architectural decision, so that the public API surface cannot drift silently and a frozen contract stays frozen until a major version says otherwise.

A note of caution

The strongest argument against an in-process gateway deserves to be stated plainly. When an organisation runs dozens of heterogeneous applications, in several languages, and needs one enforcement point for all of them, a network-level proxy is genuinely the better tool: policy in one place, polyglot by construction, upgradable without touching the applications. An embedded library binds the gateway's lifecycle to the application's, and its full surface to Python and PostgreSQL. That is a real constraint, not a footnote.

The counter-argument is one of locality. For a product whose state already lives in PostgreSQL, the proxy model duplicates rather than simplifies: a second store of truth for quotas and history, a second thing to secure, a reconciliation problem that did not previously exist. The Relay's HTTP service layer covers the polyglot case where it actually arises, while everything that benefits from transactional proximity, quotas, ledgers, embeddings, audit, stays where the application's own data lives. The bet is not that proxies are wrong; it is that for a large class of systems, the database was the control plane all along.

What this is, in the end

AYXZA Relay is built by AYXZA, an Italian studio whose claim is a design position rather than a slogan: software in which intelligence is not a feature, it is the material. The Relay is that position turned into infrastructure, an SDK the customer runs on their own machines, with their own database and their own provider keys, and a vendor whose product ends where the customer's data begins.