Skip to main content
Prisme.ai relies on 3 database engines. Each has a dedicated page covering role, version, configuration, backup, updates, scaling and least privileges.
DatabaseRole in the platformMinimum versionRecommended managed
PostgreSQL or MongoDBUsers, permissions, collections, workspace metadataPostgreSQL 12+ / MongoDB 6+RDS, Azure DB for PostgreSQL, Cloud SQL / MongoDB Atlas
RedisEvent broker, runtime cache, sessions, crawler engines state6.2+ElastiCache, Azure Managed Redis, Memorystore Redis
Elasticsearch or OpenSearchEvents storage, crawler index, search engineElasticsearch 8.x / OpenSearch 2.xOpenSearch Service, Elastic Cloud
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.
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.

​
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 and 1,000 IOPS per node.
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.

​
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. 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.
Redis is no longer supported as a vector database since the v27 platform.