> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prisme.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Databases Overview

> Databases used by Prisme.ai: roles, version requirements, recommended managed services.

Prisme.ai relies on 3 database engines. Each has a dedicated page covering role, version, configuration, backup, updates, scaling and least privileges.

| Database                                                                                           | Role in the platform                                         | Minimum version                    | Recommended managed                                     |
| -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------- | ------------------------------------------------------- |
| [PostgreSQL](/self-hosting/databases/postgresql) **or** [MongoDB](/self-hosting/databases/mongodb) | Users, permissions, collections, workspace metadata          | PostgreSQL 12+ / MongoDB 6+        | RDS, Azure DB for PostgreSQL, Cloud SQL / MongoDB Atlas |
| [Redis](/self-hosting/databases/redis)                                                             | Event broker, runtime cache, sessions, crawler engines state | 6.2+                               | ElastiCache, Azure Managed Redis, Memorystore Redis     |
| [Elasticsearch or OpenSearch](/self-hosting/databases/elasticsearch)                               | Events storage, crawler index, search engine                 | Elasticsearch 8.x / OpenSearch 2.x | OpenSearch Service, Elastic Cloud                       |

<Info>
  **We recommend PostgreSQL** for new deployments. It is mature, ubiquitous in managed cloud offerings (RDS, Azure Flexible Server, Cloud SQL), generally cheaper to operate, supports Entra ID / IAM passwordless auth on Azure, and is what most ops teams are already comfortable backing up and scaling. MongoDB remains supported — pick it only if you already run MongoDB at scale or have a strong team preference for it.
</Info>

<Note>
  Detailed sizing, backup, scaling and updates for each engine live on the per-database pages. Operational strategy (when, how often, RPO/RTO) lives under [Operations](/self-hosting/operations/backup).
</Note>

## Production topology

For production deployments we recommend the following per-engine topology. Versions live in the table above; sizing details and rationale live on the per-engine pages.

### PostgreSQL or MongoDB

* **Single shared cluster** for the three databases (`users`, `permissions`, `collections`) — keeps the initial deployment simple. 3-node cluster (primary + 2 standby on PostgreSQL, or a 3-node replica set on MongoDB), ≥ 2 GB RAM, 2 vCPU, 1,000 IOPS and ≥ 10 GB disk per node.

<Note>
  Under sustained high load, the auth path (`users` + `permissions`, critical on every request) can be impacted by `collections` growth — these have very different access patterns. If a single cluster proves insufficient, **split into two clusters**: one for `users` + `permissions`, one for `collections`. They can then be sized and backed up independently.
</Note>

### Redis

* **2 separate instances**: one dedicated to the event broker (Redis Streams), one for everything else (runtime cache, sessions, crawler search engine state).
  The broker uses `allkeys-lru`; the other instance uses `noeviction` — co-locating them on a single instance forces `noeviction` everywhere and risks memory pressure from broker streams.\
  Each instance: ≥ 3 GB RAM, 2 vCPU.

### Elasticsearch or OpenSearch

* **3-node cluster**: 16 GB RAM and 4 vCPU per node. **Disk**: start at **≥ 50 GB per node** on a dev environment and **≥ 200 GB per node** in production, then grow progressively based on actual usage and retention. Can be shared with the vector store via distinct index prefixes (see below).

### Vector store

AI Products installation also requires a **vector database**, served by **Elasticsearch or OpenSearch** — it can share the same cluster as the events store or live on a separate one.

<Note>
  Redis is no longer supported as a vector database since the v27 platform.
</Note>