Cognee Cloud Architecture

Cognee Cloud layers orchestration and managed services on top of the open-source Cognee storage model. This document explains, at a high level, how the main components fit together.

​

System Overview

Cognee Cloud’s architecture centers around two main layers that work together to provide a managed knowledge processing platform:

​

Managed Compute (Kubernetes)

Cognee Cloud runs as a managed service on AWS EKS:

• API Services: Each tenant runs its own Cognee application, which serves the REST endpoints and handles authentication (see Cloud SDK)
• Per-tenant isolation: Every tenant is provisioned as its own dedicated deployment, so tenants don’t share application compute

This keeps execution reliable and scalable while all infrastructure is managed by Cognee Cloud—users never provision servers, clusters, or credentials.

​

Storage Services (Managed by Cognee Cloud)

All data persistence is handled through Cognee Cloud’s managed storage infrastructure:

• Dedicated tenant database – Each tenant has its own managed PostgreSQL database holding all of that tenant’s durable state: relational data, the vector embeddings generated during the cognify process, and the knowledge graph
• Platform database – A separate PostgreSQL database, isolated from all tenant data, stores users, quotas, and billing records

Within a tenant, each dataset maintains separate storage namespaces for its vector and graph data.

​

Key Architectural Principles

• Tenant & Dataset Isolation: Each tenant runs as its own deployment with a dedicated database, and processing happens at the dataset level with separate storage namespaces (see permissions & access control for details)
• Managed Infrastructure: Users don’t configure compute, storage, or database credentials—everything is managed by Cognee Cloud
• Compatibility: Storage schemas remain compatible with self-hosted Cognee for easy migration

​

Continue exploring