> For the complete documentation index, see [llms.txt](https://docs.inrupt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.inrupt.com/ess/releases.md). # Release Notes ## ESS 3.2.0 (Released 2026-07-24) ESS 3.2.0 introduces the Search Service, an optional service that enables full-text and semantic search over Solid Pod content. ### Search Service The Search Service replaces the Query/QPF (Fragments) Service that was removed in ESS 3.0. It supports hybrid (keyword + semantic), keyword-only, and semantic-only search over resources stored in Pods, and indexes content automatically as Pods change — no manual sync is required. The Search Service consists of four cooperating microservices: * **Search**: Query API running at `https://search.`, providing hybrid, keyword-only, and semantic-only search, plus faceted discovery, metadata queries, and index management. * **Ingest**: Indexing pipeline that consumes encrypted Kafka events when Pod resources change, extracts text from supported content types (PDFs, images, Office documents, plain text, HTML, JSON, RDF), generates vector embeddings, and dual-writes to OpenSearch (keyword index) and pgvector (vector index). * **Embedding**: ML inference sidecar that generates 384-dimensional vector embeddings using the BAAI/bge-small-en-v1.5 model. Called internally by the Search and Ingest services over mTLS. * **OCR**: Text extraction service for PDFs (text layer with OCR fallback via RapidOCR) and images. Called internally by the Ingest Service over mTLS. In hybrid mode (the default), search results from BM25 keyword search (OpenSearch) and semantic vector search (pgvector) are merged using Reciprocal Rank Fusion (RRF). When the Embedding Service is unavailable, hybrid searches automatically degrade to keyword-only mode and affected ingest events are queued to the dead-letter queue for replay after recovery. For details, see the [Search Service](/ess/services/service-search.md) documentation. ## ESS 3.1.0 (Released 2026-06-29) ESS 3.1.0 introduces least-privilege database credential separation for PostgreSQL-backed services. ### Database Credential Separation (DML/DDL Split) ESS services that use PostgreSQL now support separate database credentials for schema migrations and application runtime: * **DDL credentials** are used by Flyway at startup to run schema migrations. These users are granted the PostgreSQL master role so that migrated objects remain owned by the `postgres` user. * **DML credentials** are used at runtime for application queries. These users are restricted to `CONNECT`, `USAGE`, `SELECT`, `INSERT`, `UPDATE`, and `DELETE` on the `public` schema only. This separation follows the principle of least privilege: the credentials used during normal operation cannot modify the database schema, reducing the blast radius of a compromised credential. In the default configuration, both sets of credentials reference the same Kubernetes secret — no changes are required to upgrade. The credential split is opt-in. For details on enabling credential separation, see the [3.x Changelogs](/ess/releases/changelog.md). ## ESS 3.0.0 (Released 2026-05-27) ESS 3.0 is a major release that introduces native Identity Provider support, permanent resource identifiers, simplified Access Grant flows, and environment isolation. ### Native Identity Provider Support ESS now supports direct integration with external OIDC-compliant Identity Providers. Clients authenticate with their existing IdP and exchange the resulting token for an ESS Access Token via a token exchange endpoint hosted by the [Platform Management service](/ess/services/service-platform-management/token-exchange.md). The ESS OpenID Broker is no longer required as an intermediary. ### Identifiers ESS assigns permanent, globally unique identifiers to storages, resources, agents, and clients. Resources are now accessible via canonical URIs (`{storage-id}/sc/{resource-id}`) in addition to path-based URIs (`{storage-id}/sp/{resource-path}`). Access Grant issuing and notification subscriptions must use canonical URIs so that access is more stable and secure. ### Simplified Access Grant Flow The UMA service has been removed. Access Grants now serve as receipts — once the resource owner approves an Access Grant, the recipient can retrieve the granted resources directly using their ESS Access Token. ESS checks the grant server-side, so no UMA negotiation or additional token exchange is needed. Additionally, Access Grants are now fully independent of ACP — no VC Matcher policies or ACP enablement configuration is required. This simplifies the access flow, reduces client code complexity, and eliminates a common source of hidden authorization failures. ### Environment Isolation Each ESS service can operate within its own named PostgreSQL database schema. This provides deployment flexibility — all services can connect to a single database instance, or separate database instances can be used for each service. ### Unified User Provisioning All user provisioning — including account creation, WebID management, and storage allocation — is handled through the [Platform Management service](/ess/services/service-platform-management/platform-management-api.md). The Pod Provisioning Service and WebID Service endpoints are no longer called directly by clients. ### Removed Services The following services have been removed in ESS 3.0: * **UMA Service**: Replaced by simplified Access Grant flow with direct resource access * **Query/QPF (Fragments) Service**: Being replaced with new search capabilities * **Notification Gateway Service**: Removed * **WebSocket Notification Service**: Removed; use the Notification Delivery Service ## Changelogs For changelogs, see [3.x Changelogs](/ess/releases/changelog.md).