DEV Community: M C

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.