DEV Community: M C

Best graph databases for an AI company brain in 2026

M C — Mon, 14 Sep 2026 12:47:55 +0000

A company brain connects the knowledge spread across your organization, including information about people, projects, decisions, documents, and more. If your team decides to build rather than buy, you need a database that can organize this knowledge and retrieve the right context.

A graph database makes sense when answers depend on relationships, historical context, or information pulled from several connected sources. If you want a ready-made workplace search or chat experience, a packaged platform may be a better fit.

The right graph database depends on what you need most. HydraDB is a strong option for teams that want object-store-native graph storage, control over their graph structure, and managed retrieval that brings dense search and graph context together.

Key takeaways: which graph database is best for an AI company brain?

Choose HydraDB for object-store-native graph storage, control over your graph structure, and managed retrieval that blends dense search, BM25, and graph context.
Go for Neo4j for Neo4j-native Cypher behavior, APOC, GDS, or AuraDB.
Pick Neptune for AWS-managed governance or GraphDB for RDF and materialized inference.
Consider ArangoDB for document, graph, and vector workloads through AQL. Memgraph suits streaming ingestion or in-memory execution, while FalkorDB offers GraphBLAS, OpenCypher, and a GraphRAG SDK.
Let your dominant workload constraint drive the choice. This could be storage, authorization, temporal freshness, or operational trust.
Treat the graph database as infrastructure. Source ACL fidelity, citations, orchestration, and employee UX remain application or platform responsibilities.

Quick comparison of the best graph databases for AI company brains

As of September 2026, the right graph database depends on your workload and the exact product surface you’re evaluating. Storage, query, retrieval, authorization, and operating boundaries all vary across current options.

Option	Best fit	Storage model	Query/API	Retrieval and context support	Pricing and efficiency	Key tradeoff
HydraDB	Organization-scale company brain where object-store-native graph state, customer-owned semantics, and managed context matter	S3-compatible object store is the durable source of truth. Memory and local NVMe serve as disposable caches	Practical OpenCypher subset over Bolt and HTTP	Managed v2 dense-plus-BM25 retrieval, exact filters, optional graph context, source-bearing results, and temporal facts	The open core is AGPL-3.0. Managed plans start free, then cost $25 per month for up to 2 GB or $399 per month for up to 10 GB. Durable graph storage and compute scale separately	Not a turnkey employee UX or Neo4j APOC equivalent
Neo4j	Neo4j-native Cypher behavior, APOC, GDS, AuraDB, and edition-scoped tooling	Disk-backed native graph with a configurable page cache	Cypher and Bolt. APOC and GDS are product- and edition-scoped	Vector and full-text indexes. GraphRAG composition remains application-specific	AuraDB Professional lists at $65 per GB-month of RAM and Business Critical at $146. Included storage is twice the RAM capacity. Page-cache, storage, and availability requirements drive sizing	RAM and I/O costs scale with the hot set. Capacity planning depends on topology and edition
Amazon Neptune	AWS-managed graph operation with IAM and the required property-graph or RDF surface	Neptune Database cluster storage. Neptune Analytics is a separate in-memory engine	Gremlin and openCypher for property graphs. SPARQL for RDF	Analytics vector search and Bedrock GraphRAG are separate surfaces	Neptune Database meters instances or serverless capacity, storage, I/O, and transfer. Neptune Analytics is billed separately. Standard and I/O-Optimized configurations suit different I/O profiles	AWS-bound service with a multi-surface architecture
GraphDB, from Graphwise	RDF/SPARQL, materialized inference, ontology-driven GraphQL, or Enterprise clustering	File-backed RDF repository. Enterprise supports a Raft cluster	SPARQL, RDF-star/SPARQL-star, and scoped GraphQL features	Semantic and full-text search. Embedding-based vector search uses Enterprise connectors	GraphDB offers a Free edition and custom Enterprise pricing. Inference rules, concurrent queries, licensed cores, and cluster topology affect resource requirements	RDF, SPARQL, and ontology-governance requirements
ArangoDB, from Arango	One AQL surface across document, key-value, graph, vector, and text-search workloads	RocksDB-backed multi-model engine with single-server and cluster deployment	AQL	ArangoSearch, inverted indexes, and vector indexes	Self-managed and managed options have deployment-specific pricing. Multi-model consolidation can reduce the number of systems, while sharding and replication affect infrastructure requirements	AQL lock-in and multi-model operational scope
Memgraph	Streaming ingestion, Cypher, graph algorithms, or in-memory transactional and analytical execution	In-memory transactional, in-memory analytical, and on-disk transactional modes	Cypher	Vector indexes on nodes and edges plus Kafka, Pulsar, and Redpanda connectors	Community Edition is free. Enterprise pricing is quote-based and scales with memory capacity. The selected storage mode determines the RAM, disk, and recovery profile	In-memory modes tie graph capacity to RAM costs. Mode-specific durability and recovery planning
FalkorDB	GraphBLAS-based property graphs, OpenCypher extensions, or its GraphRAG SDK	GraphBLAS sparse-matrix graph with RDB and AOF persistence options	OpenCypher extensions over RESP and Bolt	Full-text, range, and HNSW vector indexes plus a GraphRAG SDK	Startup starts at $73 per month for 1 GB of RAM. Pro starts at $350 per month. Memory headroom, persistence, and high availability affect total cost	SSPLv1 licensing, with durability, high availability, and security features that vary by tier

How to evaluate graph databases for a company brain

Evaluating graph databases for a company brain, GraphRAG pipeline, or enterprise knowledge graph requires a clear understanding of the workload. Generic benchmarks rarely reflect organizational data and retrieval patterns. Focus on five areas when comparing your options. These are storage architecture, cost and workload efficiency,, authorization boundaries, temporal and source freshness, and operational trust. Also compare retrieval capabilities, graph model control, and query compatibility.

Storage architecture for historical company context

A company brain accumulates context and relationships over time. Its graph grows as teams add more sources and retain historical versions. The pace of that growth depends on ingestion volume, retention policy, extraction behavior, and the data model.

Check how each deployment stores and serves hot and cold data. In-memory modes and page-cache-heavy workloads place different demands on RAM, disk, and I/O, although those mechanisms alone don’t determine latency or cost.

Object-store-native architectures can separate durable state from disposable local caches, while disk-backed native and multi-model engines handle persistence, caching, sharding, and replication their own way. Either way, compare the full cost of your planned deployment, including RAM, storage, I/O, backups, recovery, network, licensing, and operational work.

Cost and workload efficiency

A company brain's cost depends on both its total history and its active working set. Compare how each deployment charges for durable storage, RAM, compute, I/O, replicas, backups, network transfer, licensing, and support.

Normalize the comparison around the same graph size, read/write mix, hot working set, retention period, availability target, and region. A memory-priced service, an instance-priced managed database, and an open-core self-hosted system cannot be compared by list price alone.

Efficiency is workload-specific. Measure hot and cold query latency, throughput, cache behavior, recovery time, and the infrastructure required to meet the same service target. Use vendor benchmarks to understand each architecture, then test the shortlisted products with your own data and topology.

Authorization boundaries

Security in a company brain means separating infrastructure access from application policy. Graph databases offer their own controls, like database or repository boundaries, RBAC, IAM integration, or product-specific logical scopes. Those controls don’t reproduce the permission models of upstream SaaS applications.

Full source-ACL fidelity for end-user answers usually means enforcing permissions outside the database's generic role model. The surrounding system must carry source permissions into retrieval and apply them before context reaches the LLM. Depending on the architecture, this can happen during ingestion, through query middleware, or within the buyer-owned application. Database RBAC alone doesn’t automatically mirror changing permissions in Google Workspace, Slack, Salesforce, Zendesk, Okta, or Entra ID.

Time-aware company context

A company brain needs to track when each fact was valid, not just that it appeared in a document at some point. Reporting lines change, project statuses shift, and policies become outdated.

Check how the database handles incremental ingestion, versioned facts, source attribution, and time-aware relationships. Some systems have managed temporal features that track how long facts remain valid. Others require you to model time through timestamp properties, event nodes, or RDF named graphs.

Without clear temporal modeling, your AI system may return outdated information.

Operational trust for enterprise AI workloads

Evaluate the production readiness of the specific product and deployment model you intend to use. A fully managed cloud platform and a self-hosted core offer different operational capabilities.

Review disaster recovery, point-in-time backups, query observability, and data portability. Consider query language lock-in and how you would migrate if your infrastructure needs changed. Deployment options and vendor support shape how much operational work falls on your team.

Database, managed-platform, and application responsibilities

Each layer handles a different part of the system. Here's how the responsibilities split.

Layer	Owns	Examples
Database layer	Durable graph storage, graph query execution, indexes, persistence, and documented database-level controls	Entities, relationships, properties, timestamps, source references, database or repository boundaries, and product-specific logical scopes
Managed platform layer	Optional ingestion, enrichment, retrieval APIs, temporal and source attribution	Connectors, chunking, entity resolution, dense retrieval, BM25, metadata filters, and graph expansion
Buyer-owned application layer	Final user experience, orchestration, policy enforcement, and end-user authorization	Chat and search UI, workflow automations, tool routing, source-ACL enforcement, and citations

Graph database security and authorization comparison

Deployment and access-control boundaries dictate exactly where database capabilities end and application responsibilities begin.

Option	Deployment boundary	Database authorization	Fine-grained graph authorization	Identity and audit surface	Source-ACL fidelity for end-user answers
HydraDB	Separate managed databases. Collections are logical scopes	Managed controls are contract-specific	Open-core graph-scope authorization for bounded operations	Managed controls are contract-specific	Buyer-owned application
Neo4j	Database controls are product and edition scoped	RBAC in Enterprise, AuraDB Business Critical, and AuraDB Virtual Dedicated Cloud	Label, relationship-type, and property privileges on those surfaces	SSO and audit behavior is deployment and plan specific	Buyer-owned application
Amazon Neptune	One graph per cluster. Use separate clusters or application partitioning	IAM policies and resource controls	Tenant filtering inside a shared graph is application-enforced	IAM, VPC, and CloudTrail	Buyer-owned application
GraphDB, from Graphwise	Repository and server boundaries	Enterprise role controls	Enterprise fine-grained access control	OAuth, OpenID, and audit behavior is edition and configuration specific	Buyer-owned application
ArangoDB, from Arango	Database and collection boundaries (deployment specific)	Enterprise and platform controls	Collection or document enforcement is edition- and design-specific	SSO and audit behavior is edition and platform specific	Buyer-owned application
Memgraph	Multiple databases in Enterprise	Enterprise RBAC	Enterprise label-based access control	Enterprise SSO and audit logging	Buyer-owned application
FalkorDB	Cloud multi-graph and multi-tenancy (tier-specific)	Cloud graph access control. Redis ACLs for self-managed operation	Verify rule granularity on the target tier	TLS, VPC, monitoring, and support vary by Cloud plan	Buyer-owned application

## HydraDB: object-store-native company brain infrastructure

HydraDB is an open-source, object-store-native graph database that separates compute from storage. It provides graph-native context infrastructure for AI applications that require relationship modeling, multi-hop traversals, and temporal context.

When to choose HydraDB

Choose HydraDB when you need durable graph storage, control over your own graph structure, and managed hybrid context retrieval across an organization. It suits teams whose graph context has outgrown a comfortable in-memory or local-disk footprint and who want to retain ownership of their ontology and domain model.

Which HydraDB product surface is evaluated?

Surface	What it covers	Keep separate
Open AGPL-3.0 graph database core	Object-store-native graph storage, traversal, OpenCypher subset, and Bolt-compatible driver surface	Doesn’t natively provide managed hybrid retrieval, ingestion pipelines, or finished application user experience
Managed v2 context/retrieval platform	Ingestion, context enrichment, retrieval APIs, and temporal and source-attributed context	Platform features shouldn’t be attributed to the open core database alone

HydraDB strengths for company-brain workloads

HydraDB's architecture uses S3-compatible object storage as the durable source of truth for the graph. Compute nodes and indexers keep disposable state in memory and on local NVMe SSDs. This separation decouples graph storage costs from compute costs. The durable graph can grow independently of compute provisioning, unlike RAM-provisioned databases where graph growth directly increases memory costs. Latency and elasticity depend on the workload and cache sizing.

The managed v2 platform retrieves Knowledge (shared documents and sources) and Memories (per-user context) using dense search and BM25. It applies exact metadata filters before ranking and can include graph context, source information, and temporal facts.

The Bring Your Own Graph capability lets you attach your own entities, relations, and optional temporal details directly, instead of relying on LLM graph extraction. HydraDB stores and returns that graph through the same retrieval API used for other ingested context. The open core supports a practical OpenCypher subset and documented Bolt-compatible drivers.

HydraDB tradeoffs for company-brain workloads

HydraDB is an infrastructure layer without a turnkey employee user experience or a finished ontology. It’s not a drop-in replacement for workloads that rely heavily on proprietary Neo4j APOC procedures. Source-ACL fidelity and per-fact permission enforcement remain the responsibility of the buyer-owned application layer.

## Neo4j: Cypher, GDS, APOC, and AuraDB requirements

Neo4j is a native property graph database built around Cypher, with drivers, procedures, and analytics available across self-managed editions and its AuraDB managed service.

When to choose Neo4j

Neo4j fits when you need Neo4j-native Cypher behavior, APOC, Graph Data Science, AuraDB, or the tooling and operating model offered by a specific edition.

Which Neo4j product surface is evaluated?

The evaluated surfaces are Neo4j Enterprise for self-hosted deployments and Neo4j AuraDB for managed cloud operation. GraphRAG composition happens at the application layer.

Neo4j strengths for company-brain workloads

Neo4j supports vector indexes and full-text indexes alongside graph traversal. AuraDB backup, point-in-time recovery, high availability, and support all vary by tier. Verify the purchased AuraDB plan to confirm the included features.

The Neo4j Graph Data Science library provides graph algorithms and machine-learning procedures over projected graphs.

Neo4j tradeoffs for company-brain workloads

Neo4j stores graph data on disk and loads data and indexes into its page cache on demand. For large historical workloads, size the hot set, page cache, filesystem cache, disk, and I/O against the intended access pattern. Use a workload-equivalent model for any cost comparison.

You must model temporal state and source provenance explicitly through properties, event nodes, validity intervals, and strict application conventions. Neo4j offers strong database-level permissions, but mapping complex source-system ACLs into these policies remains the application layer's responsibility.

## Amazon Neptune: AWS-managed graph infrastructure

Amazon Neptune is a fully managed graph database that supports property graphs, RDF graphs, and multiple query languages within the AWS ecosystem.

When to choose Amazon Neptune

Amazon Neptune makes sense when you want an AWS-managed graph service that works with IAM, VPC networking, CloudTrail, or Bedrock Knowledge Bases. Evaluate Neptune Database, Neptune Analytics, and Bedrock as separate services.

Which Amazon Neptune product surface is evaluated?

The comparison covers Amazon Neptune Database, including Neptune Serverless, and Neptune Analytics. Capabilities and compute models differ across these surfaces.

Amazon Neptune strengths for company-brain workloads

Neptune supports property graphs through openCypher and Gremlin and RDF graphs through SPARQL. Teams can choose the graph model that fits their ontology requirements.

Neptune integrates with AWS IAM, VPC networking, backups, and monitoring. Neptune Analytics is a separate memory-optimized engine with vector search and graph algorithms. Review its capacity, data-loading path, and query semantics separately from Neptune Database.

Amazon Neptune tradeoffs for company-brain workloads

Building a comprehensive company brain on AWS may require Neptune Database for transactional storage and Neptune Analytics for vector search and graph algorithms. Using both can complicate data freshness and cost planning.

Lexical retrieval often depends on other AWS services. Your exit plan should account for graph export, query-language differences, and the migration of IAM, VPC, and Bedrock integrations. AWS's Neptune migration guidance documents important compatibility differences. Temporal provenance must be modeled explicitly through RDF named graphs or property-graph properties.

## GraphDB, from Graphwise: RDF and semantic knowledge graphs

GraphDB is a scalable semantic graph database and RDF triplestore built to manage structured knowledge models, ontologies, and data based on W3C semantic standards.

When to choose GraphDB

Choose GraphDB when regulated, scientific, compliance, or metadata-heavy workloads require RDF, SPARQL, OWL inferencing, and formal semantic modeling.

Which GraphDB product surface is evaluated?

GraphDB 11.5 documentation anchors this comparison, covering Free and Enterprise database editions and the Enterprise managed service. GraphQL endpoints, LLM tools, semantic similarity, and Enterprise connector-backed vector search vary by edition and add-on.

GraphDB strengths for company-brain workloads

GraphDB's forward-chaining reasoner materializes statements derived from selected RDFS, OWL, or custom rules.

RDF named graphs and metadata can represent provenance, source attribution, and temporal validity when the application models them.

GraphDB tradeoffs for company-brain workloads

Adopting GraphDB requires RDF data modeling and SPARQL-based query workflows. Consider the migration effort and available expertise if your current stack uses property graphs, SQL, or JSON.

RDF and ontology deployments require teams to define vocabularies, rulesets, and governance practices that fit their domain. Temporal validity is represented through explicit RDF data patterns. Confirm the available retrieval features for the edition and add-ons you plan to use.

## ArangoDB, from Arango: multi-model graph, search, and vector workloads

ArangoDB is a native multi-model database that combines document, key-value, and graph data access through a single database core and query language.

When to choose ArangoDB

ArangoDB is worth choosing when you want one AQL surface for JSON documents, key-value access, graph traversal, vector indexes, and text search. It may also fit when you are considering the broader Arango Contextual Data Platform.

Which ArangoDB product surface is evaluated?

This comparison focuses on ArangoDB Enterprise and the Arango Managed Platform (AMP), formerly ArangoGraph Insights Platform. It also considers ArangoSearch and ArangoDB vector indexes. The broader Contextual Data Platform remains a separate Arango surface.

ArangoDB strengths for company-brain workloads

ArangoDB can store JSON documents, serve key-value access, run AQL graph traversals, and use vector indexes in one database product. This may reduce the number of databases in your architecture, depending on the workload and surrounding services.

The proprietary ArangoDB Query Language (AQL) can combine document filtering, vector matching, and graph traversal logic in a single query. For distributed workloads, ArangoDB provides SmartGraphs and clustering features designed to shard graph data and reduce network hops during traversal.

ArangoDB tradeoffs for company-brain workloads

If deep, multi-hop traversal over connected organizational context is your dominant workload, benchmark ArangoDB and the shortlisted graph-focused engines using the same data model, shard locality, topology, concurrency, and queries. The multi-model design alone does not establish a latency advantage or penalty.

AQL-specific application queries require translation when moving to another database. Arango's Cypher-to-AQL translation service is experimental, and it doesn’t make AQL portable to OpenCypher. In ArangoDB itself, temporal state and historical provenance require explicit modeling. Arango's broader Contextual Data Platform documents separate temporal-state capabilities.

## Memgraph: streaming and in-memory graph workloads

Memgraph is a C++ graph database built for streaming and in-memory workloads. It supports in-memory transactional and analytical modes, an on-disk transactional mode, Cypher, and a library of graph algorithms alongside vector indexes.

When to choose Memgraph

Choose Memgraph when your workload depends on Kafka, Pulsar, or Redpanda ingestion, Cypher, graph algorithms, or in-memory transactional or analytical execution. Evaluate its on-disk transactional mode separately when the dataset exceeds your RAM budget.

Which Memgraph product surface is evaluated?

The compared surfaces are Memgraph Community Edition, licensed under the Business Source License, and the separately licensed Memgraph Enterprise and Memgraph Cloud.

Memgraph strengths for company-brain workloads

Memgraph's Kafka, Redpanda, and Pulsar connectors support streaming ingestion into the graph. Mutation and traversal latency will depend on the storage mode, data shape, concurrency, and durability settings, so test the intended workload.

The MAGE library provides graph algorithms and query modules. Memgraph Enterprise adds RBAC, label-based access control, SSO options, multi-tenancy, and audit logging. Confirm the availability of these controls for Community and your selected Cloud plan.

Memgraph tradeoffs for company-brain workloads

In Memgraph's in-memory modes, graph data consumes RAM. Memgraph also supports an on-disk transactional mode backed by RocksDB. Compare the RAM, disk, durability, and recovery requirements of the selected mode on your dataset.

Long-lived temporal history and source provenance still require explicit data modeling. Source-ACL fidelity remains an application responsibility. Memgraph documents vector indexes on nodes and edges. Evaluate lexical retrieval and any fused-ranking path separately rather than assuming database-level vector search replaces a complete hybrid-retrieval system.

## FalkorDB: GraphBLAS, OpenCypher, and GraphRAG SDK workloads

FalkorDB is a property-graph database from the RedisGraph lineage. It uses a SuiteSparse GraphBLAS-based sparse adjacency-matrix representation and supports OpenCypher extensions over RESP and Bolt.

When to choose FalkorDB

FalkorDB is the better fit if you want its GraphBLAS-based property-graph engine, OpenCypher surface, Redis-oriented operating model, or packaged GraphRAG SDK.

Which FalkorDB product surface is evaluated?

The comparison spans FalkorDB's SSPLv1-licensed self-managed database and its managed Cloud tiers.

FalkorDB strengths for company-brain workloads

FalkorDB represents graph adjacency with GraphBLAS-backed sparse matrices. That mechanism doesn’t establish a general latency or throughput advantage, so test traversal and analytical performance using representative queries, data, topology, concurrency, and durability settings.

FalkorDB documents HNSW vector indexes on nodes and relationships, plus full-text and range indexes. Its GraphRAG SDK composes vector search, full-text search, Cypher generation, and relationship expansion. Measure its resource footprint and performance on your selected deployment.

FalkorDB tradeoffs for company-brain workloads

FalkorDB’s durability includes RDB snapshots, AOF logging, and combined persistence options. Compare memory, persistence, recovery, and Cloud-tier costs for hot and historical data. Current documentation doesn’t establish a universal hot-versus-cold cost ranking.

Developers interact with FalkorDB through OpenCypher with proprietary extensions over RESP and Bolt. Don’t assume full compatibility with Neo4j-specific Cypher, APOC, drivers, or tooling. Current documentation lists Cloud graph access controls and multi-graph operation. Confirm that the purchased tier supports the clauses, procedures, and observability you need.

How to test graph databases for a company brain proof of concept

Don’t rely only on pristine synthetic datasets. Organizational data is messy, incomplete, and permissioned. Build the proof of concept around the evaluation areas using sanitized data that reflects your actual sources. Synthetic fixtures can still help test correctness, edge cases, and failure behavior.

How to test cost and workload efficiency

Load data from documents, Slack threads, Jira tickets, CRM notes, and code repositories. Measure latency and throughput when retrieving recent context and context from two years earlier. Record the RAM, compute, durable storage, local cache, I/O, replicas, backups, network transfer, licensing, and operator time required by each deployment.

How to test authorization boundaries

Run the same query using the credentials of an executive, an engineering manager, and a new hire. Confirm that the application filters the graph context according to each user’s permissions in the source systems.

How to test temporal freshness

Ask time-aware questions that require historical context.

"What was the exact status of the payments migration six months ago?"
"Who approved the Project Atlas delay, and what specific source documents prove it?"

Validate whether the system returns source-attributed facts with clear timestamps or validity windows.

How to test operational trust

Test incremental re-ingestion and verify how the system handles deleted or modified source documents. Run backup and restore procedures and test data export paths. Review query observability metrics and measure the vendor's support response times.

Example company-brain query for graph database evaluation

"Trace this customer escalation across Zendesk, Slack, Salesforce, and Jira through to the final resolution commit. Cite the sources and return only the information this employee is allowed to access."

Workload routing for company-brain databases

When evaluating graph databases for your company brain, route your shortlist by your workload's single dominant requirement.

Dominant requirement	Shortlist first	Why
Durable organization-scale company brain with managed hybrid context	HydraDB	Object-store-native durable graph storage, Bring Your Own Graph semantics, and managed retrieval layer
Neo4j-native Cypher behavior, APOC, GDS, AuraDB, or tooling requirements	Neo4j	Product-specific query, procedure, analytics, managed-service, and tooling surface
AWS standardization and Bedrock/IAM alignment	Amazon Neptune	Native AWS governance, networking, audit, and managed service integration
RDF/SPARQL, ontology inferencing, and semantic standards	GraphDB, from Graphwise	W3C semantic graph and formal reasoning surface
Document, graph, and search/vector in one unified engine	ArangoDB, from Arango	Multi-model operational consolidation through AQL
Streaming ingestion, in-memory transactional or analytical execution	Memgraph	Kafka, Pulsar, and Redpanda connectors, Cypher, graph algorithms, and in-memory modes
GraphBLAS-based OpenCypher with a packaged GraphRAG SDK	FalkorDB	Sparse-matrix graph engine, RESP and Bolt clients, and GraphRAG tooling

Notable alternatives to dedicated graph databases for AI company brains

Depending on your architecture, a GenAI workload may fit one of these alternatives to a dedicated, centralized graph database:

Stardog: Choose Stardog when you need semantic data virtualization and federated queries across existing enterprise sources. It lets you query data where it lives rather than ingesting everything into a primary company-brain storage substrate.
Zep or Mem0: Choose an agent-memory service when your main requirement is managed agent memory and persistent context across sessions. They package memory behavior behind APIs, reducing the amount of database infrastructure your team must design.

Conclusion: choose the best graph database for your company-brain workload

The best GraphRAG or enterprise knowledge graph database depends on what your workload needs most. Weigh storage architecture, cost and workload efficiency, authorization, temporal freshness, and operational trust during your evaluation. Also consider retrieval capabilities, control over the graph structure, and query compatibility.

If HydraDB fits your priorities, review the architecture documentation and test representative organizational data against the managed v2 API.

Frequently asked questions about graph databases for company brains

What should I look for when evaluating databases to build a company brain?

Evaluate five primary walls, including storage, cost and workload efficiency, authorization boundaries, temporal and source freshness, and operational trust. Treat retrieval composition, semantic control, and query compatibility as cross-cutting requirements. A graph database should support the required connected-retrieval patterns, while the surrounding platform and buyer-owned application determine ingestion logic, permission mapping, AI orchestration, and the user experience.

How do I build a multi-tenant company brain?

Use only the isolation mechanisms documented for the selected surface, such as separate databases or repositories, clusters, IAM boundaries, RBAC, or product-specific logical scopes. Treat tenant IDs and HydraDB collections as logical partitions unless a documented enforcement boundary says otherwise. Propagate and enforce source-system permissions outside generic database RBAC so answers include only authorized context.

Why use a graph database for a company brain?

Use a graph database when relationships materially affect retrieval or reasoning. A graph can preserve modeled connections and time properties for multi-hop traversal, while source-attributed answers additionally require source references, retrieval logic, and citation handling in the managed platform or application.

What would I build a Perplexity-style brain for my own company on?

Use a platform that combines dense and lexical retrieval, graph context, metadata filtering, source attribution, and permission enforcement. Choose HydraDB when object-store-native graph storage and managed hybrid retrieval are priorities, or shortlist Neptune, GraphDB, ArangoDB, Memgraph, or FalkorDB for AWS alignment, RDF inference, an AQL surface, streaming ingestion, or GraphBLAS, respectively.

Best LLM wiki tools and databases for AI agents in 2026

M C — Mon, 14 Sep 2026 12:47:40 +0000

Engineering teams building AI agents quickly discover that context windows are not databases. When agents rely solely on short-term session memory or unstructured retrieval across raw documents, they can suffer from amnesia, hallucinated relationships, and context bloat. To act autonomously and reliably across sessions, agents need a durable knowledge system they can navigate, cite, and update.

This article separates three concepts. An LLM wiki is the durable knowledge system itself. A wiki tool such as Cognition's DeepWiki turns software repositories into browsable documentation and code-grounded Q&A. A database such as HydraDB provides durable storage and query infrastructure for teams building custom agent wikis. These layers can be combined, but they are not interchangeable.

For a controlled, low-concurrency prototype, a local directory of plain-text files that agents read and edit with file-system tools can be a low-infrastructure starting point. As agents execute tasks, they can synthesize findings, update state, and commit changes back to the text files.

The pressure to change this architecture arises when multiple agents attempt to write concurrently, when untyped file links fail to represent complex business logic, and when application security requires strict tenant boundaries.

The design question is twofold: which wiki workflow fits the user, and which persistence layer fits the workload's scale, concurrency, retrieval, and governance constraints.

Treating a wiki tool, a Markdown workflow, a managed memory service, and a graph database as interchangeable options leads to architectural mistakes. Teams should first identify which layer they are selecting, then evaluate it against the workload's constraints: concurrency, relationship traversal, provenance, temporal state, and access scope.

Key takeaways on LLM wiki tools and databases

Separate the wiki application from its persistence layer. Tools such as DeepWiki generate and expose a wiki, while databases such as HydraDB provide storage and query infrastructure beneath custom wiki applications.
Start an LLM wiki with Markdown and Git unless the workload proves it needs more infrastructure.
Move beyond files when concurrent agent writes, weak entity links, provenance gaps, or tenant access rules become operational blockers.
Choose a memory service when vendor-supplied personalization or conversation-memory behavior is required. Choose a graph database such as HydraDB when typed relationships and multi-hop traversal are load-bearing.
MCP exposes tools and resources to agents and defines optional transport-level authorization, but it does not define the storage model, domain-specific authorization policy, provenance model, or schema.

LLM wiki tools and databases comparison

Evaluating products across different layers of the context stack requires understanding their primary operational role.

Tool / category	Layer	Core strength	Choose when...
Markdown and Git	File-based wiki	Transparent, versioned plain-text knowledge	Simple prototypes or controlled single-agent wikis
Obsidian	Local-first knowledge app	Markdown UX, backlinks, visual navigation	Human-friendly local wiki workflows over Markdown files
Cognition DeepWiki	AI-generated code wiki	Repository documentation, architecture diagrams, source links, and code-grounded Q&A	Teams need a browsable, queryable wiki for software repositories
Notion	Workspace source	Collaborative docs, databases, and permissions	Teams already run operations in Notion
Confluence	Enterprise workspace source	Atlassian-native documentation and governance	Enterprise docs, Jira links, SSO, and auditability matter most
Letta	Stateful agent runtime	Runtime-managed long-term agent memory	The agent runtime must manage context and memory
Mem0	Memory service	Managed personalization and preference memory	User-level memory matters more than ontology control
Zep	Context/memory service	Temporal context graphs and assembled context	Managed context from chats, documents, and business data is the primary requirement
Graphiti	Temporal graph framework	Time-aware entity and relationship extraction	Temporal graph memory with a customer-operated backend
Cognee	Graph-backed memory layer	Ingestion plus relational, vector, and graph memory workflows	A configurable memory layer across pluggable stores
Vector/Search DBs	Retrieval/index layer	Semantic, lexical, and hybrid search	Chunk retrieval matters more than relationship modeling
HydraDB	Graph database + managed context platform	Typed graph and temporal/source-aware context	Multi-hop relationship context with customer-owned app logic
Neo4j	Graph database	Mature Cypher graph database ecosystem	Traditional graph workloads or existing Neo4j expertise

Wiki tools, memory services, frameworks, retrieval systems, and graph databases address different layers of the system. A product at one layer may use products from other layers underneath it.

Defining an LLM wiki

An LLM wiki is a durable, interlinked body of synthesized knowledge that AI agents can read, navigate, cite, and update over time. The wiki acts as a shared, persistent brain across different agent sessions and workflows.

Many associate the concept with Andrej Karpathy's public "llm-wiki" gist, which outlines an agent-maintained personal knowledge base. For production, keeping raw inputs distinct from synthesized claims makes source evidence easier to reprocess and audit.

Cognition's DeepWiki is a code-focused example of the wiki application layer. It indexes repositories and generates documentation, architecture diagrams, source links, and code-grounded Q&A. Its public MCP server lets agents read and query documentation for public repositories. DeepWiki is a wiki application, not a general-purpose database.

An LLM wiki differs fundamentally from providing an agent with a large context window. Context windows are ephemeral scratchpads. An LLM wiki is a persistent system of record.

An LLM wiki also differs from a simple retrieval-augmented generation (RAG) pipeline. A basic RAG implementation may retrieve source chunks through lexical or vector similarity, while a wiki adds durable, updateable knowledge organization. Explicit entity identity, typed relationships, canonical-state rules, and controlled writes become requirements only when the workload needs them.

Term	Primary purpose	Persistence model	Best-fit use case
LLM wiki	Durable knowledge agents can navigate and update	Interlinked pages, entities, or graph-backed records	Accumulated team, product, customer, or domain knowledge
Agent memory	Preserve useful state across sessions	Memory blocks, summaries, profiles, or extracted facts	Personalization and long-running agents
RAG	Ground answers in source documents	Chunks plus lexical/vector indexes	Q&A over document corpora
GraphRAG	Improve retrieval with entities and relationships	Graph-enriched chunks, entities, summaries, or edges	Multi-hop questions and relationship-heavy corpora

Markdown and Git as the LLM wiki baseline

Markdown and Git provide a credible low-infrastructure baseline for agent knowledge. Plain-text files are inspectable and portable, and models can consume them without decoding a proprietary document format. Git provides version history, rollback, and branch-and-merge workflows that can support reviewable agent edits.

For a solo prototype, this architecture avoids operating a dedicated database, but repository hosting, backups, CI, access control, indexing, review, and merge resolution still require operational work.

Mechanical breakpoints trigger migration from this baseline, not arbitrary page counts:

Concurrent writes: Overlapping edits to the same lines can create Git merge conflicts. Non-overlapping edits may merge cleanly even when they contradict semantically, so semantic review is still required before those changes enter the knowledge base.
Untyped links: Convention-based wiki-links and frontmatter do not enforce governed, typed edges between entities.
Entity duplication: Markdown and Git do not enforce canonical entity identity, so application conventions or validation must prevent and reconcile duplicate representations.
Weak provenance: Git tracks file-level changes, but enforcing claim-level source attribution requires rigid manual formatting.
Temporal ambiguity: Reverting to a previous commit reveals past file states. Answering queries about what was true during a specific historical window requires native valid-time and transaction-time modeling.
Coarse access boundaries: Git does not natively provide claim- or row-level authorization. Tenant-aware, user-specific retrieval policies require repository partitioning or an application authorization layer.

Every additional infrastructure layer should directly address one or more of these specific mechanical breakpoints.

Evaluation criteria for LLM wiki tools and databases

Evaluating persistence tools requires mapping them to the specific layer of the context stack they address. Flattening distinct architectural components into a single competitive matrix obscures their actual operational roles.

The flow of context generally follows this path: sources → ingestion/frameworks → durable knowledge store → retrieval indexes → API/MCP tools → agent context → review/update loop

Workspace tools function as primary human-centric sources of truth.
Vector and search systems function primarily as ranked-retrieval infrastructure. Whether they also serve as an authoritative store or preserve claim provenance depends on the exact product, schema, and surrounding application.
Frameworks orchestrate ingestion and retrieval, and many persist through configured stores. Production durability and scale depend on those stores, model calls, pipeline configuration, topology, and whether a managed edition operates the stack.
The Model Context Protocol (MCP) acts as delivery plumbing that exposes selected stores and tools to agents. It does not dictate the underlying persistence model, domain schema, or update workflow.

Tool / category	Concurrent writes	Typed relationships	Provenance + temporal state	Access scope	Ownership model
Markdown and Git	Partial (branch/merge workflows)	Partial (links/frontmatter)	Partial (commits help. Claim/as-of state is manual)	Partial (repo/file permissions)	Customer-owned
Obsidian	Partial (Sync merges same-file edits but does not provide live co-editing)	Partial (wiki-links)	Partial (manual notes, Sync history, or Git history)	Partial (vault/filesystem scope without fine-grained permissions within a shared Sync vault)	Customer-owned
Cognition DeepWiki	Service-managed. Database-level write semantics are not exposed	Partial (generated page hierarchy and source links, not a user-defined typed graph)	Partial (source-code links. Claim-level provenance and as-of state are not documented)	Public DeepWiki supports public GitHub repositories. Authenticated Devin supports public and private repositories	Service-owned
Notion	Supported (workspace collaboration)	Partial (database relations)	Partial (page history. Claim/as-of state must be modeled)	Supported (workspace layer. App enforces agent retrieval)	Workspace-owned
Confluence	Supported (enterprise collaboration)	Partial (hierarchy/Jira links)	Partial (document versions. Granular temporal state must be modeled)	Supported (workspace layer. App enforces agent retrieval)	Workspace-owned
Letta	Workflow-dependent (runtime-managed)	Partial (Git-backed MemFS files, not a typed graph model)	Partial (Git history. Source semantics are application-defined)	Deployment- and plan-dependent	Runtime-owned
Mem0	Partial (service-managed)	Partial (extracted memories)	Partial (depends on retained source metadata and update policy)	Partial (tenant/app design dependent)	Service-owned
Zep	Service-managed. Database-level write semantics are not exposed	Supported (custom entity and edge types)	Supported (temporal facts and episode associations)	Project isolation, Enterprise ABAC and team RBAC	Service-owned
Graphiti	Backend- and application-dependent	Supported	Supported (bitemporal facts and episode provenance)	Namespace, backend, and application-dependent	Framework/customer-owned
Cognee	Deployment- and backend-dependent	Partial (knowledge-graph schema depends on extraction/configuration)	Edition- and configuration-dependent	OSS dataset controls. Cloud dataset isolation and RBAC	OSS customer-owned. Cloud service-owned. BYOC shared
Vector/Search DBs	Product- and topology-specific	Product-specific. Weaviate supports directional cross-references	Product- and schema-specific	Product- and plan-specific. Filters are not equivalent to authorization	Managed or customer-operated
HydraDB	Partial (writes serialize per graph scope/cell. Cells can progress independently)	Supported (in the open core)	Partial (managed responses expose source/chunk IDs and edge-level temporal facts. Lineage policy is application-owned)	Partial (open-core exact-scope authorization. Managed databases isolate customers/environments and collections provide logical scope)	Managed service or licensed self-hosting. Customer owns application semantics
Neo4j	Supported	Supported	Partial (provenance and temporal semantics are schema/app responsibilities)	Supported	Customer-owned

Tools beyond the LLM wiki persistence layer

These products span orchestration, indexing, interaction, and persistence abstractions rather than one clean layer above storage.

LlamaIndex can persist through configured stores, LangGraph supports durable checkpoints and long-term stores, Google NotebookLM stores notebook sources and state, and Microsoft GraphRAG persists indexing outputs through configured storage providers. Claude Code and Cursor are coding interfaces. These products aren't interchangeable with a general-purpose transactional graph database. Each persistence contract requires separate evaluation.

File-based and local-first LLM wiki tools

Markdown and Git for file-based LLM wikis

Best for

Prototyping, controlled single-agent workflows, and workflows requiring transparent, inspectable files.

Why it fits

As the established baseline, keeping source content in plain text improves content portability and reduces early dependence on a proprietary knowledge-store format.

Watch out for

The mechanical breakpoints include textual merge conflicts, semantic contradictions that merge cleanly, and the manual enforcement required for entity canonicalization and claim-level citations.

Pricing model

Open-source tooling. Operational costs are limited to standard Git hosting and CI/CD infrastructure.

Obsidian for local-first LLM wikis

Best for

Personal knowledge management, local-first environments, and human-in-the-loop review of agent-generated Markdown files.

Why it fits

Obsidian provides a GUI over local Markdown files. Its visual graph navigation and bidirectional links support review of wiki structure while retaining Markdown as the underlying format, including for experiments with Karpathy's wiki pattern.

It fits workflows in which human reviewers actively curate, restructure, and validate agent-generated context.

Watch out for

Obsidian Headless Sync supports servers, CI, agents, and automated workflows in open beta. Shared vaults merge same-file edits but don't provide live co-editing or fine-grained collaborator permissions. Obsidian doesn't document database-style transactions or enforced typed edges.

Pricing model

As of September 5, 2026, Obsidian is free for personal and commercial use. An optional Commercial support license costs $50 per user per year. Sync and Publish are separate paid services.

AI-generated LLM wiki tools

Cognition DeepWiki for code-repository wikis

Best for

Engineering teams that need automatically generated, browsable documentation and Q&A for software repositories.

Why it fits

Cognition DeepWiki indexes repositories and generates documentation, architecture diagrams, source links, and codebase summaries. Ask Devin combines the generated wiki with code search to answer questions grounded in the repository.

The DeepWiki MCP server lets AI agents read wiki structures, retrieve wiki contents, and ask questions about public repositories.

Watch out for

DeepWiki is specialized for repository understanding. Its public service and MCP server cover public GitHub repositories. Private repository access and broader agent workflows use the authenticated Devin product surface.

DeepWiki supplies the wiki experience. It is not a general-purpose persistence database for custom agent knowledge systems.

Pricing model

Public DeepWiki is free for public GitHub repositories. Higher-effort wiki generation uses Devin ACUs, while private repository access requires a Devin account.

Workspace tools as LLM wiki sources.

Notion for collaborative LLM wiki sources

Best for

Organizations already relying on Notion as their primary operating system for internal documentation, project management, and lightweight relational databases.

Why it fits

Notion provides a polished collaborative environment for human operators while offering sufficient structure through block types and database relations for agents to navigate. Agents interact with Notion through official APIs or MCP servers, treating Notion as a governed, human-readable source of truth that balances unstructured prose with tabular data.

Watch out for

Notion's API documents an average limit of three requests per second per integration, plus payload limits. High-frequency integrations must choose between structured block traversal and the page-as-Markdown endpoint for supported reads. Page history is version-oriented, so claim-level valid-time semantics require separate modeling.

Hosted Notion MCP is limited by the connected user's permissions, while API integrations see only content explicitly shared with the integration. The application should enforce the effective access model for the credential it uses.

Pricing model

As of September 5, 2026, Notion offers Free, Plus, Business, and Enterprise plans. Paid plans are billed per member, with Enterprise pricing available through sales.

Confluence for enterprise LLM wiki sources

Best for

Enterprise engineering and product teams heavily invested in the Atlassian ecosystem, requiring strict IT governance, SSO, and compliance standards.

Why it fits

Confluence is an enterprise documentation platform with space-level permissions, detailed audit logs, and data residency options. It can serve as the canonical source for architecture decision records, security policies, and product requirements.

Native Jira integration can surface and link Jira data inside Confluence. The integration alone doesn't keep retrieved context semantically current.

Watch out for

The Confluence page-update API is page- and version-oriented. Applications that need claim-level writes must map those changes into page bodies and handle version conflicts, so teams should benchmark high-frequency agent writes against their page model.

High-frequency agent write loops are better routed through dedicated review workflows or separate databases rather than directly overwriting authoritative enterprise documentation.

Pricing model

As of September 5, 2026, Confluence offers Free, Standard, Premium, and Enterprise plans. Product audit logs and data residency begin at Standard. User-activity auditing is Enterprise, and SSO generally requires Atlassian Guard or Enterprise.

Stateful runtimes and memory services for AI agents

Letta for stateful agent memory

Best for

Engineering teams seeking a stateful-agent runtime that intrinsically manages long-term memory and context paging as part of the execution loop.

Why it fits

Letta gives each stateful agent a Git-backed MemFS repository. Files under system/ stay in the system prompt. Other files remain outside context until the agent reads them.

This approach fits systems in which the agent runtime owns memory lifecycle and orchestration behavior.

Watch out for

Adopting Letta requires committing to its specific runtime architecture. Letta doesn't fit architectures that separate orchestration logic from passive, durable storage.

Letta provides local, self-hosted, and Cloud deployments with different backup and access-control boundaries. Evaluate provenance, tenant isolation, and administrative controls against the selected deployment and plan.

Pricing model

Open-source core framework, supplemented by managed cloud services and usage-based billing options.

Mem0 for user memory and personalization

Best for

Applications primarily focused on capturing cross-session user personalization, conversational preferences, and recurring behavioral facts.

Why it fits

Mem0 is an opinionated service that automatically extracts, updates, and retrieves memories from conversational inputs. It reduces the engineering burden of designing custom extraction prompts and memory management policies.

Mem0 provides managed extraction and recall for assistants that need user profiles, preferences, and past instructions.

Watch out for

Mem0 Platform Graph Memory trades some modeling control for managed memory behavior. It links memories through co-occurring entities and does not expose typed, custom-labeled relationships or a separate graph payload. Mem0 Open Source instead lets teams configure and operate the self-hosted LLM, embedder, vector store, and reranker, so the control boundary differs by mode. Evaluate conflict resolution, decay, and forgetting behavior for the exact mode selected.

Pricing model

Open-source components alongside managed API consumption tiers and custom enterprise pricing.

Zep for assembled context memory

Best for

AI platforms where managed temporal context and retrieval across chats, documents, and business data are primary requirements.

Why it fits

Zep converts chats, business data, documents, and JSON into temporal Context Graphs, generates incremental thread summaries, and assembles context with semantic, full-text, and graph retrieval. Downstream conversational coherence and workload-specific latency still require application testing.

Watch out for

Zep supports custom entity and edge types, project isolation, Enterprise ABAC, and team RBAC, and episode-to-artifact provenance. It remains a managed agent-memory and context service rather than a general-purpose graph database, so evaluate its Context Graph APIs against database-level query, transaction, and deployment requirements.

Pricing model

Managed cloud service using credit-based consumption tiers. Graphiti is a related open-source temporal framework.

Graph and GraphRAG frameworks for LLM wikis

Graphiti for temporal graph memory

Best for

Engineering teams requiring a temporal knowledge-graph framework who are fully prepared to provision, manage, and scale the underlying backend database themselves.

Why it fits

Graphiti focuses on modeling time-aware entities and relationships. It handles the ingestion logic required to extract facts from unstructured episodes and merge them into a cohesive graph. The framework's temporal design ensures agents can differentiate between current active state and superseded historical facts.

Watch out for

Graphiti is an application framework. It currently supports Neo4j, FalkorDB, and Amazon Neptune. Storage durability, database concurrency, and availability depend on the selected backend and topology, while authorization and governance also depend on the surrounding application.

Graphiti links episodes to extracted nodes and relationships, providing episode-level provenance. Mapping those episode IDs to source-system citations and governance policies remains application work.

Pricing model

Open-source framework. Total cost of ownership is driven by backend database hosting, infrastructure operations, and LLM API consumption.

Cognee for graph-backed memory pipelines

Best for

Teams looking to implement configurable GraphRAG workflows without handwriting every individual ingestion, chunking, vectorization, and extraction pipeline.

Why it fits

Cognee orchestrates document parsing, embedding generation, entity extraction, graph construction, and retrieval. Its configuration model composes relational storage for documents, metadata, and system state, vector storage for embeddings and semantic search, and graph storage for entities and relationships. Its built-in pipelines can reduce how much ingestion, extraction, and retrieval orchestration the application must implement.

Watch out for

In self-hosted Cognee, retrieval quality and operating behavior depend on the configured models, pipelines, and relational, vector, and graph backends. Cognee Cloud separately manages compute, storage, pipeline execution, dataset isolation, and RBAC, so evaluate the exact Open Source, Cloud, or Enterprise/BYOC surface.

Pricing model

Cognee Open Source is Apache-2.0. As of September 5, 2026, Cognee Cloud includes a free tier and lists Standard processing at $2.50 per 1 million tokens plus $5 per month for each additional workspace. Enterprise/BYOC pricing is custom.

Retrieval and index tools for LLM wikis

Vector and search databases for LLM wiki retrieval

This category includes Pinecone, Qdrant, Weaviate, pgvector, Elasticsearch/OpenSearch, and Vespa.

Best for

Applications where the primary requirement is semantic, lexical, or hybrid retrieval across vast, relatively flat corpora of text chunks.

Why it fits

Vector databases excel at capturing semantic similarity, allowing agents to retrieve relevant information even when exact keywords are missing. BM25 ranks lexical matches for product names and policy terms. Exact identifiers should use term-level or ID queries when the selected product provides them.

Metadata filtering allows applications to constrain retrieval by tenant, document type, or source system.

Watch out for

These products center on ranked retrieval, but their data models vary. Weaviate supports directional cross-references, and pgvector retains PostgreSQL relations, joins, and ACID behavior. Evaluate relationship traversal, entity identity, and provenance product by product.

When relationships exist only as vector metadata, traversal and canonicalization move into application code and can become harder to maintain as the model grows.

Pricing model

Highly variable across the category, encompassing managed SaaS platforms, open-source self-hosted clusters, and standard PostgreSQL infrastructure costs.

Graph databases for LLM wikis

HydraDB for graph-native LLM wiki infrastructure

Best for

Engineering teams evaluating HydraDB as graph-database infrastructure when typed relationships and multi-hop traversal are central, with managed temporal and source-linked context available where those features are required.

Why it fits

HydraDB is an object-store-native graph database that maps pages to nodes and wiki-links to typed edges. S3-compatible object storage is the durable source of truth, while graph nodes and indexers keep disposable state in memory and on local SSD or NVMe. This design separates durable graph storage from compute and is intended to lower graph-storage cost. The architecture alone does not establish a universal scale, latency, or total-cost advantage.

HydraDB maintains a strict architectural boundary between layers:

Open core: Manages durable graph storage, exact-scope authorization, and traversal execution via JSON, streaming HTTPS APIs, and an OpenCypher subset over Bolt 5.1 through 5.4.
Managed platform: Handles asynchronous ingestion, hybrid retrieval that combines dense semantic and BM25 scores, exact metadata filtering before ranking, graph-context enrichment, separate databases for customer or environment isolation, and collections for logical scoping inside a database.
Customer application: Retains control over domain ontologies, agent prompts, authorization policies, and workflow orchestration.

On the managed platform, optional temporal reasoning can return current, as-of, range, or upcoming edge-level facts, and responses can carry source, chunk, entity, and relationship identifiers. Those identifiers support attribution but do not by themselves constitute complete lineage or an immutable audit trail.

Watch out for

HydraDB provides database infrastructure for teams that build the application logic orchestrating the agent workflow.

While HydraDB supports a practical OpenCypher subset, it is not a guaranteed drop-in replacement for every legacy Neo4j workload. Migration feasibility depends on exact query requirements. HydraDB is over-engineered for simple RAG pipelines lacking relational complexity.

Pricing model

As of September 5, 2026, HydraDB lists Ship as free, Surge at $25/month with up to 2 GB of graph storage and $0.50/GB/month overage, Scale at $399/month with up to 10 GB and $0.25/GB/month overage plus an option to self-host under license, and Enterprise at custom pricing for BYOC or fully self-hosted deployment.

Neo4j for Neo4j-native Cypher and graph workloads

Best for

Teams that need full Neo4j Cypher behavior, its procedures or Graph Data Science tooling, managed AuraDB, clustering, or compatibility with established Neo4j workloads.

Why it fits

Neo4j documents native nodes and relationships, property indexes, Cypher, Bolt, APOC, Graph Data Science, clustering, self-managed editions, and AuraDB. Its transactions are ACID-compliant. Default isolation is read-committed, with explicit locking available when stricter serialization is needed.

Vector indexes are available for nodes and relationships. These capabilities are relevant when Neo4j-specific query, procedure, analytics, deployment, or ecosystem behavior is decisive.

Watch out for

In Neo4j, claim-level provenance and business-valid-time semantics remain schema and application responsibilities even though Cypher supports temporal value types. Deployment cost depends on edition, topology, workload, and service model. No workload-equivalent evidence supports a general cost conclusion.

Pricing model

As of September 5, 2026, Neo4j lists AuraDB Free at $0, Professional at $65/GB/month with a 1 GB minimum, Business Critical at $146/GB/month with a 2 GB minimum, and Virtual Dedicated Cloud by quote. Self-managed Community Edition is available under GPLv3. Enterprise and Infinigraph use commercial terms.

Testing LLM wiki infrastructure before purchase

Selecting infrastructure based on marketing pages or single-metric benchmarks invites production failure. Teams evaluating persistence layers for an LLM wiki must validate the architecture against four specific operational tests.

Read-path test for LLM wiki retrieval

The evaluation should run a realistic query that exercises the retrieval signals and controls the workload actually needs. Candidates don't need to implement the same retrieval stack.

Example query: "What changed about Acme Corp's renewal risk since the last quarterly business review?"

The test should determine whether the end-to-end system can:

Resolve the string "Acme Corp" to a canonical entity ID.
Filter the retrieval scope to authorized CRM records, support tickets, and specific account owner notes.
Execute semantic search for "renewal risk" and lexical search for specific contract terms.
Traverse the graph to locate related incidents and decision records.
Apply a strict temporal filter to exclude data generated prior to the last review date.
Return the synthesized answer alongside exact source citations, all within the LLM's token budget.

Write-path test for agent updates

The write-path test should simulate high-concurrency contention by forcing two independent agents to update the exact same entity or factual claim simultaneously.

The end-to-end write path, including application logic, review policy, and storage, must demonstrate that it supports:

Submitting proposed state changes rather than unconditionally overwriting the canonical record.
Enforcing entity canonicalization to prevent creating duplicate records for the same concept.
Routing highly destructive or low-confidence changes to a human reviewer or deterministic policy engine.
Retaining complete merge history, ensuring any incorrect agent update can be rolled back cleanly.
Mapping strict claim-level provenance so the system explicitly records why it believes the new fact is true.

Access-scope test for secure agent retrieval

The end-to-end ingestion and retrieval path must preserve the intended source-system security boundaries. The connector, identity layer, application, query service, and store may enforce different parts of that policy.

Production systems must strictly handle:

Mirroring source-level permissions from external systems like Notion, Jira, and Slack.
Isolating customers or environments through documented top-level isolation boundaries, with namespaces or logical collections used only where their contract provides the required isolation.
Recording the ingestion, retrieval, and agent-write events required by the threat model, and verifying whether any component provides tamper-evident or immutable audit storage.
Redacting or isolating sensitive data, secrets, and regulated customer-confidential content.
Neutralizing prompt-injection attacks by strictly treating retrieved text as passive evidence, never as executable instruction.

MCP test for agent tool delivery

Teams should define the architectural role of the Model Context Protocol in the stack.

MCP standardizes host, client, and server interactions for negotiated capabilities including resources, prompts, and tools. An MCP server can expose operations that search, traverse relationships, fetch citations, or propose writes.

MCP does not define the underlying data schema, persistence semantics, provenance model, or update workflow. It defines optional transport-level authorization, but not the application's domain-specific access policy or agent orchestration logic.

Passing data through MCP does not transform an unstructured tool endpoint into an audited, transactional database.

Selecting an LLM wiki architecture

Selecting the correct foundation for an LLM wiki requires matching the technology to the workload's most severe operational constraint.

Choose Cognition DeepWiki if... The goal is to generate and query documentation for software repositories. DeepWiki supplies the wiki application, while broader custom knowledge systems still require teams to evaluate their persistence and data-model requirements separately.

Choose Markdown and Git if... The workflow is a prototype or a strictly controlled single-agent system, and transparent, portable files are the priority. Markdown and Git remain the baseline until a concrete requirement for coordinated writes, typed relationships, provenance, temporal state, or access scope requires more infrastructure.

Choose Obsidian if... Obsidian fits workflows that require a local-first, human-centric interface layered over Markdown files. It supports subject matter experts who visually navigate, curate, and review the knowledge agents produce.

Choose Notion or Confluence if... The knowledge base must serve human operational workflows first, and agent retrieval second. Default to Notion for flexible, collaborative team workspaces. Default to Confluence for strict enterprise documentation, Atlassian ecosystem alignment, and rigid IT governance.

Choose Letta, Mem0, or Zep if... Letta fits when its stateful-agent harness and Git-backed MemFS should own the execution loop and long-term agent memory. Mem0 Platform fits applications that require managed extraction and recall for user or application memory. Zep fits applications that require managed temporal Context Graphs and assembled context from chats and business data.

Choose Graphiti or Cognee if... Graphiti fits teams that require an open-source temporal knowledge-graph framework and will operate a supported graph backend. Cognee fits when its graph-backed memory lifecycle and exact Open Source, Cloud, or Enterprise/BYOC operating model match the requirements.

Choose vector/search databases if... Vector and search databases fit workloads in which the primary bottleneck is semantic, lexical, or hybrid retrieval over relatively flat records and the selected product's relationship, provenance, access-control, and temporal capabilities match the workload.

Choose HydraDB if... HydraDB fits workloads that need an object-store-native graph database for multi-hop traversal and, on the managed platform, edge-level temporal facts and source-linked context, while the application retains domain semantics, end-user authorization, and orchestration.

Choose Neo4j if... Neo4j fits workloads that depend on Neo4j-specific Cypher behavior, procedures, Graph Data Science, clustering, AuraDB, or established Neo4j operational tooling.

Frequently asked questions

What is an LLM wiki?

An LLM wiki is a persistent knowledge base that agents can read, update, cite, and navigate across sessions. It stores durable information and source references and may represent entities and relationships in files, databases, or graphs.

Should I start an LLM wiki with Markdown and Git?

Yes, for prototypes, single-person projects, and controlled single-agent workflows. Markdown and Git are transparent, portable, and easy for agents to read and edit.

When should I move beyond Markdown and Git for an LLM wiki?

Teams should move beyond Markdown and Git when they encounter concurrent writes, duplicate entities, weak provenance, untyped links, temporal ambiguity, or tenant-level access control.

Is an LLM wiki the same as RAG?

Not necessarily. A simple RAG pipeline retrieves source material to ground a response, while an LLM wiki emphasizes durable, updateable knowledge organization. A production system can combine both patterns.

When does an LLM wiki need a graph database?

Use a graph database when typed relationships and multi-hop traversal are load-bearing and a graph query/storage model is preferable to application-managed joins. Provenance and historical-state requirements are separate capabilities that can be implemented in more than one storage model.

Does MCP replace the need for a database?

No. MCP standardizes how hosts, clients, and servers exchange context and invoke capabilities and defines optional transport-level authorization. It does not define the database, domain schema, application-specific access policy, temporal model, or data-governance workflow.

Should I use a memory service or a graph database for agent context?

A memory service fits when its exact managed behavior, such as preference extraction, conversation continuity, or assembled context, matches the application. A graph database fits when typed relationships and multi-hop traversal justify a graph storage and query model.

How should teams choose between HydraDB and Neo4j?

HydraDB fits when its object-store-native architecture and practical OpenCypher subset, plus optional managed source-linked and temporal context, match the workload. Neo4j fits when the workload requires Neo4j-specific Cypher, procedures, GDS, clustering, AuraDB, or ecosystem compatibility. Teams should test actual query, transaction, procedure, and driver requirements before treating either system as a replacement for the other.

Conclusion: choosing LLM wiki infrastructure

Start with the simplest architecture that works, and move up the stack only when a specific requirement forces the change.

Use a wiki tool such as DeepWiki for repository documentation and Q&A, Markdown and Git for controlled agent-maintained knowledge, memory services for managed memory behavior, vector or search systems for retrieval-heavy workloads, and graph databases when typed relationships and multi-hop traversal become load-bearing.

Before buying, test the architecture against a representative ontology and workload. Evaluate HydraDB when governed, durable relationships are the capability your current stack cannot provide.

Teams evaluating these workloads can book a demo with the HydraDB team.

Best Postgres hosting providers for AI agents in 2026

M C — Fri, 21 Aug 2026 18:41:18 +0000

Picking a Postgres host for an AI agent isn't like picking one for a normal app. High-volume agents can write constantly. Checkpoints, memory, tool calls, and retrieved context all land on the same database that may have to handle traces, evals, and analytics later. Put both jobs on one primary at sufficient scale, and they start competing for CPU and disk.

At modest scale, keeping both workloads in Postgres is a valid place to start. When analytical scans begin to affect transaction latency, the fix is decoupling the two. Some providers do this with CDC into a separate analytical engine. Others use read replicas or serverless isolation. Either way, agent writes shouldn't have to wait on analytics once that contention becomes measurable.

We compare the major Postgres providers on transactional speed, retrieval quality, and how well each one keeps that separation when you need it.

TL;DR

Many AI agents can begin with Postgres for state, memory, checkpoints, tool activity, retrieval, and light reporting. Add a separate OLAP path for telemetry, evaluations, and analytics when scans create persistent CPU, I/O, cache, or p99 contention.
We built ClickHouse Managed Postgres for production applications that need high-performance transactional Postgres and an integrated route to ClickHouse Cloud. It runs Postgres on compute-colocated local NVMe. You configure ClickPipes to replicate selected data into ClickHouse Cloud, where offloaded analytical queries run on separate compute.
pg_clickhouse lets you query imported ClickHouse Cloud tables from Postgres. Supported work is pushed down to ClickHouse; unsupported or mixed work can still execute in Postgres.
Choose a narrower alternative when scale-to-zero for smaller workloads, native cloud integration, time-series features at single-node write scale, or a required extension matters more than an integrated OLTP-to-OLAP path. Whatever you pick, test vector-index memory, p99 latency, connection behavior, write throughput, durability, and analytical isolation on your own workload.

Why production AI applications may need both OLTP and OLAP

AI agents are often chatty database clients. A single run can read conversation history, retrieve context, update a checkpoint, record tool calls, and append new state. Those operations need Postgres transactions and predictable p99 latency.

The same run can produce traces, token usage, tool outcomes, evaluation results, latency distributions, errors, and product events. Teams scan and aggregate that data across thousands or millions of runs, and those queries are much heavier than the point reads and writes on the live agent path. ClickHouse's engineering guidance for managed Postgres in AI and real-time applications walks through how agent traffic, vector lookups, continuous telemetry, and analytical scans can put pressure on I/O, memory, WAL processing, and concurrency at once.

If you run both workloads on one Postgres primary, they can compete for CPU, I/O, and buffer cache. Read replicas can move reporting queries off the primary and provide useful compute isolation at moderate scale, but they're still row-oriented Postgres instances. They don't give you the execution model of a dedicated analytical engine.

That doesn't make a separate analytical engine mandatory on day one. Stateless agents, applications that store traces elsewhere, and modest Postgres-only systems are all valid. Isolate analytics when scans push transactions beyond their latency target, reporting misses its own SLA, long analytical transactions interfere with vacuum, or you have to overprovision Postgres mainly for aggregations.

At that breakpoint, an application needs high-performance OLTP, isolated OLAP, and a managed path connecting the two. That's the architecture we built ClickHouse Managed Postgres to support. Postgres stays the transactional system of record, ClickHouse Cloud handles the analytical workloads, and configured ClickPipes plus pg_clickhouse connect them without you having to build the replication system yourself.

Evaluation criteria for Postgres hosting providers for AI agents

This comparison asks five questions about each provider. The benchmark numbers cited later apply only to the configurations tested, not to every plan or region a provider offers.

Can it keep agent state fast? Agent workloads mix append-only conversation and tool events with mutable checkpoints, summaries, and memory records. Look at storage architecture, write throughput, vacuum behavior, high availability, and transactional latency.
Can it retrieve the right context quickly? Check pgvector, alternative vector indexes, hybrid keyword and vector search, index memory, and disk access. Extension availability is only the starting point.
What happens when traffic spikes? Connection pooling, transaction multiplexing, cold starts, autoscaling, and storage latency all shape p99 latency under chatty agent traffic.
Where do analytical queries run? Database monitoring is not the same as analytics over traces, token spend, evaluations, latency distributions, and product behavior. Ask whether those scans run on the primary, on row-oriented replica compute, or on a dedicated analytical engine. Also check freshness and source-side replication overhead.
Can agents operate the platform safely? Check APIs, Infrastructure as Code, MCP support, agent-operable CLIs, branching, migrations, and how much infrastructure you must assemble to connect the transactional and analytical paths.

Why pgvector support alone doesn’t determine retrieval performance

pgvector support is table stakes. It tells you that a provider can store embeddings and run exact or approximate nearest-neighbor queries. But it doesn’t tell you whether an index will meet your recall, latency, ingestion, or cost requirements.

HNSW trades more memory and longer build times for a stronger speed-recall balance. IVFFlat builds faster and uses less memory, but needs training data and workload-specific tuning of lists and probes. Vector dimensions, filters, update frequency, index build time, available RAM, and storage latency all change the result.

Size retrieval against your own embedding model, dataset, filters, update rate, recall target, and latency objective.

Best Postgres hosts for AI agents at a glance

Provider	Best fit	Transactional and latency model	Retrieval and agent tooling	Analytics path	Main tradeoff
ClickHouse Managed Postgres	Sustained production AI applications needing high-performance OLTP and dedicated OLAP	Compute-colocated local NVMe and bundled PgBouncer	`pgvector`, `vchord`, `clickhousectl`, Terraform, and ClickHouse Agents	User-configured ClickPipes to ClickHouse Cloud plus supported `pg_clickhouse` pushdown	Continuously provisioned compute; analytics needs a separate ClickHouse Cloud service and setup
Neon	Smaller-scale or latency-tolerant developer workflows	Separated compute and storage with scale-to-zero	`pgvector` and copy-on-write branch automation	Row-oriented read replicas or an external analytical system	Cold starts and cache state affect the first query after suspension
Tiger Cloud	Time-series-heavy workloads at single-node write scale	Postgres with TimescaleDB hypertables, continuous aggregates, and columnstore	StreamingDiskANN, BM25, and CLI-based MCP	On-service analytics or row-oriented read replicas	Multi-node support was deprecated; on-service work shares the Postgres resource envelope
Amazon RDS	AWS-standardized teams	EBS-backed storage with RDS Proxy	`pgvector` and the AWS automation ecosystem	Read replicas or zero-ETL to Redshift for eligible configurations	Network storage latency and session pinning can reduce proxy reuse
Amazon Aurora	AWS-native distributed storage and Serverless v2	Distributed storage with conditional auto-pause and eligible local-NVMe caching	`pgvector` and the AWS automation ecosystem	Read replicas or eligible zero-ETL integrations with Redshift and SageMaker Lakehouse	Resume latency and topology restrictions affect auto-pause
Google Cloud SQL	GCP-standardized operations	Managed PostgreSQL with Enterprise Plus pooling and read pools	`pgvector`, Vertex AI integration, and remote MCP	Read pools, BigQuery federation, or Datastream CDC	BigQuery federation still loads the source; dedicated columnar analytics needs another system
AlloyDB	ScaNN vector retrieval and in-engine columnar acceleration on GCP	Postgres-compatible engine with columnar acceleration	ScaNN, hybrid search, Preview adaptive filtering, and remote MCP	Columnar analytics on the primary or a read pool	Write-heavy workloads can invalidate columnar blocks; read pools share cluster storage
Azure Database for PostgreSQL	Microsoft-standardized environments	Flexible Server with built-in PgBouncer	`pgvector` and Azure automation tools	Read replicas or selected-table Fabric Mirroring to OneLake	PgBouncer is single-threaded; Elastic Clusters can't currently scale in
Crunchy Bridge	A required extension or setting unavailable from ClickHouse Managed Postgres	Managed PostgreSQL with 90 extensions and table-level controls	`pgvector` and a Terraform provider	Read replicas or an AWS-only Crunchy Data Warehouse service	AWS plans use network-attached `gp3`; the warehouse is separate
Aiven	Teams needing several managed open-source infrastructure projects from one vendor	Cloud-, region-, and plan-dependent infrastructure with PgBouncer on eligible plans	`pgvector`, Terraform, and MCP	Additional managed services or an externally assembled CDC path	Portfolio breadth adds architectural and operational complexity
DigitalOcean	Smaller deployments prioritizing simple operations	Managed PostgreSQL with PgBouncer	`pgvector`, API, Terraform, and lifecycle-focused MCP	Read-only nodes or an external analytical service	No superuser and plan-dependent resource, extension, and connection ceilings

1. Why ClickHouse Managed Postgres is the best overall host for AI agents

We built ClickHouse Managed Postgres for production applications that need both data paths in one managed architecture. Transactions run on Postgres backed by compute-colocated local NVMe. Configured ClickPipes replicate selected application data into ClickHouse Cloud, where analytical scans run on separate OLAP compute. pg_clickhouse keeps supported analytical query access available through the Postgres interface.

ClickHouse packages the Postgres service, managed CDC, OLAP engine, and Postgres-facing query layer in the ClickHouse Cloud experience. You still select or create the destination ClickHouse Cloud service, configure a ClickPipe and its tables, and set up pg_clickhouse foreign tables. The integration is managed, not automatic.

Best for

ClickHouse Managed Postgres is our default choice for sustained production agent backends where chatty transactional traffic and telemetry analytics are both core requirements, or where measured analytical contention shows that Postgres needs a dedicated OLAP path.

How it works

ClickHouse Managed Postgres runs PostgreSQL on compute-colocated local NVMe and integrates it directly with ClickHouse Cloud. Postgres handles transactions, ClickHouse Cloud handles offloaded analytical scans, and configured ClickPipes plus pg_clickhouse connect the two.

Clients query imported foreign tables through pg_clickhouse. Only supported operations are pushed down. The current documentation reports full pushdown for 14 of 22 TPC-H queries; unsupported or mixed work may execute partly in Postgres or move rows there. Use EXPLAIN (VERBOSE) to check the plan for your own queries.

What stands out

Vector retrieval: Supports more than 90 extensions including pgvector, specifically pgvector (0.8.2), vchord, vchord_bm25, and pg_tokenizer. NVMe accelerates disk reads, but vector index memory and storage still need explicit sizing.
Transactional state: Postgres runs on compute-colocated local NVMe, avoiding network-storage round trips for write-heavy event appends and mutable checkpoints.
High availability: Three HA modes expose the latency and durability tradeoff. Zero standbys maximizes performance without a streaming standby. One standby is asynchronous and can lose recent acknowledged commits during failover. Two standbys use synchronous replication and add a cross-Availability-Zone acknowledgement to commits.
Concurrency and latency: Bundled PgBouncer runs in transaction-pooling mode, letting many short-lived clients share a smaller pool of backend connections. Apps that need server-side prepared statements can connect directly.
Operational integration: clickhousectl gives coding agents machine-readable workflows for provisioning and recovery operations. ClickHouse Agents adds read-only-by-default tools for querying Postgres, inspecting service metrics and slow-query patterns, and analyzing Postgres and ClickHouse Cloud together. Control-plane automation also includes OpenAPI and an alpha Terraform provider.
OLAP and workload isolation: ClickPipes CDC replicates selected application data into ClickHouse Cloud. The default pull interval is 60 seconds; lower values are configurable, with values above 10 seconds recommended. End-to-end lag also depends on push time, backlog, and long-running transactions. Offloaded scans run outside the Postgres transactional compute, but CDC still uses source-side WAL, logical-decoding, snapshot, and network resources. Query Insights and Prometheus-compatible endpoints expose database metrics.

Where it falls short

ClickHouse Managed Postgres uses continuously provisioned compute rather than an idle-suspension model. It doesn't bundle application services such as auth or object storage. The analytical path also needs a separately configured and billed ClickHouse Cloud service. It isn't the right fit when scale-to-zero economics for an intermittent workload or a bundled application backend is the primary requirement.

2. Neon Postgres for AI agents

Best for

Smaller-scale or latency-tolerant applications that need copy-on-write branching, API-driven provisioning, and serverless developer workflows rather than sustained production scale.

How it works

Now a part of Databricks, Neon separates Postgres storage from compute. Copy-on-write branching creates isolated clones in seconds, and idle compute can suspend automatically. Compute nodes maintain a local page cache, while WAL durability uses a separate Safekeeper path.

What stands out

Vector retrieval: Supports pgvector for exact and approximate nearest-neighbor search. Index performance and memory requirements follow standard pgvector behavior.
Transactional state: Branching simplifies state sandboxing during development. The local page cache affects operations that need database pages, while writes use Neon's separate WAL durability path.
Concurrency and latency: Neon can suspend idle computes after five minutes by default and documents wake-up within a few hundred milliseconds. Exact first-query latency depends on your workload and cache state.
Operational integration: APIs automate provisioning and branch creation, so you can spin up isolated environments quickly.
OLAP and workload isolation: Read replicas can move moderate reporting away from the writer, but remain row-oriented Postgres. Larger telemetry analytics need an external analytical system.

Where it falls short

Suspend economics don't apply cleanly to steady production agent traffic. Cold-start latency directly penalizes the first tool call. If the application can't accept that delay, disable scale-to-zero. Benchmark sustained throughput and p99 latency before using it beyond smaller-scale or latency-tolerant workloads.

3. Tiger Cloud Postgres for AI agents

Best for

Time-series-heavy agent data that benefits from hypertables, retention policies, continuous aggregates, and columnar storage, and that fits a single-node Postgres writer.

How it works

Tiger Cloud combines TimescaleDB hypertables, continuous aggregates, a columnstore, pgvectorscale, and pg_textsearch. These features support time-series agent events and hybrid retrieval inside Postgres.

What stands out

Vector retrieval: Uses pgvectorscale with StreamingDiskANN and pg_textsearch with BM25 for hybrid retrieval.
Transactional state: Hypertables partition time-series records by time, while retention policies and continuous aggregates reduce manual work for rollups and historical data.
Concurrency and latency: Read replicas can be sized independently to isolate reporting query compute from the writer.
Operational integration: Tiger MCP ships inside the Tiger CLI. OAuth covers the control plane, while SQL access also depends on stored database credentials and the selected Postgres role. Read-only mode must be enabled.
OLAP and workload isolation: On-service Hypercore and continuous-aggregate work shares the Postgres resource envelope. Read replicas can isolate analytical query compute, but they aren't a dedicated scale-out OLAP engine. An external Iceberg connector is also available.

Where it falls short

TimescaleDB 2.13 was the last release with multi-node support, so evaluate Tiger Cloud around a vertically scaled single writer rather than horizontal write scaling. On-primary queries and continuous-aggregate maintenance still share resources with agent transactions. pg_textsearch compacts segments synchronously, creating a concrete tradeoff for sustained write-heavy BM25 workloads.

4. Amazon RDS for PostgreSQL for AI agents

Best for

AWS-standardized teams wanting conventional managed Postgres with IAM, VPC, AWS operational controls, and Bedrock-adjacent architecture.

How it works

Amazon RDS runs PostgreSQL on EBS-backed network storage, making provisioned IOPS and storage latency central to performance.

What stands out

Vector retrieval: Supports pgvector, including HNSW indexing. In an AWS benchmark, instance type and pgvector version affected build and query times for the tested workloads.
Transactional state: RDS handles standard Postgres transactions. Frequent checkpoint updates create dead row versions and may require autovacuum tuning; lower fillfactor can help HOT updates where appropriate.
Concurrency and latency: Relies on network-attached storage, meaning per-I/O behavior heavily influences latency under chatty traffic. RDS Proxy multiplexes transactions to handle connection volume.
Operational integration: Supported by the established AWS API and Terraform ecosystem.
OLAP and workload isolation: CloudWatch Database Insights covers database operability. Read replicas provide row-oriented query isolation, while eligible RDS zero-ETL integrations replicate PostgreSQL data to Redshift for dedicated analytics.

Where it falls short

Network-attached storage paths introduce latency that compounds across chatty agent steps. RDS Proxy can pin sessions when applications use SQL PREPARE, temporary objects, or documented session state. Pinning reduces backend connection reuse rather than removing every proxy benefit. Redshift adds a separate service with version, region, and configuration requirements.

5. Amazon Aurora PostgreSQL for AI agent backends

Best for

AWS-standardized teams that need Aurora's distributed storage, Serverless v2 autoscaling, and eligible Optimized Reads for OLTP, with read replicas or a separate AWS service for heavier analytics.

How it works

Aurora is a PostgreSQL-compatible service built on a distributed, log-structured storage layer. Aurora Serverless v2 manages burst scaling. Optimized Reads can use local NVMe on supported instance families and engine versions. Tiered caching depends on Aurora I/O-Optimized; Aurora Standard uses local storage for temporary objects.

What stands out

Vector retrieval: Supports pgvector, while eligible Optimized Reads configurations cache data locally for generative AI workloads.
Transactional state: Aurora's managed durability layer handles append-only events and mutable summaries.
Concurrency and latency: Distributed storage behaves differently than conventional block storage. Eligible Serverless v2 configurations can set MinCapacity=0 and auto-pause when no activity blocks it.
Operational integration: Shares the AWS API and Infrastructure-as-Code control plane.
OLAP and workload isolation: Read replicas provide row-oriented query isolation. Eligible Aurora PostgreSQL zero-ETL integrations replicate data to Redshift or SageMaker Lakehouse. Redshift is the dedicated warehouse option, not a technical requirement for every analytical query.

Where it falls short

Aurora remains row-oriented. Auto-pause requires supported versions and regions, db.serverless, MinCapacity=0, and no blocking activity. An attached RDS Proxy prevents associated instances from pausing, while logical replication, zero-ETL, and global-database topology can prevent particular writers or promotion tiers from pausing. Aurora Serverless v2 typically resumes in approximately 15 seconds, but resume can take 30 seconds or longer after more than 24 hours paused. That delay can break the latency budget of a user-facing first tool call.

6. Google Cloud SQL for PostgreSQL for AI agents

Best for

Teams standardized on Google Cloud that want conventional managed Postgres rather than an AI-tuned Postgres-compatible engine.

How it works

Cloud SQL is Google Cloud's conventional managed PostgreSQL service, while AlloyDB is the Postgres-compatible alternative with ScaNN vector and columnar acceleration. Cloud SQL Enterprise Plus adds Managed Connection Pooling and read pools.

What stands out

Vector retrieval: Supports pgvector using HNSW configurations and includes google_ml_integration for Vertex AI embeddings.
Transactional state: Standard Postgres writes and updates handle agent event logs and checkpoints.
Concurrency and latency: Depends on the selected storage path, edition, caching, and connection limits you configure for the instance.
Operational integration: Accessible through the Google Cloud API and Terraform providers. Google provides a Database Insights MCP server for metrics and a separate Cloud SQL remote MCP server that can create, manage, and query resources.
OLAP and workload isolation: Enterprise Plus read pools offload read traffic and moderate analytics from the primary. BigQuery federation queries Cloud SQL directly, so it doesn't isolate the source workload. Datastream can stream changes into a separate analytical system.

Where it falls short

Cloud SQL lacks the ScaNN index and in-engine columnar acceleration found in AlloyDB, though it still supports HNSW, pgvector optimizations, and edition-specific caching. Read pools provide row-oriented compute isolation. If you need a dedicated columnar path, you still have to assemble and operate a separate analytical destination.

7. AlloyDB for PostgreSQL for AI agents

Best for

Google Cloud teams that want ScaNN vector retrieval and in-engine columnar acceleration without adding a separate analytical engine.

How it works

AlloyDB is a PostgreSQL-compatible engine featuring in-engine columnar acceleration and advanced Google search technologies, distinguishing it from standard Cloud SQL.

What stands out

Vector retrieval: Supports pgvector-compatible vector operations, hybrid text and vector search, and Google's ScaNN index. ScaNN uses a tree-based quantization index with a smaller memory footprint. Adaptive filtering for filtered vector search is a separate Preview feature.
Transactional state: Processes transactional agent checkpoints through a PostgreSQL-compatible interface and managed durability layer.
Concurrency and latency: Designed to accelerate complex analytical queries concurrently with your transactional traffic.
Operational integration: Managed through the GCP control plane, automation tools, and a first-party remote MCP server.
OLAP and workload isolation: The columnar engine can run on the primary or on a read pool. A read pool isolates analytical compute from the primary, while sharing the cluster's distributed storage and replication path.

Where it falls short

Frequent updates invalidate affected columnar content until it is refreshed, which can reduce acceleration for write-heavy telemetry. AlloyDB keeps analytics inside the AlloyDB estate, so if you need to combine that data with application events, logs, and evaluation data from elsewhere, you're working within GCP's ecosystem rather than a separate dedicated OLAP engine.

8. Azure Database for PostgreSQL for AI agents

Best for

Organizations standardized on Azure that need managed PostgreSQL for agent transactions and light operational reporting, with Fabric as a separate analytics path.

How it works

Azure Database for PostgreSQL Flexible Server is the standard managed service. Elastic Clusters add Citus-based horizontal sharding when you need to scale out.

What stands out

Vector retrieval: Supports pgvector for embedding storage and nearest-neighbor execution.
Transactional state: Processes agent events and memory checkpoints with standard Azure operational durability.
Concurrency and latency: Uses a built-in PgBouncer implementation with a default max_client_conn of 5,000 and a configurable range of 1 to 50,000. Usable concurrency depends on compute and the single-threaded pooler.
Operational integration: Integrated tightly with Azure APIs, Terraform, and Bicep.
OLAP and workload isolation: Query Store and wait sampling feed Query Performance Insight, but are disabled by default. Fabric Mirroring copies selected eligible tables into OneLake in near-real-time batches and exposes a Fabric SQL analytics endpoint.

Where it falls short

Flexible Server remains row-oriented. Fabric Mirroring has table and scope limits and no fixed end-to-end latency SLA. The built-in PgBouncer is single-threaded. Elastic Clusters can scale out to 20 nodes through self-service tooling, but currently can't scale in and don't support TimescaleDB. This limits operational flexibility for time-series telemetry.

9. Crunchy Bridge Postgres for AI agents

Best for

Teams that require a PostgreSQL extension or setting that ClickHouse Managed Postgres doesn't provide.

How it works

Crunchy Bridge runs managed Postgres with 90 extensions plus supported procedural languages. Crunchy Data Warehouse provides a separate AWS-only analytical target that combines Postgres, a vectorized analytical engine, and Iceberg support.

What stands out

Vector retrieval: pgvector is available alongside standard relational querying for hybrid search designs.
Extension access: The catalog includes Citus, TimescaleDB, PostGIS, foreign data wrappers, procedural languages, and other options that can justify choosing it for a specific requirement.
Transactional state: Exposes table-level autovacuum controls and a documented subset of server settings for workload-specific tuning.
Concurrency and latency: Standard AWS plans use gp3 network-attached storage, so don't treat Crunchy Bridge as a local-NVMe service.
Operational integration: A Terraform provider handles infrastructure-as-code deployments.
OLAP and workload isolation: Crunchy Data Warehouse isolates analytical telemetry queries from the transactional agent path. It supports heap and Iceberg tables, object storage, and local NVMe caching in the warehouse service.

Where it falls short

Generic PostgreSQL behavior and pgvector aren't reasons to choose Crunchy Bridge over ClickHouse Managed Postgres. The differentiator has to be an extension or setting your workload actually requires. Crunchy Data Warehouse is available only on AWS and runs as a separate service. Managed logical replication applies changes in 30-second batches, with typical end-to-end lag below 60 seconds. Replication also adds source-side WAL and replication work.

10. Aiven for PostgreSQL for AI agents

Best for

Teams that want one vendor for a broad portfolio of managed open-source infrastructure, such as PostgreSQL, Kafka, Flink, OpenSearch, ClickHouse, Valkey, and MySQL.

How it works

Aiven deploys and manages these services across major cloud providers. It offers a consistent control plane, but each database, stream processor, search service, and integration remains a separate component that your team has to size, secure, monitor, and pay for.

What stands out

Portfolio breadth: Teams can procure several open-source data services from one provider.
Vector retrieval: Supports pgvector for exact and approximate nearest-neighbor indexes.
Transactional state: Standard managed Postgres handles state appends and mutable checkpoints.
Concurrency and latency: Managed PgBouncer is available on eligible Startup plans and above. Infrastructure and storage choices vary by cloud, region, and plan.
Operational integration: Terraform handles provisioning, while Aiven's MCP server can run SQL and retrieve database metrics and logs. Read-only mode is opt-in.
OLAP and workload isolation: You can combine Aiven services into an analytical path, but your team owns the cross-service design and operation.

Where it falls short

The only strong reason to choose Aiven here is that you need several managed open-source projects from one vendor and accept the resulting complexity. Your team still owns integration, networking, access control, recovery design, and cost management across those services. Plans, infrastructure, and storage options also vary by cloud and region, so benchmark the exact configuration.

11. DigitalOcean Managed PostgreSQL for AI agents

Best for

Smaller production agent deployments that value a simple operational surface alongside DigitalOcean's AI-oriented platform and inference tooling.

How it works

DigitalOcean integrates managed Postgres into its standard control plane, and clusters support up to three nodes.

What stands out

Vector retrieval: Supports pgvector. HNSW index size remains bounded by the memory available on the selected plan.
Transactional state: Standard managed Postgres handles modest agent-state workloads.
Concurrency and latency: Employs PgBouncer. A cluster supports up to 21 PgBouncer pools and about 1,000 pooled clients, while direct backend connection limits are separate and plan-dependent.
Operational integration: Accessible through the DigitalOcean API, Terraform, and an MCP server for database lifecycle operations.
Controls and monitoring: Exposes autovacuum, memory, WAL, worker, logging, and PgBouncer settings. It also provides Postgres-specific metrics and a Prometheus endpoint.

Where it falls short

DigitalOcean doesn't provide superuser access. Extension, compute, memory, and connection ceilings limit headroom on larger workloads. Native alerting on PostgreSQL-specific metrics isn't available. If telemetry analytics outgrow the primary or read-only nodes, you need an analytical service from another provider.

Performance and workload separation for AI agent Postgres hosting

Agent calls stack latency. Serial database calls add latency to the step, while fanned-out calls increase the chance that one tail event determines when the step finishes. A storage delay, a connection queue, or one analytical scan can slow the entire user-facing run.

How storage architecture affects Postgres concurrency and p99 latency

For I/O-bound Postgres workloads, storage latency and provisioned IOPS can dominate throughput and tail latency. Compute-colocated local NVMe removes the network-storage hop, while network-attached storage offers different durability and independent-scaling characteristics. Local-NVMe results also depend on the selected standby and replication mode.

ClickHouse publishes PostgresBench, a vendor-run pgbench comparison using a TPC-B-like workload. In the pinned repository snapshot, the approximately 500 GB tests used 256 clients, provider-default settings, and high availability disabled. Most services had 64 GB of memory, but Aurora used 128 GB because AWS didn't offer the targeted 1:4 CPU-to-memory ratio. Pricing wasn't normalized.

Tested service	vCPUs	Memory	Three-run arithmetic mean
ClickHouse Managed Postgres	16	64 GB	26,104.81 TPS
Crunchy Bridge	16	64 GB	10,953.71 TPS
Amazon Aurora I/O-Optimized	16	128 GB	11,011.36 TPS
Neon	16	64 GB	7,692.91 TPS
Amazon RDS for PostgreSQL	16	64 GB	4,727.11 TPS

The interactive leaderboard displays the best run; this table uses the three-run arithmetic mean. The services use different storage and durability architectures, and Aurora had twice the memory. Treat the results as one vendor-authored observation about this configuration and workload, not as proof of an overall provider ranking.

At 4 vCPUs and 16 GB, the difference mostly disappeared in the three-run means. Crunchy Bridge measured 6,320.00 TPS, and ClickHouse Managed Postgres measured 6,012.88 TPS. Reproduce the test with your production schema, transaction mix, connection count, durability mode, and region.

How workload separation protects AI agent telemetry performance

Agent telemetry analytics aggregate the same data that the runtime is actively writing. On a single Postgres primary, these scans consume CPU, I/O, and buffer cache needed by live agents.

Read replicas and read pools can isolate query compute for moderate reporting, even though they remain row-oriented and share storage or replication paths with the writer. Federation is different: it can simplify access while still sending query work to the source. CDC copies data to dedicated analytical compute, where heavy scans run separately, but the source still performs logical decoding, retains WAL, and sends changes.

AWS offers zero-ETL integrations with Redshift, Azure offers Fabric Mirroring, GCP offers Datastream, and Crunchy Bridge replicates into a separate warehouse. BigQuery federation queries Cloud SQL directly and doesn't isolate source load. AlloyDB can run its columnar engine on a read pool, while Tiger Cloud can use read replicas to isolate query compute.

ClickHouse Managed Postgres follows the principle of moving analytics off the primary. Configured ClickPipes replicate selected Postgres data into ClickHouse Cloud with eventual consistency. pg_clickhouse pushes supported work against imported foreign tables into ClickHouse Cloud while preserving the Postgres interface. Offloaded scans don't consume the Postgres primary's query compute, but CDC and any local or non-pushed work still affect Postgres.

Freshness needs, replication overhead, and isolation depth vary across all of these approaches, so run a proof of concept on your own data and workload before making a provider decision.

How to choose Postgres providers for AI agents

ClickHouse Managed Postgres is the best overall choice for sustained production AI applications that need fast transactional Postgres and dedicated analytics. Start with Postgres alone if it meets both the transactional and reporting targets. Choose a narrower platform when scale-to-zero for smaller workloads, provider-native integration, time-series features, or a required extension is the deciding requirement.

Dominant constraint	Deciding criterion	Shortlist	Why
Retrieval volume against available memory	Vector retrieval	ClickHouse Managed Postgres, Tiger Cloud, AlloyDB, Crunchy Bridge	Focus on your vector dataset, dimensionality, filtering patterns, recall target, update behavior, and index-memory boundaries. AlloyDB adds ScaNN, while Tiger Cloud adds StreamingDiskANN. Choose Crunchy only if a required extension or setting is unavailable from ClickHouse Managed Postgres.
Concurrent throughput and p99 under chatty traffic	Concurrency, latency, and burst behavior	ClickHouse Managed Postgres, RDS, Aurora	Local NVMe removes a network-storage hop, while pooling reduces backend connection pressure. RDS and Aurora fit teams that prioritize AWS-native operations. Test each durability topology.
Time-series-heavy agent state at single-node write scale	Time-series behavior	Tiger Cloud	Hypertables, continuous aggregates, retention, and columnar storage are the decision trigger. Validate vertical writer capacity and maintenance overhead.
Connection storms at peak against idle troughs	Concurrency, latency, and burst behavior	Neon, Aurora Serverless v2, ClickHouse Managed Postgres	Neon fits smaller-scale or latency-tolerant idle workloads. Eligible Aurora configurations optimize idle economics. ClickHouse Managed Postgres keeps the transactional path warm for sustained traffic.
Automation and agent-operability for a small team	Operational integration and agent tooling	ClickHouse Managed Postgres, Tiger Cloud, Neon	ClickHouse combines machine-readable provisioning with read-only-by-default Postgres and cross-engine analysis. Tiger exposes service and SQL tools through MCP, while Neon emphasizes API-driven branches.
Analytical queries over telemetry contending with the agent path	OLAP and workload isolation	ClickHouse Managed Postgres, AlloyDB, Crunchy Bridge	ClickHouse moves selected Postgres data into a dedicated OLAP engine. AlloyDB can isolate columnar compute on a read pool. Crunchy Bridge offers a separate AWS-only warehouse.
Several managed open-source infrastructure projects from one vendor	Portfolio breadth	Aiven	Choose this only when the portfolio is worth the extra cross-service integration, networking, recovery, and cost-management work.

Conclusion

Evaluate the options against one architectural question: what stays on the transactional Postgres path, what runs on isolated analytical compute, and how much integration you have to assemble yourself. You can keep both workloads in Postgres while it meets their targets. Once analytics creates measurable contention, ClickHouse Managed Postgres provides the integrated route we recommend for moving that work into ClickHouse Cloud.

Get started with ClickHouse Managed Postgres to run Postgres for transactions and ClickHouse Cloud for analytics in one managed experience.

FAQs about Postgres hosting for AI agents

What is the best Postgres hosting provider for AI agents?

ClickHouse Managed Postgres is the best overall Postgres hosting provider for sustained production AI applications that need both high-performance transactions and dedicated analytics. It combines NVMe-backed Postgres, managed CDC to ClickHouse Cloud, and a Postgres-facing analytical query layer. The integration requires configuration, and Postgres-only operation remains valid while it meets your transaction and reporting targets.

Which Postgres hosts work best for AI voice agents with spiky traffic?

Always-warm Postgres services are usually the starting point for latency-sensitive production voice agents because scale-to-zero cold starts can delay the first tool call. Neon documents wake-up within a few hundred milliseconds. Aurora Serverless v2 typically resumes in approximately 15 seconds, but AWS notes that resume can take 30 seconds or longer after more than 24 hours paused.

Which Postgres hosts should teams test for thousands of concurrent AI agents?

For thousands of concurrent agents, shortlist services with connection pooling or transaction multiplexing and benchmark p99 latency under the application's actual connection count, query fan-out, transaction mix, retrieval pattern, durability mode, and telemetry load.

Is pgvector support enough for production AI agent workloads?

No. pgvector support only confirms that a provider can store and query embeddings. Production AI agent workloads also require enough memory for vector indexes, predictable p99 latency, connection handling, write throughput, vacuum tuning, and a plan for telemetry analytics.

Which Postgres hosts are best for large vector indexes?

For large vector datasets, evaluate index-memory behavior, disk access patterns, filtering support, build time, update behavior, recall, and scaling mechanisms. AlloyDB's ScaNN, Tiger Cloud's StreamingDiskANN, ClickHouse Managed Postgres with pgvector or vchord, and carefully sized pure-Postgres providers are candidates.

Should AI agent telemetry run on the same Postgres database as live agent traffic?

It can while both workloads meet their targets. Move telemetry to a replica, read pool, or dedicated analytical engine when analytical scans cause breached transaction-latency targets, persistent CPU, I/O, or cache contention, missed analytical SLAs, or overprovisioning driven by scans. ClickHouse Managed Postgres supports the dedicated-engine pattern through configured ClickPipes into ClickHouse Cloud.

Which Postgres providers offer database branching for agent experimentation?

Neon offers copy-on-write branches suited to preview and branch-per-PR workflows. ClickHouse Managed Postgres offers restore- and PITR-based forks into new services, not copy-on-write branches. These mechanisms are useful for experimentation, testing, and recovery, but they don't replace production capacity planning.

Which Postgres providers offer scale-to-zero for AI agent backends?

Neon and eligible Aurora Serverless v2 configurations offer scale-to-zero or auto-pause behavior. It's usually a better fit for development, smaller-scale applications, branches, and intermittent workloads than for latency-sensitive production agents. Neon documents wake-up within a few hundred milliseconds. Aurora Serverless v2 typically resumes in approximately 15 seconds and can take longer after an extended pause.

Which Postgres providers support isolated transactional databases and unified tenant analytics?

ClickHouse Managed Postgres supports this pattern. Each Postgres service can remain an isolated transactional system of record, while one or more configured ClickPipes replicate selected tables into a ClickHouse Cloud analytical service. pg_clickhouse requires separate foreign-server, user-mapping, and foreign-table configuration. Crunchy Bridge provides a separate AWS-only warehouse path through managed logical replication.

Which Postgres providers offer APIs and MCP support for agent automation?

ClickHouse, Tiger Cloud, Google Cloud, Aiven, and DigitalOcean provide MCP or agent-oriented interfaces. The important distinction is scope: some tools can provision or modify services, while others are limited to querying and inspection. ClickHouse Agents adds read-only-by-default Postgres analysis and can analyze Postgres and ClickHouse Cloud together. Check the default permissions, SQL role, approval controls, and guidance for production data.

Best Postgres hosting providers for startups in 2026: 8 managed PostgreSQL options compared

M C — Fri, 21 Aug 2026 18:41:05 +0000

As a startup grows, the same application data that powers transactions begins powering usage dashboards, billing aggregation, reporting, personalization, and AI features. Analytics is coming either way. The real question is where those workloads run once it does.

We built ClickHouse Managed Postgres for this path from transactional applications to real-time analytics. Our fully managed PostgreSQL service is backed by local NVMe storage and integrated with ClickHouse Cloud. Postgres remains the transactional system of record for OLTP, while ClickPipes and pg_clickhouse connect the same application data to ClickHouse for real-time analytics. Start with PostgreSQL, scale with ClickHouse, without assembling and operating a separate CDC and query-integration stack.

The providers compared here span three operating models. Dedicated database services focus on Postgres operations and performance. Multi-service data platforms manage PostgreSQL alongside other open-source infrastructure. Hyperscaler services integrate Postgres with a broader cloud environment.

ClickHouse Managed Postgres extends the dedicated-database model into a unified data stack: Postgres for OLTP and ClickHouse for OLAP, connected by ClickPipes and pg_clickhouse and managed through ClickHouse Cloud.

TL;DR

ClickHouse Managed Postgres, our fully managed PostgreSQL service, combines production Postgres, local-NVMe OLTP performance, and integrated ClickHouse analytics through ClickPipes and pg_clickhouse.
Choose Neon for smaller-scale or latency-tolerant applications when branch-per-PR environments and scale-to-zero economics are the deciding requirements; choose ClickHouse Managed Postgres for sustained, I/O-heavy production Postgres and integrated analytics.
Choose RDS, Aurora, or Cloud SQL if provider-native IAM, networking, region coverage, and established cloud operations are hard requirements; choose ClickHouse Managed Postgres for local-NVMe Postgres and integrated ClickHouse analytics.
Before choosing, validate high availability, recovery, and connection pooling. Check extension and region availability, read replica support, and failover behavior. Then price it all against your actual workload.

Postgres hosting providers comparison table

For startups that need high-performance production PostgreSQL and a direct route to real-time analytics, our ClickHouse Managed Postgres service combines local-NVMe Postgres with managed ClickPipes replication and pg_clickhouse query access to ClickHouse. Neon stands out for smaller-scale development workflows, and RDS, Aurora, or Cloud SQL for provider-native cloud operations.

Provider	Operating model	Best fit when	Pricing	What drives the bill	HA, recovery, and read scaling	Path to analytics
ClickHouse Managed Postgres	Dedicated database service with integrated ClickHouse analytics	Production applications need local-NVMe Postgres performance and an integrated route to ClickHouse analytics	Hourly pricing based on the full local-NVMe VM configuration; rates vary by tier, region, architecture, and instance family. Use the pricing calculator	Tier, full VM configuration, HA standbys, read replicas; a separate ClickHouse service for analytics	HA: up to two standbys; recovery: daily backups and PITR, with seven-day retention on Scale; read scaling: independently sized replicas via WAL shipping	Managed ClickPipes CDC plus `pg_clickhouse` query access to ClickHouse
Neon	Dedicated database service	Smaller-scale or latency-tolerant applications prioritize branch-per-PR workflows and serverless compute	Launch: $0.106 per CU-hour and $0.35 per GB-month; Scale: $0.222 per CU-hour and $0.35 per GB-month	CU-hours, database storage, history storage, branches, read replicas, network transfer	HA: multi-AZ storage with compute replacement; recovery: one-day history by default, configurable up to seven days on Launch and 30 days on Scale; read scaling: replicas using shared storage	Read replicas or external CDC
Crunchy Bridge	Dedicated database service	A required extension or PostgreSQL setting is unavailable from ClickHouse Managed Postgres	AWS East sample: Standard-16 is $280/month; storage is $0.10 per GB-month; HA doubles the cluster price	Instance size, region, storage, HA, replicas	HA: available on production plans; recovery: ten-day PITR history; read scaling: read replicas	Separate Crunchy Data Warehouse cluster with managed logical replication, read replicas, or external CDC
Aiven	Multi-service managed open-source data platform	One provider is required for PostgreSQL plus services such as Kafka, Flink, OpenSearch, and ClickHouse across clouds	DigitalOcean `do-nyc` Business-4 example: $0.25/hour, or $180 for 720 hours, for two VMs and 80 GB total storage	Service plan, cloud, region, VM size, HA topology, additional storage, replicas, private connectivity	HA: one standby on Business; recovery: 14-day PITR; read scaling: read-only replicas	Remote PostgreSQL access from Aiven for ClickHouse; isolated CDC requires a Kafka and Kafka Connect pipeline
DigitalOcean	Dedicated database service	Packaged resource plans and a smaller operational surface are preferred	Basic Regular with 6 vCPUs, 16 GiB RAM, and the 290-GiB minimum storage: $244.35/month per node	Node plan, storage, number of standby and read-only nodes	HA: up to two standbys; recovery: daily backups and seven-day PITR; read scaling: standby or read-only nodes	Read-only nodes or external CDC
Amazon RDS	Hyperscaler service	The application and operations are standardized on AWS	Use the RDS for PostgreSQL pricing page and calculator	Instance hours, deployment topology, storage, IOPS, backups, replicas, transfer, RDS Proxy	HA: Multi-AZ deployment; recovery: automated backups and PITR; read scaling: read replicas or readable Multi-AZ standbys, depending on topology	Read replicas, Redshift zero-ETL for supported configurations, or external CDC
Amazon Aurora	Hyperscaler service	AWS-native distributed storage, failover, and read scaling are non-negotiable	Use the Aurora pricing page and calculator	Provisioned or ACU compute, storage, I/O pricing model, replicas, backups, transfer	HA: multi-AZ storage with an Aurora Replica required for fast failover; recovery: continuous backups and PITR; read scaling: up to 15 replicas	Aurora Replicas, zero-ETL to Redshift or SageMaker for supported configurations, or external CDC
Google Cloud SQL	Hyperscaler service	The application and operations are standardized on Google Cloud	Use the Cloud SQL pricing page and calculator	Edition, CPU, memory, region, storage, HA, backups, replicas, egress	HA: synchronous writes to regional disks with automatic zonal failover; recovery: automated backups and PITR; read scaling: direct replicas, cascading replicas, or Enterprise Plus read pools	BigQuery federation or Datastream CDC to BigQuery

How we evaluated the best Postgres hosting providers

A startup choosing a managed Postgres provider needs to answer five questions:

Can it run production reliably? We evaluated high availability, failover, backups, point-in-time recovery, connection pooling, and read replicas.
Will it support the application workload? We considered PostgreSQL compatibility, transactional performance, supported versions and extensions, and region availability.
Does it fit the team’s operating model? We compared dedicated database services, a multi-service data platform, and hyperscaler services.
What will it cost at steady production? We examined published pricing and bill drivers such as compute, storage, standbys, I/O, backups, replicas, and network transfer.
What happens as the startup grows? We considered branching workflows, migration reversibility, and the path from transactional Postgres to analytics.

Capabilities, limitations, and pricing were checked against official vendor documentation and pricing calculators on August 18, 2026.

Which Postgres hosting provider should you choose by lifecycle stage?

Growth stage or trigger	Primary database risk	Recommended direction	What to validate
First production deployment	Underbuilding HA, backups, pooling, transactional performance, and the analytics architecture	ClickHouse Managed Postgres for fully managed Postgres on local NVMe with ClickHouse ready for real-time analytics; Neon for smaller-scale or latency-tolerant applications when branching and scale-to-zero are the deciding workflows	HA mode, PITR, backup retention, pooling, extension and region availability
Growing traffic and concurrency	Connection pressure, write throughput, storage I/O, and analytical workloads emerging on the primary	ClickHouse Managed Postgres for sustained, I/O-heavy production Postgres and an integrated OLTP-to-OLAP stack; a hyperscaler service when provider-native operations are a hard requirement	Connection pooling, read replicas, failover, write latency, steady-production cost
Analytics begin competing with transactions	Analytical scans compete with OLTP for resources and drive Postgres overprovisioning	Use ClickHouse Managed Postgres for OLTP and ClickHouse for OLAP, connected through ClickPipes and `pg_clickhouse`	Transaction and dashboard latency under concurrent load, CDC freshness, query pushdown coverage, schema-change workflow, and combined production cost

The analytics breakpoint: when to move OLAP off Postgres

Move OLAP off Postgres when analytical work starts breaching transaction-latency or data-freshness targets, or demands enough overprovisioning and tuning to justify a separate engine. This breakpoint depends on workload shape and concurrency, not a fixed database size. Faster storage and read replicas can delay it, but they don’t turn Postgres into a columnar OLAP engine.

Signs analytics is outgrowing Postgres

Large dashboard refreshes, usage aggregations, billing reports, and historical analyses touch far more rows than transactional lookups. Ordinary reads don’t block writes at the table-lock level, but analytical queries still compete with transactions for CPU, memory, I/O, and buffer cache.

Move the workload when one or more of these conditions becomes persistent:

Analytical queries push transaction latency past the application’s target.
The primary or its read replicas keep getting upsized mainly to sustain scans and aggregations.
Long-running transactions with old snapshots can prevent VACUUM from reclaiming dead row versions on the primary. On a hot standby, long queries can delay WAL replay or be canceled when replayed WAL conflicts with them.
Reporting indexes and materialized views exist mainly to keep analytical queries within their latency targets.

Three ways startups handle the analytics breakpoint

1. Keep analytics on Postgres temporarily

Keeping analytics on Postgres avoids a second data system and works while scans are infrequent and transaction-latency targets hold. As analytical demand grows, the cost shifts into larger instances, reporting indexes and materialized views, and off-peak scheduling.

2. Operate a separate CDC and analytics stack

Replicating Postgres data into a columnar analytical database isolates heavy scans from the transactional engine. You then operate the replication pipeline, schema-change handling, failure recovery, monitoring, access policies across two systems, and separate query paths.

3. Start with PostgreSQL, scale with ClickHouse

ClickHouse Managed Postgres runs the transactional system of record on local NVMe, while ClickHouse serves real-time analytics. ClickPipes replicates selected Postgres tables into ClickHouse with a default pull interval of 60 seconds. End-to-end freshness also includes push time and can increase because of backlog or long-running source transactions. pg_clickhouse pushes supported filters, joins, aggregations, and functions into ClickHouse while applications continue using the PostgreSQL interface.

Both engines are managed through ClickHouse Cloud, so startups avoid assembling and operating separate CDC and query-integration components.

1. ClickHouse Managed Postgres: high-performance Postgres integrated with ClickHouse Cloud

ClickHouse Managed Postgres is our fully managed PostgreSQL service for startups building production applications that need PostgreSQL compatibility, local-NVMe performance, managed operations, and a direct route to real-time analytics. It is integrated with ClickHouse Cloud.

Postgres remains the transactional system of record, while ClickHouse handles high-concurrency dashboards, usage metering, reporting, personalization, and AI or RAG analytics. ClickPipes keeps selected tables synchronized with seconds-level freshness, and pg_clickhouse pushes supported analytical queries into ClickHouse while clients continue using the PostgreSQL interface.

This is a purpose-built OLTP and OLAP stack, not a single-engine HTAP database. Each engine handles the workload it was designed for, and pg_clickhouse pushes supported queries rather than automatically routing every query between the two engines.

Best for

Choose ClickHouse Managed Postgres for production PostgreSQL workloads that benefit from local-NVMe performance, fully managed operations, and a direct route to ClickHouse analytics. It is particularly strong for transactional applications, I/O-heavy OLTP, and teams that want to add real-time analytics without assembling and operating a separate CDC and query-integration stack.

How it works

PostgreSQL data runs on local NVMe storage physically colocated with compute, avoiding a network round trip to network-attached storage. ClickPipes provides managed CDC from Postgres into ClickHouse. Its default pull interval is 60 seconds and can be tuned lower, while end-to-end freshness also depends on push time, backlog, and source transaction duration. On PostgreSQL 17 and later, failover-enabled logical slots allow properly configured CDC pipelines to continue through failovers and scaling operations without recreating the slot or performing a full resynchronization.

That storage architecture also strengthens the service’s core OLTP position. In the latest PostgresBench repository snapshot, ClickHouse Managed Postgres averaged 26,104.81 TPS across three runs at approximately 500 GB on a 16-vCPU, 64-GB configuration with HA disabled. The test used a pgbench TPC-B-like workload with 256 clients. The interactive leaderboard defaults to the best run, which was 26,327.73 TPS for this configuration. Evaluate both results against your own schema and workload.

The pg_clickhouse extension comes preinstalled and exposes ClickHouse tables through the PostgreSQL interface. Existing ORMs, dashboards, cron jobs, and API code can push supported filters, joins, aggregations, and functions into ClickHouse without changing database clients or connection strings. Pushdown is partial: current ClickHouse product documentation reports that 14 of 22 TPC-H queries are fully pushed down. Query coverage and performance vary by query shape, so validate both with EXPLAIN (VERBOSE) and a workload-specific test.

Pricing

Pricing is hourly and based on the full local-NVMe VM configuration, including CPU, memory, and storage. Rates vary by tier, region, architecture, and instance family. More than 50 configurations are available, starting at 1 vCPU, 8 GB of RAM, and 59 GB of NVMe. The Basic tier includes one-day backup retention, point-in-time recovery, branches, high availability support, more than 90 extensions, ClickPipes, and pg_clickhouse. The Scale tier adds storage autoscaling, read replicas, private networking, and seven-day backup retention. Use the pricing calculator for the selected tier, VM configuration, and HA topology; price read replicas and the separate ClickHouse analytics service as additional services.

Production operations

ClickHouse Managed Postgres ships with a bundled PgBouncer fleet operating in transaction-pooling mode. High availability options include zero, one, or two dedicated standbys, where a single standby replicates asynchronously, and two standbys form a synchronous quorum. These standbys are reserved for failover and durability and can’t serve reads. Use dedicated read replicas for read scaling.

All tiers include daily full backups, WAL archiving, point-in-time recovery, and PITR branches. Read replicas use WAL shipping from object storage rather than streaming replication from the primary, isolating read-replica work from the primary. They’re provisioned separately, can be sized independently, and can lag the primary by a few tens of seconds.

Direct connections are available for applications relying on server-side prepared statements that conflict with transaction pooling. ClickPipes CDC also connects directly to PostgreSQL and doesn’t run through PgBouncer. The service supports PostgreSQL 17 and 18 and includes more than 90 Postgres extensions.

When another platform model is the better fit

Choose a hyperscaler database when a provider-specific region, IAM or networking integration, PostgreSQL version, or extension unavailable in ClickHouse Cloud is non-negotiable.

2. Neon: Serverless Postgres for branching workflows

Best for

Choose Neon for smaller-scale or latency-tolerant applications when branching, preview environments, autoscaling, and scale-to-zero are the deciding workflows. For sustained, I/O-heavy or continuously active production databases, compare its steady-state compute and latency directly against fixed-size alternatives.

How it works

Neon is a serverless Postgres offering with separated storage and compute layers. Copy-on-write branching can create database branches without duplicating the underlying data. Compute instances can suspend after inactivity, defaulting to five minutes where applicable.

Pricing

The Neon Launch plan bills compute at $0.106 per CU-hour and storage at $0.35 per GB-month, with no fixed monthly base. The Scale plan costs $0.222 per CU-hour and adds an SLA, private networking, and restore windows configurable up to 30 days. Compute is billed in CU-hours: average compute size in CUs multiplied by active runtime. History storage is billed separately.

One Compute Unit represents roughly 4 GB of RAM plus associated CPU and local SSD resources. A four-CU instance provides approximately 16 GB of RAM. CU-hours, storage capacity, branching overhead, read replicas, and retained history shape the monthly total. Steady 24/7 production traffic removes the economics of scale-to-zero.

Production considerations

Neon includes PgBouncer transaction pooling. For production endpoints that require consistently low connection latency, disable scale-to-zero; smaller or intermittent workloads can retain it when cold starts are acceptable. High availability combines multi-AZ storage and Safekeeper quorum durability with stateless compute that is automatically restarted or replaced after a failure, so clients must reconnect and retry interrupted queries.

Paid plans default to one day of retained history. Launch can be configured up to seven days and Scale up to 30 days, with retained WAL history billed separately. Instant restore applies to root branches. Paid plans also offer separately billed snapshots and read replicas using shared storage.

Where it falls short

Neon scale-to-zero adds connection latency when suspended compute restarts. Reactivating suspended compute adds a few hundred milliseconds, so production primaries with strict connection-latency requirements should keep their compute instances active.

The analytics path requires running queries directly on Postgres, using read replicas, or replicating data to a separate analytical system. A connected logical-replication subscriber keeps Neon compute active, so scale-to-zero savings do not apply while CDC is connected. Logical replication also requires a direct, non-PgBouncer connection.

3. Crunchy Bridge: Managed Postgres with configuration control

Best for

Choose Crunchy Bridge when a specific extension in its documented catalog or a PostgreSQL configuration setting unavailable from ClickHouse Managed Postgres is a hard requirement.

How it works

Crunchy Bridge provides managed PostgreSQL with broad extension availability and self-service access to many PostgreSQL configuration parameters. It does not support arbitrary extensions or unrestricted configuration, so verify the exact extension and setting before choosing it for this reason.

Pricing

In Crunchy's published AWS East sample pricing, Standard-16 provides 4 cores and 16 GB at $280 per month. 100 GB of storage adds $10, and high availability doubles the cluster price. A Standard-16 deployment with 100 GB and high availability therefore costs about $580 per month at list rates. Use the pricing calculator to adjust for region, cloud, and configuration.

Expect costs to move with the compute tier, region, storage capacity, high availability topology, and separately provisioned read replicas. The default ten-day backup retention is included.

Production considerations

High availability is available on all production plans. Crunchy Bridge automatically takes daily base backups and archives WAL, retaining ten days of point-in-time recovery history.

Read replicas are supported for scaling. PgBouncer is available on production plans and uses transaction mode by default; the crunchy_pooler extension must be installed separately in each database that accepts pooled connections. The platform supports a broad extension catalog and self-service major-version upgrades that complete during a maintenance window and normally require downtime.

Where it falls short

Standard Crunchy Bridge Postgres clusters do not include an analytical engine. Crunchy also offers Crunchy Data Warehouse as a separate AWS-only cluster type inside Crunchy Bridge. For an existing operational database, its Data Sync feature performs an initial copy and then applies logical-replication changes to Iceberg tables in 30-second batches, with typical lag below 60 seconds.

The warehouse retains the PostgreSQL interface and planner, delegating eligible analytical fragments to DuckDB's vectorized engine over Parquet-backed Iceberg data. It is a single-node engine rather than distributed analytical compute, and unsupported operations fall back to PostgreSQL execution. A separate warehouse isolates analytical query compute from the OLTP server, although initial copying, logical decoding, WAL generation, and network transfer still use source resources.

In the latest PostgresBench repository snapshot, the three-run arithmetic mean at approximately 500 GB was 10,953.71 TPS for Crunchy Bridge and 26,104.81 TPS for ClickHouse Managed Postgres. At approximately 100 GB with 4 vCPUs and 16 GB RAM, Crunchy Bridge averaged 6,320.00 TPS and ClickHouse Managed Postgres averaged 6,012.88 TPS. These were single-node, HA-disabled pgbench tests using provider defaults; the interactive leaderboard displays the best run rather than the three-run mean.

4. Aiven: Managed open-source data services across multiple clouds

Best for

Choose Aiven when your team specifically needs one provider for a broad open-source data stack across clouds, including PostgreSQL alongside services such as Kafka, Flink, OpenSearch, and ClickHouse.

How it works

Aiven provides a common control plane for multiple managed open-source data services across AWS, Azure, Google Cloud, DigitalOcean, OVH, and UpCloud, with service and region availability varying by product. This breadth is most relevant when a team would otherwise operate several specialist data services and their integrations.

Pricing

The currently displayed DigitalOcean do-nyc Business-4 example costs $0.25 per hour, or $180 for 720 hours. It includes two VMs, each with 2 CPUs and 4 GB RAM, plus 80 GB of total storage. Pricing varies by cloud, region, and selected Business size.

The selected service plan, cloud, region, VM size, and high availability topology set the baseline cost. Additional storage, read-replica services, and private connectivity can add cost. Standard Aiven network traffic is included, although the application's cloud provider may charge its side of a transfer.

Production considerations

The Business plan provisions one primary and one standby node with 14 days of backup retention. Premium plans offer two standbys and 30 days of retention.

Connection pooling uses PgBouncer and is configurable across transaction, session, and statement modes, with transaction as the default and recommended mode. Aiven takes daily recovery backups and copies WAL at five-minute intervals for point-in-time recovery. Failover promotes the standby and schedules a replacement node automatically. Extensions such as pgvector are supported on compatible PostgreSQL versions.

Where it falls short

Aiven is a poor fit when you need only a PostgreSQL specialist or a direct Postgres-to-analytics offload path.

The built-in Aiven for PostgreSQL-to-Aiven for ClickHouse integration wraps ClickHouse's standard PostgreSQL engine in an automatically created integration database. It queries data remotely rather than copying it into ClickHouse, so large scans can still consume PostgreSQL CPU, I/O, connections, and network capacity. An isolated CDC copy requires a multi-service pipeline using PostgreSQL, Kafka, Kafka Connect, and a ClickHouse sink connector.

5. DigitalOcean: Managed Postgres with packaged resource plans

Best for

Choose DigitalOcean when packaged resource plans and a smaller operational surface matter more than advanced database controls.

How it works

DigitalOcean provides managed PostgreSQL clusters using plan-based compute and storage. It keeps provisioning and scaling simple, but exposes fewer database controls than specialized Postgres providers.

Pricing

The Basic Regular shared-CPU configuration with 6 vCPUs, 16 GiB RAM, and the 290-GiB minimum storage costs $244.35 per month per node. The total consists of a $182 node plus 290 GiB at $0.215 per GiB-month. High availability requires at least one matching paid standby, bringing the minimum two-node configuration to $488.70 per month.

Cost scales with the primary node size, the number of standby nodes, storage capacity, and read-only nodes. Traffic to and from Managed Databases does not count against DigitalOcean's bandwidth-billing transfer allowance.

Production considerations

DigitalOcean clusters can configure zero, one, or two standby nodes for high availability. Daily backups with point-in-time recovery and seven-day retention are included.

Automatic failover promotes a standby and provisions a replacement node in the background. Connections will disconnect during brief maintenance or failover windows, requiring client retry logic. Standard Edition standbys can serve reads, but heavy read load can compromise failover readiness; separate read-only nodes provide independently addressed read scaling. Extensions such as pgvector are supported.

Where it falls short

DigitalOcean exposes fewer database controls than specialized Postgres providers. The analytics path involves using read-only nodes for reporting, exporting data, or configuring change data capture to ClickHouse or another analytical system.

6. Amazon RDS for PostgreSQL: AWS-native managed Postgres

Best for

Choose RDS when your application and operations are already standardized on AWS.

How it works

RDS manages PostgreSQL instances, storage volumes, automated backups, maintenance windows, Multi-AZ configurations, and read replicas within the AWS network. RDS offers extensive control over instance types, storage classes, and parameter groups.

Pricing

Use the RDS for PostgreSQL pricing page and calculator to price the selected region, instance class, deployment topology, storage, IOPS, and backup retention.

Drivers include the specific instance class, storage class, provisioned IOPS, Multi-AZ standby configuration, backup storage beyond the included allowance, read replicas, data transfer, and RDS Proxy charges.

Production considerations

A Multi-AZ instance deployment provisions one standby that is reserved for failover and doesn’t serve read traffic, while a Multi-AZ cluster deployment provisions two standby instances that can serve reads.

RDS Proxy pools and reuses connections, but session-state changes and temporary tables can pin sessions, and Postgres session-pinning filters are unsupported. Automated backups provide point-in-time recovery.

Where it falls short

RDS pricing and performance tuning span instance classes, storage types, provisioned IOPS, and I/O options. This adds operational complexity for write-heavy workloads.

In the latest PostgresBench repository snapshot, RDS averaged 4,727.11 TPS across three runs at approximately 500 GB on 16 vCPUs and 64 GB RAM. This benchmark ran with high availability disabled, used a pgbench TPC-B-like workload with 256 clients, and excluded pricing comparison. The interactive leaderboard defaults to the best run, which was 5,078.41 TPS for this configuration.

RDS for PostgreSQL offers zero-ETL integration to Amazon Redshift for supported engine versions, regions, and DB instance topologies. AWS's engine-specific compatibility matrix does not currently list SageMaker AI lakehouse as a destination for RDS for PostgreSQL. Other options are running analytical queries directly on RDS, using read replicas, or replicating to another analytical system.

7. Amazon Aurora PostgreSQL: Distributed storage and read scaling on AWS

Best for

Choose Aurora when your AWS workload requires distributed storage durability, rapid failover, and extensive read scaling.

How it works

Aurora separates database compute from a purpose-built distributed storage layer. It offers both provisioned and serverless capacity models. Aurora Replicas share the underlying storage architecture, enabling read scaling without independent storage provisioning.

Pricing

Use the Aurora pricing page and calculator to price the selected region, provisioned or Serverless v2 compute, storage, I/O model, replicas, and backup retention.

Bills reflect provisioned instance-hours or consumed ACU-hours, total storage, the chosen I/O model, billable backup and snapshot storage, data transfer, and read-replica compute. Serverless minimum and maximum ACU settings constrain consumption but are not separate charges.

Production considerations

Aurora replicates storage synchronously across multiple Availability Zones, which protects the data but doesn’t by itself provide standby compute. With one or more Aurora Replicas, service is typically restored in under 60 seconds and often in under 30 seconds. Place at least one replica in another Availability Zone for AZ resilience. Without a replica, AWS recreates the writer instance, and restoration typically takes under 10 minutes. Aurora supports up to 15 Aurora Replicas, which serve as failover targets and read scaling nodes.

RDS Proxy can keep most application connections open and redirect them during failover, but statements or transactions in progress are canceled and must be retried. Point-in-time recovery, continuous backups, and global database features are supported.

Where it falls short

Aurora Serverless auto-pause requires a supported engine version and a minimum capacity of zero ACUs. An attached RDS Proxy prevents all instances in the cluster from pausing, while open user connections prevent the affected instance from pausing. Logical replication and global database configurations prevent writers and some failover-tier readers from pausing.

In the latest PostgresBench repository snapshot, Aurora averaged 9,125.25 TPS across three runs at approximately 500 GB. Aurora used 16 vCPUs and 128 GB RAM, compared with 64 GB RAM for the ClickHouse Managed Postgres, Crunchy Bridge, and RDS configurations. The test used a single writer with no Aurora Replica. Aurora also supports zero-ETL integrations to Redshift and, for supported versions and regions, a SageMaker AI lakehouse. These integrations carry topology, schema, data-type, and region restrictions.

8. Google Cloud SQL for PostgreSQL: GCP-native managed Postgres

Best for

Choose Cloud SQL when your application and operations already run on Google Cloud.

How it works

Cloud SQL provides managed PostgreSQL instances backed by Google Cloud provisioning, monitoring, high availability, and maintenance controls. Teams manage it through the same Google Cloud networking, monitoring, IAM, and maintenance controls used by the rest of their infrastructure.

Pricing

Use the Cloud SQL pricing page and calculator to price the selected edition, region, CPU, memory, storage, high availability, and backup retention.

CPU allocation, memory, persistent storage, the high availability standby footprint, automated backups, read replicas, and networking egress affect the bill.

Production considerations

Regional high availability synchronously replicates writes to persistent disks in both the primary and secondary zones. Failover typically causes about 60 seconds of unavailability and uses the same connection string.

For an unavailable instance, Google says point-in-time recovery typically provides an RPO of five minutes or less, but this is not a contractual guarantee and PITR creates a new instance. Read replicas are billed separately and do not ordinarily replace the primary automatically. Unless overridden, Cloud SQL derives the default max_connections from the configured memory of the largest instance in the replication chain.

Where it falls short

Cloud SQL supports up to ten conventional direct read replicas; use cascading replicas for larger conventional topologies. Enterprise Plus also supports read pools with 1 to 20 directly attached nodes behind one load-balanced endpoint.

Cloud SQL supports federated queries from BigQuery and managed Datastream CDC into BigQuery. Federation executes the external query on Cloud SQL, so Google recommends a read replica for workload isolation. Datastream replicates changes into BigQuery to separate analytical execution. Read replicas and external logical replication remain additional options.

How to evaluate a Postgres hosting provider: pre-commit checklist

Evaluate every shortlisted provider against the same production-like workload.

Create a shortlist from non-negotiables. Keep two or three providers that support your required PostgreSQL version, extensions, regions, high-availability topology, private networking, and analytics path.
Model steady-production cost. Price expected compute, storage, I/O, high-availability standbys, backups, read replicas, connection pooling, and network transfer. Cover both normal traffic and expected bursts.
Run a workload-specific proof of concept. Use a production-like schema, realistic data volumes and indexes, the expected write ratio, and the anticipated connection count. Measure transaction latency and throughput while running the heaviest analytical queries.
Test connection handling. Confirm pooling behavior at peak connection counts, including compatibility with server-side prepared statements and your application framework.
Rehearse failover and recovery. Force a failover and measure database unavailability and application reconnection time. Compare restore and reconnection duration with your recovery-time objective, and compare the latest restorable timestamp and recovered data with your recovery-point objective.
Test read scaling. Provision a read replica, measure replica lag under write load, and check how long-running queries interact with WAL replay.
Verify the operating model. Review maintenance windows, upgrade behavior, private networking, audit logging, observability metrics, and extension availability on the target PostgreSQL version.
Validate the analytics path. Determine whether future analytical workloads will stay on Postgres, run on read replicas, or move to a separate OLAP engine. If the provider offers CDC or query offload, test replication freshness, schema-change handling, failure recovery, and query coverage.
Document the exit plan. Validate schema export, logical replication and CDC limitations, application connection changes, data-validation steps, cutover, rollback, and analytics-pipeline continuity.

Conclusion: Which Postgres hosting provider to choose in 2026

For startups that need high-performance production PostgreSQL and a direct route to real-time analytics, ClickHouse Managed Postgres combines local-NVMe Postgres with integrated ClickHouse analytics. ClickPipes replicates selected data into ClickHouse, and pg_clickhouse keeps analytical query access inside the PostgreSQL interface. Start with PostgreSQL, scale with ClickHouse.

Before committing, price the complete production configuration and test it with your schema, connection count, failover requirements, and heaviest analytical queries.

Start with ClickHouse Managed Postgres through the ClickHouse Cloud trial with $300 in credits.

Frequently asked questions about Postgres hosting providers

What is the best Postgres hosting provider for startups in 2026?

The best fit depends on the startup's workload and operating requirements. For startups that need high-performance production PostgreSQL and real-time analytics in one managed experience, ClickHouse Managed Postgres combines local-NVMe OLTP, managed HA and recovery, ClickPipes replication into ClickHouse, and pg_clickhouse query access through PostgreSQL.

How should startups choose a managed Postgres provider?

Startups should evaluate high availability, automated backups, point-in-time recovery, connection pooling, failover behavior, read replicas, observability, private networking, extension and region availability, production pricing, migration reversibility, and the path from transactional Postgres to analytics.

How much does managed Postgres cost for a startup?

Entry prices are not production estimates. Model compute, storage, I/O, high-availability standbys, backups and point-in-time recovery, read replicas, connection pooling, support, and network transfer for an always-on production workload. Usage-based services can cost less for idle workloads, while fixed-size plans are generally easier to predict for steady traffic.

When should you move analytics off Postgres?

Move analytics off Postgres when dashboards, aggregations, billing queries, reporting jobs, or AI workloads begin slowing transactional queries or causing replica lag. At that point, Postgres should remain the system of record while analytical queries move to a columnar system like ClickHouse.

Which Postgres hosting providers offer an integrated analytics path?

ClickHouse Managed Postgres integrates both sides of the Postgres-to-ClickHouse workflow into the managed database experience: ClickPipes replicates PostgreSQL data into ClickHouse, and pg_clickhouse lets applications query ClickHouse through the PostgreSQL interface. RDS for PostgreSQL supports zero-ETL integration to Redshift for supported configurations. Aurora supports zero-ETL to Redshift and, for supported versions and regions, a SageMaker AI lakehouse. Cloud SQL supports BigQuery federation and managed Datastream CDC to BigQuery. Crunchy Bridge offers a separate Crunchy Data Warehouse cluster with managed logical replication. ClickHouse Managed Postgres is designed for startups that want a purpose-built Postgres-for-OLTP and ClickHouse-for-OLAP stack with both replication and query access managed through ClickHouse Cloud.

Is Amazon RDS or Aurora better for Postgres?

RDS is the conventional managed Postgres choice for AWS teams that want broad compatibility and mature operations. Aurora provides distributed shared storage and up to 15 replicas. Failover performance depends on the selected topology: compare AWS's documented ranges and test application reconnection behavior.

Which Postgres hosting providers offer automatic scaling?

Automatic scaling means different things across providers, so verify the specific feature in each vendor's documentation. Distinguish between compute autoscaling, storage autoscaling, serverless suspend and resume, read scaling, and replica scaling.

Neon documents compute scaling and scale-to-zero, and Aurora Serverless scales within configured ACU boundaries. ClickHouse Managed Postgres Scale and Enterprise tiers support storage autoscaling by provisioning a larger replacement instance and performing a controlled cutover rather than expanding local NVMe in place.

How should startups scale Postgres as data volume grows?

Startups should model storage, backups, read replicas, I/O costs, restore time, and analytical query costs before the primary database reaches its next scaling threshold. Common triggers include connection pressure, extension or replica constraints, changing cloud operating models, and analytical workloads competing with transactions.

The 5 Primitives We Use to Evaluate in a Stateful Agent Context Layer

M C — Tue, 18 Aug 2026 15:51:54 +0000

An agent approves a refund, changes a contract, or sends a consequential recommendation. Three months later, the underlying facts have changed. Can you prove what the agent knew when it acted, where that context came from, and whether the agent was allowed to use it?

This question tests a stateful agent context layer. Once consequential context persists across a turn, session, user, agent, tool, workflow, or time boundary, retrieval becomes more than a semantic-search problem. Depending on the application, the system may need to preserve relationships, reconstruct past state, distinguish current truth from superseded facts, enforce authorization before context reaches the model, and assemble a coherent view from multiple signals.

These requirements map to five context-layer capabilities: connected state, versioned episodic history, temporal truth, permission-aware provenance, and multi-signal context assembly. These capabilities complement, rather than replace, underlying database guarantees such as read isolation, durable writes, conflict detection, schema evolution, and retention. We cover when each capability becomes necessary, what failure it prevents, and when a simpler architecture suffices.

TL;DR

A stateful agent context layer preserves consequential context across turns, sessions, users, agents, tools, workflows, or time and persisted and external context is made available to the agent when it acts
The five primitives are connected state, episodic history, temporal truth, permission-aware provenance, and multi-signal context assembly.
A stateful AI application needs a primitive when it must reconstruct past context, maintain current truth, enforce permission boundaries, or select context using relationships and multiple signals.
A stateful agent context layer also depends on database guarantees such as read isolation, durable writes, conflict detection, schema evolution, and retention. Vector search alone is sufficient only for flat, static, already-authorized content.

What is a stateful agent context layer?

An agent context layer determines what persisted and external context is available to an AI agent when it acts.. It governs what information the system retrieves, how long that information persists, who can see it, and how it connects to the active task.

That job sits apart from the large language model, the prompt, the orchestration framework managing loops, and the tool layer executing API calls, even though all of these work together at runtime.

It becomes stateful once information starts carrying across users, sessions, and time on data where being wrong has real consequences, and that’s where the requirements start.

The primitives represent infrastructure-level capabilities that application code can implement directly, but doing so means the team is building that infrastructure itself. They don't guarantee overall agent correctness on their own.

What makes an agent context layer stateful?

Persisting consequential context, rather than just labeling a feature "memory," activates some engineering and governance requirements.

A stateless retrieval tool answers one isolated question from a static, public corpus, executing semantic search and returning the closest matches. That alone doesn’t activate these requirements, and it doesn’t need to track who asked, what changed yesterday, or whether a fact was superseded.

But once a system retains context across users, sessions, and time, it creates three permanent operational surfaces.

First, an accountability surface. The NIST AI RMF calls for transparency and accountability risks to be examined and documented. One practical implication for a context layer is retaining records of the context available to an agent when it acted.

The second one is the history surface, where the information either changes, is corrected, or gets explicitly deleted, and the system must differentiate between a new fact and an updated one.

Third is an isolation surface. When multiple users or organizations interact with the same application, strict boundaries must prevent one tenant's actions or inferred preferences from influencing another tenant's agent outputs.

The remaining two about keeping current truth and selecting under a finite window come from the data changing and the context outgrowing the model window rather than from retention itself.

A stateless retrieval tool can be reliable without managing any of this. But a stateful agent takes on accountability, history, and isolation the moment they apply. That's what decides whether a system needs only a vector index or a context layer built specifically for these surfaces.

Which requirements apply to a stateful agent context layer?

The application of these requirements depends on the context of use and the consequence of the agent's actions. Not every AI application activates all five, and production deployment by itself doesn't guarantee that any of them do.

Requirement	Activation test	Context-layer guarantee	Boundary
Accountability	Someone will ask why the agent did what it did after a consequential output	Reconstruct the context and state transitions available to the agent	Full explanation also needs execution traces, model versions, prompt versions, outputs, and tool-call records
Historical truth	Someone will ask what the system believed at a past moment	Answer as-of questions after underlying facts move	Current state alone is not enough
Isolation and attribution	More than one tenant's context exists, and cross-boundary disclosure is unacceptable	Unauthorized context never reaches the model, and retrieved context records its source and owner	Authorization must be enforced outside the model. Answer-level attribution also needs model and execution traces
Current truth	Facts change while the system runs and stale answers are wrong	Use the current valid fact when answering	Current truth can exist without historical replay
Constrained selection	Relevance depends on relationships and the model window is smaller than candidate context	Select context that is relevant, authorized, current, and connected	This selection requirement is broader than context overflow

Episodic history is only a part of what explains model behavior. While the context layer can guarantee exactly what documents and state parameters were provided to the model, full accountability still needs orchestrator logs, prompts, and output traces working alongside the context system.

When is current state enough for an agent context layer?

A tenant-safe current-state store paired with access controls and destructive overwrites is a legitimate, effective architecture when accountability and historical truth aren't active. If your application only needs to retrieve the latest explicitly permitted state, this simpler design meets the requirements for current truth and isolation.

Say your agent derives a user preference. The preference gets overwritten in your database from "prefers detailed responses" to "prefers concise responses." Your current-state store can serve that latest preference quickly and safely to the model.

What it can't give you is accountability. It can't answer whether the agent used the old preference last month, whether the user explicitly changed the preference, or whether an automated ingestion job corrected a prior mistake.

How should you separate guarantees, capabilities, and mechanisms?

The guarantee is the promise the system makes once a requirement kicks in. The capability is what the context layer actually has to do to keep that promise. The mechanism is just how you build the capability. The five primitives in this piece are capabilities, each one tied to the requirements it covers.

Multiple mechanisms can provide each capability, so no specific mechanism is universally mandatory.

Isolation is usually built with mechanisms like row-level authorization filters or physical per-tenant separation. Accountability and historical truth can lean on a full append-only event log, though scoped decision snapshots work too if you need point-in-time accountability. For connected state, teams can rely on graph traversal, or relational joins over a normalized schema. Temporal truth is where bitemporal validity intervals and event sourcing with replay tend to show up.

Omitting a required capability is an architectural decision that leaves the matching guarantee unenforced.

Capability	Requirements it supports
Connected state	Constrained selection
Episodic history	Accountability, historical truth
Temporal truth	Historical truth, current truth
Permission-aware provenance	Accountability, isolation and attribution
Multi-signal assembly	Isolation, current truth, constrained selection

These five are context-layer capabilities, not the complete database contract underneath them. A production stateful system may also require read isolation, durable writes, conflict detection, relational constraints, schema evolution, and retention. Those substrate guarantees determine whether the five capabilities remain correct under concurrent reads and writes, replay, migration, and deletion.

Many memory-layer evaluations collapse these concepts. They present one implementation style as mandatory, like forcing all workloads into a specific vector database or assuming every workflow needs an abstracted memory application.

Match active obligations to required capabilities, then select the mechanism that fits your team’s latency, cost, and operational constraints.

What each primitive guarantees and how it fails

When a system is stateful and its outputs carry consequences, it requires primitives that map directly to the activated requirements. One worked example, deriving a user preference from behavior, runs through all five.

1. Connected state for relationship-aware context selection

Connected state serves constrained selection. The guarantee is that relationships can participate in context selection before the model ever sees the context.

When an agent needs to act on a derived preference, selecting the correct preference should account for the user, the specific workspace, the active task type, the original source behavior, and the current goal.

A raw semantic similarity search can return a preference about "concise answers" because the embedding is close in vector space to the query. But if the relationships between the user, the task, and the preference are unavailable to the retrieval path, whether through storage queries, retrieval planning, or application-side joins, the selector can't use them to constrain the result.

The concrete failure is a system that retrieves a preference because of semantic similarity, but misses that the preference belongs to a completely different project, workflow, or decision context.

Graph traversal and relational joins can both satisfy connected-state requirements. Relational joins work well for bounded domains with stable, normalized schemas. As entities, relationship types, and sources evolve, or when traversal itself determines relevance, a graph-native substrate becomes the more natural fit.

2. Episodic history for accountability and historical truth

Episodic history serves accountability and historical truth. In practice, this means that retained, ordered records can reconstruct prior states and the transitions between them, provided those records contain complete event metadata and stable replay semantics.

A preference may be explicit or derived from one or more observations. For a derived preference, the system must retain the observations and their source metadata to explain how the state was produced.

Without history, destructive updates erase the transition record. The system also needs provenance metadata, since history alone can't distinguish a user correction from an automated overwrite.

This gap is what an operator hits directly. They see the current preference is set to "concise," but can't tell which observations produced the setting, who changed it, or whether a later ingestion job rewrote it.

Valid mechanisms include an append-only event log that captures state changes, observations, actors, and ordering metadata. A decision snapshot can preserve the exact context used at a particular decision, although it doesn’t reconstruct every transition that produced that context.

For state shared across runs or agents, this normally requires versioned, append-only transitions with stable event semantics. A decision snapshot can prove what context was used for one action, but it does not replace entity-level history when the system needs cross-run replay, schema evolution, or a complete transition audit.

3. Temporal truth for current and past-state accuracy

Temporal truth serves historical truth and current truth. It promises that the context layer can answer what was true then, and what is valid now.

A user strongly preferred detailed responses in the first quarter of the year, then shifted to preferring concise responses in the third quarter. The system must know both facts and when each applied.

Without this capability, simple database overwrites destroy the ability to answer as-of questions.

Consider an audit where a reviewer asks why the agent gave a highly detailed, verbose answer months ago. Current-state retrieval gives the wrong historical explanation, reporting that the preference is "concise." The agent's past behavior appears hallucinated or incorrect, even though the agent acted correctly based on the truth at that time.

Valid mechanisms include bitemporal validity intervals that record both transaction time and valid time, or event-sourced systems whose events carry both time dimensions and support reliable replay. Event sourcing without valid-time semantics preserves change history but cannot answer every as-of business-time question.

4. Permission-aware provenance for isolation and attribution

Permission-aware provenance serves isolation, attribution, and accountability. Authorization enforced before model exposure prevents unauthorized context from reaching the model. Depending on the application, useful provenance metadata can include source, owner, permission scope, valid-time claim, and supersession lineage, plus extraction method, model version, and confidence. Reconstructing a complete answer still requires prompt, model, output, tool-call, and execution records outside the context layer.

A derived preference inferred from one tenant, workspace, or user must not inadvertently shape the response in another boundary. Without this capability, the system causes immediate security and isolation failures because model instructions aren’t authorization enforcement boundaries.

Instructing a model in the system prompt to "only use information from Workspace A" doesn't prevent the context layer from retrieving and exposing Workspace B's data into the model's context window.

That gap plays out concretely when a preference inferred from one customer's behavior influences another customer's agent response because the authorization filter was omitted, was scoped incorrectly, or was delegated to the model.

Valid mechanisms include row-level authorization, physical per-tenant separation, access control list (ACL) joins, and policy-aware retrieval indexes. With selective vector filters, prefiltering improves filtered-result recall, while postfiltering can miss eligible matches or return fewer than k.

Depending on the implementation and index size, prefiltering can also add CPU and latency overhead, so the non-negotiable security invariant is a hard authorization check before any candidate reaches the model, not one universal vector-filter mode.

5. Multi-signal assembly for relevant, authorized, and current context

Multi-signal assembly serves isolation, current truth, and constrained selection. It guarantees that context selection jointly respects semantic relevance, authorization scope, temporal validity, provenance, and relationships.

Those signals must also be read against a known committed version horizon. Otherwise, every retrieved item can be individually valid while the assembled context combines incompatible points in time.

Without multi-signal assembly, each signal can be correct in isolation while the final assembled context is wrong.

Semantic retrieval successfully finds a highly similar preference that is stale, unauthorized for the current user, or disconnected from the current workflow.

Closing that gap takes more than one signal working correctly. Valid mechanisms include a retrieval planner that combines semantic, graph, metadata, and temporal filters while applying authorization as a hard constraint. A two-stage approach works as well, where policy filters remove unauthorized candidates before relevance reranking.

Multi-signal assembly doesn't guarantee perfect precision. Context precision can be measured after the team defines relevance through reference answers, labeled chunks, reference contexts, or another evaluation criterion. The capability enforces the selection policy. The evaluation setup makes retrieval performance measurable.

Should you use an integrated substrate or a modular stack for agent context infrastructure?

Two common context-layer approaches are a coordinated modular stack and an integrated substrate. Both are valid choices, and both fail in their own particular ways.

A modular stack can provide every activated capability if its components share identity, version, authorization, temporal, and provenance semantics and if reads are anchored to an authoritative transaction-time horizon. Without that boundary, the components can coordinate retrieval but cannot claim a coherent snapshot. A single authoritative write path is the simplest design; a distributed consistency protocol is another, more operationally expensive route.

Common modular-stack failures are usually operational in nature, showing up as distributed coordination gaps, race conditions, and invalidation drift across disconnected indexes.

Integrated designs can coordinate temporal, relational, and semantic rules under one version model. Whether they also enforce write-time relational constraints or transactional isolation depends on the guarantees exposed by the system. What you trade for that is tighter coupling, more schema complexity, and a concentrated blast radius if the shared infrastructure goes down.

Vector-native retrieval is a mature fit for semantic similarity over static, flat content when you don’t need relationship, permission, historical, or evolving-state guarantees. Predefined memory abstractions and hand-assembled stacks work for constrained use cases and teams with heavy platform engineering resources. Tenant-safe current-state stores remain sufficient when only isolation and current truth are active and historical replay is unnecessary.

For systems that require connected, evolving, attributable, and permission-aware context, HydraDB provides graph-native storage and traversal infrastructure. Vector search remains one retrieval mode within that infrastructure, not the architecture itself.

On LongMemEval-s, a benchmark for long-term interactive memory, it shows 90.79% overall accuracy. Teams can bring their own domain model rather than adopt a predefined memory abstraction.

How can you audit a stateful agent context layer for missing capabilities?

Omitting a capability doesn't remove the requirement. It means the context layer can’t satisfy it when production tests it.

Step 1: Identify which requirements are active

Will a consequential output need to be justified or audited later?
Will anyone ask what the system believed at a past moment?
Does context cross tenants, workspaces, users, teams, or strict permission boundaries?
Do facts change while the system runs?
Does useful relevance depend on relationships, and is the candidate context larger than the model's window?

Step 2: Map active obligations to missing capabilities

If accountability is live, can the system reconstruct state transitions and the exact context used at the time?
If historical truth is live, can the system answer as-of questions without data loss?
If isolation is live, is strict authorization enforced before context ever reaches the model?
If current truth is live, can stale facts be aggressively invalidated or superseded?
If constrained selection is live, does retrieval jointly respect relevance, relationships, permissions, and temporal validity?

If all five requirements are active, the context layer needs all five primitives to satisfy them. If fewer are active, a simpler stack may satisfy the context-layer requirements.

Next steps

A stateful agent context layer delivers the right context when agents act and lets you reconstruct why that context was used. Required capabilities vary by application, but guarantees must remain explicit.

If your agents need connected, evolving, and permission-aware context across systems and time, talk to the HydraDB team.

FAQ about stateful agent context layers

What are the five primitives of a stateful agent context layer?

The five primitives are connected state, episodic history, temporal truth, permission-aware provenance, and multi-signal assembly. Together, they help an AI agent retrieve context that's relevant, authorized, current, traceable, and connected to the active task.

When does an AI agent need a stateful context layer?

An AI agent needs a stateful context layer when it retains consequential context and activates requirements such as accountability, historical truth, tenant isolation, current truth, or relationship-aware selection. The layer needs the capabilities mapped to whichever of those are actually active.

What is the difference between current state and temporal truth?

Current state shows what's true now. Temporal truth answers what was true at a specific point in the past. That matters when an audit, replay, or review asks an as-of question after the underlying facts have changed.

Why is permission-aware provenance important for AI agents?

Permission-aware provenance combines authorization before model exposure with records of each retrieved item's source, owner, and permission boundary. Answer-level attribution additionally requires model, prompt, output, tool-call, and execution traces.

What is multi-signal assembly in an agent context layer?

Multi-signal assembly selects context using multiple signals at once, including semantic relevance, permissions, temporal validity, provenance, and relationships to the active task.

Is an agent context layer the same as agent memory?

No. Agent memory is one application of persistent context. The context layer is the underlying infrastructure that governs what's stored, updated, authorized, traced, and selected for action across all workflows.

Is vector search enough for a stateful agent context layer?

Sometimes. Vector search is enough for semantic recall over flat, static, authorized content. It's not enough by itself when relationships, temporal state, provenance, and permission-aware selection are active.

Do all five primitives need to live in one database?

No. The capabilities can live in one integrated substrate or across a coordinated modular stack, provided the components share identity and version semantics and collectively enforce authorization, provenance, temporal validity, and invalidation invariants.

Are the five primitives sufficient for agent correctness?

No. They only cover context-layer obligations. They don't ensure model behavior, tool reliability, prompt quality, application policy design, or end-to-end agent evaluation.

HydraDB vs Zep: Managed Context Platform vs Programmable Graph Database

M C — Fri, 14 Aug 2026 20:12:36 +0000

Zep and HydraDB both use temporal graphs, but they ask engineering teams to build at different layers. Zep packages users, threads, extraction, and Context Blocks into a managed context platform. HydraDB exposes the graph database underneath, so your team can define its own ontology, data boundaries, and workflows.

If your main problem is cross-session conversational memory, Zep offers the shorter path. If memory is one part of a larger company-wide context system, the database layer matters more than the memory API.

TL;DR

Choose Zep when you want a managed context platform with built-in users, threads, temporal extraction, and Context Blocks.
Choose HydraDB when you want to define your own application model on a programmable graph database that serves memory, company knowledge, workflow context, and agent action history.

Managed context platform or programmable graph database?

Zep is a managed context platform with built-in application conventions: users, threads, extraction, Context Blocks, and graph APIs.

Zep created Graphiti, an open-source temporal knowledge graph framework. The managed Zep service runs Graphiti inside a system backed by Zep's proprietary Context Graph Engine.

HydraDB starts at the database layer. Your application maps its graph and retrieval primitives to users, companies, projects, workflows, and domain objects.

Zep provides the managed context workflow. HydraDB gives your team the programmable graph database and context APIs to define the application model.

What each product provides

Layer or responsibility	Zep	HydraDB
Product layer	Managed context platform with built-in application conventions	Programmable graph database and context substrate
User and conversation model	Built-in users, threads, messages, and user-level memory	Databases and collections that the application maps to customers, users, teams, projects, or environments
Graph construction	Managed temporal graph extraction from messages, text, and JSON	Automatic graph extraction or explicit entities and relations through Bring Your Own Graph
Custom graph structure	Up to 10 custom entity and 10 custom edge types per graph or project, with one classification per node or edge and optional strict ontology	Application-supplied entities, relations, predicates, namespaces, relation context, and optional temporal details
Retrieval	Automatic Context Blocks for user graphs, plus graph search and direct node, edge, and episode access	Hybrid semantic and BM25 retrieval, metadata filtering, graph traversal, and returned graph paths
Context delivered to the model	Automatic Context Block for user graphs; direct search and custom assembly for standalone graphs	Retrieved chunks, sources, and graph context for the application to place in its agent or model prompt
Storage engine	Bundled proprietary Context Graph Engine	Graph database built on object storage
Main engineering trade-off	Adopt Zep's users, threads, extraction pipeline, and Context Block conventions	Define the application model and how the graph fits the product

What Zep handles for your application

Zep handles the user-memory loop from ingestion to retrieval. You send messages, text, or JSON. Zep extracts entities and facts, constructs a temporal knowledge graph, and returns a Context Block for the user. A user graph aggregates context across that user's threads, and thread.get_user_context() selects the context most relevant to the current thread.

Developers can define custom entity and edge types, disable the default ontology, and enable strict ontology during ingestion. Zep limits a graph or project to 10 custom entity types and 10 custom edge types, with up to 10 fields per model. Each node or edge receives one classification, and ontology changes do not automatically re-extract existing data.

You configure graph construction, users, threads, context assembly, and the engine inside Zep's model rather than defining each layer yourself.

What HydraDB leaves under your control

HydraDB handles database isolation, asynchronous ingestion, indexing, graph construction, and hybrid retrieval. One query pipeline combines semantic search, BM25, metadata filters, and graph traversal. HydraDB returns retrieved context rather than a final model answer, so your application decides how to assemble context for the agent.

Your team chooses between two graph construction paths:

Automatic extraction. HydraDB extracts entities and relations during ingestion and traverses them during retrieval.
Bring Your Own Graph. You send explicit entities and relations with each source and skip LLM graph extraction for that source. HydraDB stores and queries the supplied graph in the same shape as an extracted graph.

Bring Your Own Graph fits teams that already maintain an ontology, curated knowledge graph, database export, or deterministic relationship model. You choose the entity types, predicates, namespaces, and relation metadata instead of asking an extraction model to infer them.

HydraDB isolates customers or environments through separate database boundaries. Collections scope data to teams, workspaces, projects, or users within those boundaries. A B2B application can keep shared company knowledge and user-specific memory in the same context system while keeping them in separate databases.

What your team still owns on HydraDB

HydraDB does not supply Zep's user and thread data model, so your team owns several application-level decisions:

The application-level model for users, threads, workflows, and business objects
The ontology and deterministic relationship rules used with Bring Your Own Graph
The entity-resolution and conflict rules for graph state the application supplies
The prompt, agent, and user experience that consumes retrieved context
The evaluation logic for deciding whether the returned context supports the next action

Automatic extraction and retrieval remove infrastructure work, but your application still defines how users, workflows, permissions, and domain objects map to the graph.

Where object storage changes the architecture

HydraDB separates durable graph state from compute. It keeps hot data in memory, uses NVMe for warm data, and retains colder graph data on object storage.

This design moves retained graph history off provisioned memory and NVMe tiers as it cools. Cold reads introduce object-storage latency, so the database must manage caching, prefetching, and data placement.

The architectural choice matters when the graph extends beyond one user's conversation history. An enterprise ontology, company brain, or agent-action graph can cover documents, tickets, people, projects, permissions, decisions, and years of events. Storage then becomes part of the product decision.

Zep bundles storage and compute inside its managed service. HydraDB separates them, allowing teams to scale durable graph storage independently from the compute and cache tiers used for retrieval.

Beyond agent memory: ontologies, company brains, and agent actions

HydraDB supports agent memory as one application of its graph database, alongside ontologies, company brains, and agent workflows.

Ontologies

Your ontology defines the entities, relationships, and rules that matter to the business. A support system models accounts, tickets, products, incidents, and owners. A clinical system models patients, providers, consent, orders, and evidence. Those domains need different graph structures.

When these relations must be deterministic, Bring Your Own Graph lets you supply the domain graph directly while retaining automatic extraction for less constrained sources.

Company brains

A company brain connects documents, conversations, projects, people, decisions, and application data. Its graph has to preserve relationships across sources rather than treat every document as an isolated memory.

HydraDB stores shared knowledge at the database level and scopes team, project, or user context through collections. Its query pipeline combines semantic, keyword, metadata, and graph signals when retrieving context.

Agent actions and shared context

You can represent tool calls, inputs, outputs, approvals, and effects as entities and relations that form an agent decision trace alongside the context that produced an action. Multiple agents can query and write within the same database and collection scopes. Your application still defines coordination and conflict rules for concurrent actions.

Zep supports standalone graphs for shared data. Its automatic Context Block applies to user graphs, so applications search standalone graphs separately and combine those results with user context.

How both systems handle changing facts

Zep and HydraDB both model context that changes over time. The difference is who controls the update model.

Zep stores created_at, valid_at, invalid_at, and expired_at on facts. Its extraction pipeline compares new information with existing graph data to determine whether a new fact supersedes an earlier one.

HydraDB's published architecture models knowledge as versioned, relational, and time-aware state through a Git-style temporal graph. You can use HydraDB's extraction pipeline or provide explicit relations through Bring Your Own Graph. In the public BYOG API, applications may attach an optional temporal_details field to each relation.

Can you build agent memory on HydraDB?

Yes. HydraDB publishes a LongMemEval-s evaluation that tests long-term interactive memory across extraction, preference, multi-session reasoning, temporal reasoning, and knowledge updates.

LongMemEval-s evaluation	HydraDB, Gemini 3.0 Pro	Zep baseline, GPT-4o
Overall accuracy	90.79%	71.2%
Temporal reasoning	90.97%	62.4%
Knowledge update	97.43%	83.3%

The evaluation demonstrates an agent-memory implementation on HydraDB. HydraDB used Gemini 3.0 Pro, while the cited Zep baseline used GPT-4o. The scores measure complete system configurations, including each model, prompt, extraction pipeline, and retrieval setup.

When to choose Zep vs HydraDB

Use Zep when:

You want managed users, threads, memory ingestion, temporal graph construction, and Context Blocks.
Your main problem is cross-session agent memory or personalized context.
You want to configure a managed system instead of designing the database and application model around it.
Zep's extraction ontology and graph APIs fit your domain model.

Use HydraDB when:

You want a graph database to serve as the foundation for your context system.
You need to supply explicit entities and relations or combine automatic extraction with a curated graph.
Your context spans memory, company knowledge, ontologies, workflow context, and agent action history.
You want databases and collections to map directly to customer, workspace, team, project, and user boundaries.

FAQ

What's the main difference between HydraDB and Zep?

Zep is a managed context platform with built-in application conventions. HydraDB is a programmable graph database for teams defining their own application model and context systems.

Are Zep and HydraDB both graph-native?

Yes. Both use temporal graphs and expose graph APIs. Zep packages them inside a managed context platform, while HydraDB exposes the programmable graph database underneath.

Can HydraDB replace Zep directly?

Not at the same API layer. Zep supplies users, threads, and automatic Context Blocks. HydraDB supplies the graph database and retrieval primitives, while your application defines those product-level workflows.

Does Zep support custom ontologies and shared graphs?

Yes. Zep supports custom entity and edge types, optional strict ontology, user graphs, and standalone graphs. Its managed model limits a graph or project to 10 custom entity types and 10 custom edge types, with up to 10 fields per model and one classification per node or edge.

Is HydraDB only a low-level graph store?

No. HydraDB also handles ingestion, automatic graph extraction, hybrid retrieval, metadata filtering, graph traversal, and response shaping. Bring Your Own Graph lets you replace extraction with explicit entities and relations for selected sources.

What does your team build when using HydraDB for agent memory?

Your team defines how databases, collections, entities, and relations map to the product. You also own the agent, prompt, user experience, and application-specific policies around the retrieved context.

Which option fits a chatbot that needs cross-session memory?

Use Zep when the chatbot can adopt its user, thread, and Context Block model directly. Use HydraDB when chatbot memory belongs to a larger system with shared knowledge, custom domain relationships, or other graph applications.

How do HydraDB and Zep handle temporal context?

Zep stores four timestamps on facts and lets its extraction pipeline determine whether new information supersedes an earlier fact. HydraDB models versioned, time-aware graph state and accepts explicit BYOG relations with an optional temporal_details field.

Can several agents share context in Zep and HydraDB?

Yes, but the workflow differs. Zep applications search standalone graphs separately from the automatic user Context Block. HydraDB applications map shared and private context across databases and collections. In both systems, your application coordinates concurrent agent actions.

Why does HydraDB use object storage?

HydraDB keeps hot graph data in memory, uses NVMe for warm data, and retains colder graph data on object storage. That keeps retained graph history separate from the compute and local-storage tiers used for query execution and caching.

Graph Engineering: Execution Graphs vs Context Graphs

M C — Thu, 13 Aug 2026 15:59:11 +0000

Peter Steinberger asked, “Are we still talking loops or did we shift to graphs yet?” LangChain replied: “Graph engineering isn't a new idea. It's the latest name for a well-established approach to building reliable agents.”

Graph engineering means representing agent execution as explicit nodes and edges. It extends rather than replaces prompt engineering, context engineering, harness engineering, and loop engineering.

Modern graph frameworks can also persist checkpoints, memory, workflow events, and application-defined data. That persistence can resume a run or preserve information across sessions. It does not define whether two records identify the same customer, what a relationship means, which source is authoritative, or what was true when an agent acted.

An execution graph defines how work moves through the system. A context graph can represent application entities, relationships, sources, and history for domains that require consistent shared meaning. It can be grounded in an application-defined ontology.

Not every agent needs both. The distinction matters when multiple workflows, applications, or teams must interpret and update the same changing domain state.

Key Takeaways

Prompt engineering shapes one inference. Context engineering determines what the model sees. Harness engineering constrains the runtime, loop engineering sustains iterative work, and graph engineering coordinates branches between agents and tools.
An execution graph answers what runs next. A context graph represents what the system knows across entities, sources, workflows, and time.
Persisting checkpoints, transcripts, or application data does not create a shared domain contract. Durable agent state still needs an application-owned ontology, stable identity, temporal validity, provenance, permissions, and safe update semantics.
A separate context graph becomes useful when multiple workflows or applications share changing domain facts. HydraDB can extract relationships automatically or ingest an application-supplied graph without imposing a fixed ontology.

How Graph Engineering Relates to Prompt, Context, Harness, and Loop Engineering

Prompt engineering shapes one inference

Prompt engineering steers a single inference. Role definitions, few-shot examples, output constraints, and task decomposition all shape what the model does with that request.

The model can also draw on knowledge encoded in its weights. Retrieval for current information, memory for continuity, iteration for sustained work, and a persistence layer for durable state all depend on the surrounding system.

Context engineering determines what the model sees

Context engineering decides what the model sees on the next inference. RAG pipelines, token budgeting, retrieval ranking, memory selection, and context compression bring current application data into that request.

In a study of 18 models, including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3, Chroma found that performance became increasingly unreliable as input length increased, even on deliberately simple retrieval and question-answering tasks.

Reliability is only half the problem. Putting information in a context window doesn’t make it durable or authoritative. A retrieved document can be stale, and a compressed summary can lose the details that made it trustworthy. A transcript can preserve text without ever resolving it to a stable domain entity. None of these mechanisms determines which record the application should treat as canonical.

Harness engineering enforces runtime behavior

Harness engineering controls the environment around an agent. It can enforce runtime constraints independently of the model, set verification gates, scope available tools, and preserve progress across sessions. A harness can keep plans in files, use git to record changes, run tests before accepting work, and stop an agent when it enters an unproductive loop.

The application still has to define what each file, commit, and checkpoint means.

Loop engineering sustains iterative work

Loop engineering replaces repeated human prompting with an automated plan, execute, observe, verify, and retry cycle. Addy Osmani wrote: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Building that system usually means propose-run-check-retry cycles, verifier separation, tool use, and explicit stop conditions.

A loop can save progress to files, git, databases, or framework memory. But persistence isn’t verification. Osmani also wrote: “Verification is still on you.” An unattended loop can repeat errors without human intervention, and persisting those errors does not make them trustworthy.

Graph engineering coordinates execution

Graph engineering makes control flow explicit. Nodes and edges support routing, parallelism, fan-out and fan-in, node-level scoping, conditional transitions, and human approval as a step in the workflow. A Researcher can feed a Writer, whose work is checked by a Reviewer, without placing the entire workflow in one linear context.

Execution Graphs and Context Graphs Solve Different Problems

An execution graph and a context graph can use the same database or runtime, but their nodes and edges represent different things.

Dimension	Execution graph	Context graph
Primary question	What runs next?	What does the system know?
Typical nodes	Agents, tools, steps, routers, approvals	Customers, contracts, incidents, claims, policies
Typical edges	Routing, branching, retry, dependency	Owns, governs, caused, approved, supersedes
State	Checkpoints and branch results	Facts, relationships, sources, decisions, history
Meaning comes from	Workflow definition	Application-owned ontology
Typical lifetime	Run, thread, or long-running workflow	Sessions, workflows, applications, and frameworks

A workflow graph can coordinate five agents successfully while all five write inconsistent representations of the same customer. The application still has to reconcile their results into one canonical domain model.

Persistence Does Not Create a Domain Contract

State category	Typical mechanisms	Primary purpose	What still needs explicit design
Execution state	Graph checkpoints, workflow histories, retry metadata	Resume and coordinate work	Domain identity, validity, and cross-workflow semantics
Session state	Conversation stores, thread history, scratchpads	Preserve interaction continuity	Canonical facts, deduplication, and authority
Agent memory	Facts, preferences, summaries, episodic records	Influence future agent behavior	Provenance, conflict rules, permissions, and application-wide consistency
Durable domain state	Application databases, event logs, temporal models, context graphs	Represent business truth across systems and time	Schema ownership, migration paths, and framework independence. Typically chosen for the workload.

LangGraph uses Checkpointers for thread snapshots and Stores for application-defined data across threads. Temporal reconstructs workflow state from ordered Event History. OpenAI Agents SDK Sessions retain conversation items. Google ADK MemoryService provides searchable knowledge across sessions. CrewAI Memory extracts facts with scopes and source tags.

These frameworks can persist state beyond a process lifetime. Some also offer in-memory implementations.

A LangGraph Store can hold a customer record, a Temporal Workflow can carry business data, and a file in git can represent an approved plan. If the orchestrator's internal schema is the only system of record, domain state inherits the runtime's namespacing, lifecycle, concurrency model, and migration constraints.

A domain-state contract answers five questions:

Can two agents update the same entity safely?
Can the system identify the same customer across CRM, support, and billing?
Can it distinguish current truth from historical truth?
Can every consequential claim be traced to a source?
Can state move to a different framework without replaying every transcript?

Agent memory is one part of application state. The CoALA taxonomy describes working memory plus three long-term memory types: episodic, semantic, and procedural. Agent-memory products differ substantially in how they handle provenance, temporal validity, permissions, and concurrent writes. Cross-session recall still does not guarantee those properties.

What Breaks When Workflow State Becomes Domain State

Checkpoints resume work. Transcripts preserve conversation continuity. Vectors support semantic recall. Event logs preserve history. Problems start when an application uses a checkpoint as a fact store, a transcript as an approval record, or a vector index as an event log.

State loss on restart

LangGraph's MemorySaver and InMemorySaver keep checkpoints in RAM, so a process restart loses them. Using an in-memory saver when restart recovery is required is a deployment error. Persistent backends are available, but their scope and backing-store guarantees must be chosen explicitly.

Session history mistaken for domain state

A customer approval stored only in a transcript is history, not a structured domain record. An OpenAI Agents SDK SQLiteSession lets another workflow read the stored conversation items. It doesn’t extract an approval object, deduplicate facts, define which source is authoritative, or tell downstream systems how to enforce the approval. A preference buried in turn 47 is persisted, but another system still needs a defined way to identify, validate, and apply it.

Concurrent writes without convergence rules

Two agents update the same shared block, and both complete successfully. Under last-writer-wins semantics, one intent disappears.

Letta replaces an entire shared memory block during a direct modification and resolves concurrent modifiers with last-writer-wins semantics. When lost updates are unacceptable, successful task completion is not enough. The write path needs ownership, version checks, or conflict detection.

History destroyed by unversioned updates

If an application overwrites a fact without preserving its previous value, source, and validity interval, it can’t reconstruct what was recorded at the time of a decision. A credit score, contract status, or policy value can remain current while its decision-relevant history disappears. Storage exists, but the update destroyed the history.

Unbounded context bloat

Passing growing execution-history payloads between nodes increases serialization cost and can increase latency. Token use rises only when those payloads are inserted into model context. ActiveWizards recommends keeping state bounded and storing large payloads externally while passing references through workflow state. This bounding matters because PostgreSQL locks the entire row when an update changes a JSON document. Updating one shared JSON row can increase contention when many agents write to it.

The Ontology and Guarantees Behind Durable Agent State

A domain model or ontology is the shared vocabulary that defines which kinds of entities, relationships, properties, and rules exist. It gives records consistent meaning across agents and applications. It does not have to be a formal OWL or RDF model. A versioned application schema with typed relationships can be enough for a bounded domain.

The ontology supplies meaning, not durability. The state layer still needs stable identity, temporal validity, provenance, concurrency semantics, permissions, and a lifecycle independent of any one orchestrator. Required guarantees depend on the workload.

Stable entity identity

CRM, support, and billing may assign different source IDs to the same customer. The domain model needs a stable identity that resolves those records across systems, frameworks, and time.

Typed relationships

An account has contracts, contacts, incidents, deployments, and prior decisions. Those connections carry domain meaning. Key-value and document stores can encode them, but the application must supply the relationship model and traversal semantics.

Temporal validity

The system needs to distinguish what is true now, what used to be true, and what superseded what. Bi-temporal modeling separates valid time, when a fact applied in the domain, from transaction time, when the system recorded it. Applications need both dimensions when they must reconstruct domain validity and the information available to an agent at a past decision point. Simpler workloads may need only one.

Provenance

Each consequential claim should record where it came from and which transformation or approval produced it. That's provenance, and it's easy to confuse with confidence. Confidence describes how sure a model was, while provenance identifies the source and lineage of the information, so store them separately.

Concurrency semantics

Multi-agent writes require reducers, disjoint ownership, version checks, transactions, or conflict detection. LangGraph requires a reducer when parallel branches can update the same state key. Without one, the runtime raises InvalidUpdateError. Every fan-out and fan-in design needs explicit write and convergence semantics.

Permissions

Access control may need to operate at field, entity, source, tenant, and purpose level. A support agent should not necessarily see the same customer data as a billing agent, even when both operate on the same entity.

Framework independence

LangGraph persists state through its saver and Store abstractions. CrewAI Memory uses its own schema and defaults to LanceDB. Neither storage model is a cross-framework domain contract.

Entity records link to sources, decisions, policies, actors, permissions, and validity intervals. The resulting model is often graph-shaped even when relational tables or a hybrid system store the data. When relationship traversal, cross-source identity, provenance, and scoped access dominate the workload, graph-native context infrastructure can reduce the application code needed to maintain those connections.

Common fields in a durable fact record include:

Tenant and subject identity
Entity type and stable ID
Value or relationship
Source reference
observed_at, valid_from, valid_to, recorded_at
A superseded-record pointer
Author or agent identity
Run and tool-call IDs
Approval and access policy
Schema version
Confidence, stored separately from provenance

Don’t let the structure of a transcript or checkpoint determine the domain schema.

When a Separate Context Graph Is Worth It

Not every agent needs a separate durable state layer.

Anthropic's multi-agent system (Opus 4 lead, Sonnet 4 subagents) outperformed a single-agent baseline by 90.2% on breadth-first research without a shared domain model, but used about 15 times the tokens and was a poor fit for tasks with many shared dependencies.

Cognition initially favored single-threaded agents, then found multi-agent works when writes stay single-threaded and auxiliaries contribute intelligence without mutating shared state. The Ralph pattern carries progress in files and git with fresh model passes; a one-shot agent may never need bi-temporal modeling.

Use a separate context graph or equivalent durable domain-state model when multiple sessions, applications, or teams must identify, authorize, and update the same changing business facts consistently. An agent that processes customer renewals across CRM, billing, and support needs a stable customer identity, current contract state, access rules, source lineage, and safe update semantics.

Production teams already combine several state stores. Replit runs each agent as a Temporal Workflow and isolates failure-prone work in Activities, according to a Temporal case study. In a two-part engineering report, mabl described using Jira labels, Git history, pull requests, repository instructions, and MCP integrations to preserve context across repositories. mabl reported that context drift fell from roughly 40% of failures to under 5%, effectively using those tools as an external state layer.

How to Add a Context Graph Without Replacing Your Orchestrator

Step 1: Audit what you persist today

Walk through checkpoints, session stores, memory services, files, and vector databases. For each record, ask whether a different workflow in a different framework could query it and obtain a useful, trustworthy answer. If not, identify the runtime-specific assumption that prevents it: schema, identity, lifecycle, provenance, or access.

Step 2: Externalize one critical entity

Pick the entity agents interact with most, such as a customer, ticket, deployment, or account. Give it a stable identity, an entity type, a schema, and an application-owned home outside the orchestrator's internal state. Define the relationships that connect it to sources, decisions, policies, and other entities.

Step 3: Add provenance to one decision path

Choose one consequential agent action, such as a refund, escalation, or code merge approval. Record the source, timestamp, approving actor, policy version, relevant inputs, and resulting action. The resulting decision trace connects the evidence, policy, approval, and action so the decision can be reconstructed later.

How HydraDB Supports Application-Owned Ontologies

HydraDB provides graph-native context infrastructure beneath the orchestrator without imposing a fixed application ontology. By default, it extracts relationships during ingestion and stores them as source → relation → target triplets. Queries can return the relevant graph paths alongside ranked chunks, so applications receive both retrieved content and the relationships around it.

When an application already maintains a curated knowledge graph, ontology, or database export, Bring Your Own Graph accepts caller-supplied entities and relations instead of running LLM graph extraction for that source. Entities can include a type, namespace, and external identifier. Relations can include an application-defined predicate, supporting context, and temporal details. The supplied graph persists across re-ingestion and appears in the same graph_context response as extracted relationships.

The application owns the ontology. It defines what entity types and predicates such as CUSTOMER, CONTRACT, OWNS, or SUPERSEDES mean, how records from different systems resolve to canonical entities, and which constraints govern updates.

Graph Engineering Still Inherits Distributed-Systems Problems

Agent systems inherit distributed-systems failures, then add probabilistic reasoning, context limits, and semantic ambiguity.

Retry an ambiguous tool call with an idempotency key. Protect shared-record updates with isolation or merge semantics. Migrate state schemas deliberately. Treat a successful write followed by a failed acknowledgment as a partial failure.

Engineers already know the tools: idempotency, event sourcing, schema evolution, optimistic concurrency, transactions, access control, and lineage.

No ratified, broadly adopted interoperability standard defines a shared domain model for agent memory. The current Model Context Protocol specification defines interoperability for context exchange, including tools, resources, and prompts. It does not define a shared memory model. Early drafts, including the memorywire preprint and the Agent Memory Protocol, cover parts of the problem but remain fragmented.

Until a shared contract emerges, keep durable domain state behind an application-owned interface instead of embedding it in one framework's internal schema. Frameworks change, and the state contract should survive the migration.

Keep your orchestrator. Add a graph-native context layer beneath it. Start building an application-owned context graph with HydraDB.

FAQ

What is graph engineering for AI agents?

Graph engineering is the practice of representing agent execution as explicit nodes and edges. Nodes perform work, call tools, or run agents, while edges define routing, branching, retries, joins, approvals, and stop conditions. It makes the structure of an agent workflow inspectable and controllable.

How is graph engineering different from loop engineering?

Loop engineering designs the cycle that lets an agent plan, act, observe, verify, and retry until it reaches a stop condition. Graph engineering connects one or more of those loops through explicit branches, dependencies, parallel paths, and convergence points. A loop sustains work; a graph coordinates how work moves through the larger system.

How do prompt, context, harness, loop, and graph engineering differ?

Prompt engineering shapes one model response. Context engineering determines what information the model receives. Harness engineering controls the tools, permissions, verification gates, and runtime around the agent. Loop engineering automates repeated work, while graph engineering coordinates multiple steps, loops, agents, and approval paths.

What is the difference between an execution graph and a context graph?

An execution graph represents control flow: which agent or tool runs next, where work branches, and how results converge. A context graph represents domain state: entities, relationships, sources, decisions, and changes over time. The execution graph coordinates work, while the context graph gives that work a shared model of the domain.

Can LangGraph persist durable domain state?

LangGraph Checkpointers persist thread snapshots, and LangGraph Stores can hold application-defined data across threads. Those mechanisms can store domain records, but the application must still define canonical identity, schema, temporal validity, provenance, permissions, and conflict rules. Framework persistence can be part of a durable-state architecture without becoming the domain contract itself.

When do AI agents need an ontology?

Agents need an ontology when several workflows or applications must interpret the same entities and relationships consistently. The ontology defines what concepts such as CUSTOMER, CONTRACT, and POLICY mean and how relationships such as OWNS, APPROVED_BY, or SUPERSEDES should be interpreted. It supplies shared meaning, while the state layer supplies durability and operational guarantees.

When does an AI agent need a separate context graph?

A separate context graph is useful when multiple sessions, agents, or applications must read and update the same changing business facts. One-shot agents and isolated coding workflows can often rely on files, framework state, or a conventional schema. Cross-system workflows need stronger identity, history, provenance, permissions, and concurrency semantics.

How does HydraDB support application-owned ontologies?

HydraDB can extract entities and relationships automatically during ingestion or accept caller-supplied entities and relations through Bring Your Own Graph. Applications control their entity types, namespaces, predicates, and relationship meanings. HydraDB stores and retrieves that graph without requiring every application to adopt the same ontology.

CDC streams vs. materialized views: When to use event streams, queryable state, or both

M C — Thu, 13 Aug 2026 15:38:12 +0000

TL;DR

CDC streams and maintained queryable state solve different problems. Use CDC streams when systems need to react to individual database changes, like inserts, updates, and deletes. Use materialized views, dynamic tables, streaming tables, or maintained tables when applications, dashboards, or APIs need fast access to current, historical, or aggregated state.

Use CDC streams for event-driven workflows, microservice fanout, replay within retention limits, and reacting to changes.
Use maintained queryable state for SQL queries, API lookups, dashboards, joins, aggregates, and current-state views.
Use both when teams need independent event consumers plus query-optimized serving tables.
CDC streams preserve change events only when capture and retention policies keep them. Maintained state preserves business history when the model stores versions or snapshots; some systems separately retain bounded table versions for time-travel or recovery.

What is the difference between CDC streams and materialized views?

A CDC stream is a continuous flow of database change events you use for processing and reaction.

A materialized view or maintained table is a queryable state layer that stores materialized representations: current, historical, or derived tables. Use streams to react, state to query, or both when consumers need each.

What are CDC streams, change feeds, and maintained queryable state?

Teams often conflate source database logs, external event streams, platform-scoped change feeds, and materialized representations.

Maintained queryable state is the umbrella term for persisted, queryable representations derived from changing data. Materialized representations refers broadly to materialized views, materialized tables, dynamic tables, streaming tables, and aggregate tables.

Different systems use different product names, but the core architectural question stays the same: are consumers reading an event history or querying a maintained state?

What are source logs such as WAL and binlog?

Source logs are internal database transaction records used for recovery and replication. Think PostgreSQL write-ahead log (WAL) or the MySQL binlog.

Change data capture (CDC) tools read these logs. But source logs don't serve as a general-purpose downstream fanout layer.

Production CDC commonly starts with an initial consistent snapshot, records the source log position, and then continues by tailing the WAL or binlog from that position. For MySQL sources, Debezium also documents the role of an initial consistent snapshot before streaming from the binlog.

Snapshot mode, source-log retention, and persistent connector offsets are part of the CDC recovery contract. Connectors that reconstruct historical table schemas, such as Debezium's MySQL connector, also require durable internal schema-history storage. If the WAL or binlog position needed for recovery has been purged, the connector may require a new snapshot or another rehydration path.

What are external CDC streams?

CDC streams are extracted database changes (inserts, updates, and deletes) published to an external event stream or broker.

Debezium change records use a Kafka message key plus a value envelope. The envelope includes an operation type, timestamps, and source metadata; before and after contents vary by operation and source configuration, and transaction metadata is optional. In Kafka, ordering is guaranteed within a topic partition. Ordering by key follows when records with that key are routed to the same partition; there is no global order across partitions or table topics.

Replay depends on topic retention and cleanup policy, any supported remote storage, external archives, and operational policy. Standard implementations include Debezium CDC events in Kafka topics, managed CDC connectors, and Kafka-compatible event streams.

What are platform-scoped change feeds?

Platform-scoped change feeds are change-tracking mechanisms within a specific warehouse or lakehouse. Examples include Snowflake Streams and Databricks Change Data Feed. Lakeflow Spark Declarative Pipelines is instead a managed batch and streaming pipeline framework that can maintain streaming tables and materialized views; it is not itself a change feed.

These feeds support incremental processing inside their respective platforms. Their retention, replay capabilities, and fanout semantics differ significantly from those of external, durable event streams.

What are streaming database changelogs?

Streaming database changelogs are update streams used by systems like Materialize or RisingWave to maintain query results or expose downstream changes.

The exact semantics depend on the engine and whether the changelog is purely internal state maintenance or externalized for downstream consumption.

What is maintained queryable state?

Maintained queryable state refers to persisted query results derived from applying changes over time. These representations can take several forms:

Current state / SCD type 1: One row per business key with the latest known value.
Historical state / SCD type 2 / snapshots: Explicitly modeled history using versions, validity windows, or periodic snapshots.
Derived state / aggregates: Maintained metrics like counts, totals, rollups, and denormalized tables.
Streaming database materialized views: Continuously maintained SQL views over changing inputs.

Maintained queryable state can preserve history when modeled to do so. But it doesn't automatically preserve every event transition the way a retained CDC stream or changelog can.

Example: Processing a database update as an event vs. querying state

Consider an e-commerce order changing its status from Processing to Shipped.

How does a CDC stream process an update?

A downstream consumer receives an explicit change event containing the transition data. For example:

op: update
order_id: 123
before.status: Processing
after.status: Shipped
ts: 10:01

Because the consumer sees the transition itself, a downstream service can react as soon as the event reaches it, with latency determined by capture, transport, processing, and sink behavior. For example, the service can send a shipping confirmation email, update a fulfillment workflow, or trigger a mobile push notification.

For external side effects like emails, payments, notifications, or HTTP calls, design for retries and duplicate delivery. Use an idempotent destination operation, deduplicate on a stable event or command ID, or atomically coordinate the consumed offset with the external write when the destination supports it. Do not assume that a bare WAL or binlog position uniquely identifies every CDC record.

Replay and backfill paths need careful design. You don't want to re-send customer-facing side effects during a recovery operation.

How does maintained queryable state represent an update?

In this model, a consumer application executes a query against the serving layer:

SELECT status FROM orders WHERE id = 123

The returned result is Shipped. The consumer sees the latest modeled state. They don't necessarily see the fact that the order changed from Processing to Shipped exactly at 10:01.

To query the transition or its exact timing in a state-based architecture, the design must explicitly include historical state, SCD Type 2 records, periodic snapshots, audit tables, or retained CDC events.

The stream is useful for reacting to the change, while the maintained table, view, or dynamic table is useful for lookup and analysis.

![][image1]

CDC streams vs. maintained queryable state: Five production comparison points

CDC streams and maintained queryable state aren't interchangeable.