Neon and ClickHouse Managed Postgres are managed PostgreSQL services for transactional applications and AI agent backends. ClickHouse’s acquisition of Xata aims to add scale-to-zero and copy-on-write branching to ClickHouse Managed Postgres. An agent run can read conversation history, retrieve context, update a checkpoint, and record tool results. Concurrent runs put frequent reads and writes on the database, and accumulated execution data creates demand for analytics.
This comparison covers transactional performance, retrieval, agent tooling, development workflows, pricing, analytics integration, availability, recovery, and migration across the two services.
TL;DR
- Choose Neon for applications and AI agent platforms where compute autoscaling, scale-to-zero, and fast copy-on-write branching prove decisive.
- Choose ClickHouse Managed Postgres for performance-critical AI agent and application workloads, agent-assisted database operations, or a native path to ClickHouse analytics. The Xata acquisition aims to add scale-to-zero and copy-on-write branching.
Neon vs ClickHouse Managed Postgres at a glance
| Decision factor | Neon | ClickHouse Managed Postgres |
|---|---|---|
| Best-fit workloads | AI agent and application backends with variable compute demand, idle periods, and frequent branching | AI agent and application backends with performance-critical workloads, operational tooling, and growing analytical demand |
| Transactional storage | Separated compute and storage, with write-ahead log (WAL) durability | Local NVMe attached to the Postgres server |
| Scaling and idle behavior | Scale-to-zero for compute sizes up to 16 compute units (CU). A connected logical-replication subscriber keeps compute active | Provisioned compute with manual vertical scaling. Storage autoscales on Scale and Enterprise. Scale-to-zero planned through the Xata acquisition |
| Branching | Copy-on-write clones at metadata speed without parent load | Backup-based branches restored with WAL replay. Independent deployments available in minutes. Copy-on-write branching planned through the Xata acquisition |
| Analytics integration | ClickHouse through ClickPipes, or Databricks through Lakeflow Connect | Native ClickPipes integration with independently scaled ClickHouse analytics in the same cloud platform. pg_clickhouse preserves PostgreSQL query access |
| Pricing model | CU-hours, storage, history, branches, and egress metered separately | Bundled CPU, RAM, and NVMe. Native CDC included on AWS |
| High availability | Multi-AZ storage without continuously running standby compute | Automatic failover with configured standbys: two for synchronous replication, one for asynchronous replication |
| Migration | Standard PostgreSQL tools for importing data | Managed ClickPipes migration for initial load plus change data capture (CDC) |
PostgreSQL versions, cloud availability, and plans
Neon (branded Lakebase Postgres on Neon) supports PostgreSQL 14 through 18 across eight AWS regions. Azure no longer accepts new projects. The Neon plans are Free, Launch, and Scale (Business is legacy).
ClickHouse Managed Postgres is a production-ready managed PostgreSQL service on AWS and GCP within ClickHouse Cloud. It uses local NVMe storage and supports PostgreSQL 17 and 18, with 17 as the service-creation API default. The ClickHouse organization tiers are Basic, Scale, and Enterprise. See cloud and region availability for deployment locations. Xata acquisition plans to integrate scale-to-zero and copy-on-write branching into the service.
AI agent requirements: state, retrieval, and operations
Application agents use the database for state and context during execution. Coding and database agents also need interfaces to provision resources and investigate problems.
| Agent requirement | Neon | ClickHouse Managed Postgres |
|---|---|---|
| Persist runtime state | PostgreSQL persistence for sessions, task progress, memory, and application records, with compute managed separately from storage | PostgreSQL on local NVMe for frequent checkpoint updates, memory writes, and tool-result recording |
| Retrieve context | pgvector and Lakebase Search for vector, BM25 keyword, and hybrid retrieval | pgvector, vchord, and BM25 retrieval extensions for vector, keyword, and hybrid retrieval. For larger-scale retrieval, pg_clickhouse pushes vector and search queries to ClickHouse |
| Handle concurrent activity | Pooling, compute autoscaling, and serverless connectivity for changing worker demand | Bundled transaction pooling for bursts of short-lived workers and provisioned capacity for sustained activity |
| Provision agent infrastructure | APIs, SDKs, and agent tools for creating databases and branches within product workflows | API, client library, CLI, and Terraform for programmatic provisioning and management |
| Investigate database behavior | Agent tools, MCP, CLI, and SQL diagnostics for inspection and management | ClickHouse Agents, MCP, clickhousectl CLI, Query Insights, logs, and metrics for SQL investigation and tuning assistance |
| Analyze accumulated data | PostgreSQL reporting and asynchronous CDC paths to ClickHouse or Databricks | Native asynchronous replication to independently scaled ClickHouse analytics, with PostgreSQL query access through pg_clickhouse |
A Postgres-only deployment works while state, retrieval, and reporting meet the application's targets. Add dedicated analytical (OLAP) capacity when scans and aggregations create persistent contention or need more resources than the transactional service can spare.
Transactional performance and scaling
Transactional throughput and query latency shape the performance of application and AI agent backends.
ClickHouse Managed Postgres targets performance-critical transactions. Local NVMe handles ingestion, updates, and vacuum work while reducing tail latency for disk-bound workloads. Neon separates compute from durable storage, so it can adjust or suspend compute independently as demand changes.
Neon storage, autoscaling, and scale-to-zero
In Neon's storage architecture, Safekeepers replicate WAL via Paxos, Pageservers materialize pages, and object storage holds history. A cache miss may require fetching a page from the storage layer.
Scale-to-zero applies to computes up to 16 CU. Compute activation generally takes a few hundred milliseconds, with cold buffers afterward. Neon autoscaling adjusts running compute within a configured range spanning at most 8 CU, without a restart.
ClickHouse Managed Postgres local NVMe and instance scaling
Local NVMe storage is physically attached to the Postgres server, so reads that miss the cache avoid a network page request. For agent backends, that storage serves cache-miss context reads and frequent memory or checkpoint updates. Commit latency also depends on the selected zero-, one-, or two-standby configuration.
ClickHouse Managed Postgres uses manual vertical scaling: it provisions a replacement standby from backups, replays WAL to catch up, and performs a controlled failover. The switch interrupts connections for roughly 30 seconds. On Scale and Enterprise, storage autoscaling replaces the server when usage reaches 90%.
Neon vs ClickHouse Managed Postgres benchmark results
ClickHouse Managed Postgres delivered 3.4x Neon's transactional throughput in the tested PostgresBench configuration. Both endpoints had 16 vCPUs and 64 GB RAM in AWS us-east-2, with an approximately 500 GB database and provider-default settings. ClickHouse ran without standbys.
| Service | PostgreSQL version | Run date | Mean transactions per second |
|---|---|---|---|
| ClickHouse Managed Postgres results | 18.3 | March 18, 2026 | 26,104.81 |
| Neon results | 18.2 | March 11, 2026 | 7,692.91 |
PostgresBench measures transactional throughput, not complete agent-run latency. It does this by measuring mean throughput across three 600-second runs per service using pgbench's TPC-B-like workload with 256 clients, 16 threads, and prepared queries.
Postgres performance in Socialpruf's workload
Socialpruf's Postgres queries ran faster after its production workload moved from Neon to ClickHouse Managed Postgres.
| Outcome | Workload context |
|---|---|
| Roughly 30% faster Postgres queries overall | Socialpruf's production workload after migration |
| Selected Postgres queries improved by up to 5x | Before-and-after observations for selected queries in the same customer workload |
Test steady-state query latency, Neon's first-query latency after suspension, and connection recovery during ClickHouse Managed Postgres scaling separately.
Agent and developer workflows: retrieval, branching, and operations
Branching, retrieval, and connection behavior shape how applications and agents use Postgres. APIs and diagnostic tools also let coding and database agents provision resources, inspect data, and investigate performance.
| Capability | Neon | ClickHouse Managed Postgres |
|---|---|---|
| Branch mechanism | Copy-on-write clone from current or historical state, without adding load to the parent | Backup restore plus WAL replay from a selected point in time into an isolated deployment |
| Branch availability | Metadata-level creation | Most branches become available in minutes. Larger databases take longer |
| Deployment and use case | Agent platforms with databases per app or workspace. Isolated branches for agent changes, evaluations, and previews | Independently sized branches for development, staging, agent evaluations, debugging, and recovery |
| Branch billing | Free and Launch include 10 branches per project. Scale includes 25. Excess branches cost \$1.50/branch-month | Instance pricing for each independently sized deployment |
| Connection pooling | Transaction-mode PgBouncer accepts up to 10,000 client connections | Transaction-mode PgBouncer with parallel processes |
| Shared extensions | PostGIS, pgvector, and pg_cron | PostGIS, pgvector, and pg_cron |
| Retrieval capabilities | pgvector and Lakebase Search for vector, BM25 keyword, and hybrid retrieval | Vector and BM25 extensions for vector, keyword, and hybrid retrieval: pgvector, vchord, vchord_bm25, and pg_tokenizer |
| Serverless and edge clients | HTTP/WebSocket serverless driver | PostgreSQL drivers and pooling. Cloudflare Workers through Hyperdrive |
| MCP support | Hosted MCP server | Remote MCP server for Managed Postgres |
| Agent and automation interfaces | API, SDK, and agent tools and CLI | ClickHouse Agents, clickhousectl, OpenAPI, Rust API client, and Terraform |
Both services support programmatic provisioning for application and agent platforms. ClickHouse Managed Postgres exposes service creation and connection credentials through its API. Applications can create multiple databases and schemas within each instance using standard PostgreSQL commands. Its backup-based branches support isolated migration, index, and retrieval testing from a selected point in time, with each deployment sized independently.
Connections and extension compatibility
Transaction pooling lets concurrent clients share a smaller set of backend connections. ClickHouse Managed Postgres runs multiple PgBouncer processes behind one endpoint, which helps handle bursts of short-lived clients.
Neon's pooled client connections share backend limits that depend on compute size: for example, 419 at 1 CU and 4,000 at 9+ CU. ClickHouse Managed Postgres defaults to 500 direct connections, and PgBouncer multiplexes a larger pool of clients onto those backends.
Both services support protocol-level prepared statements used by database drivers. Use direct Postgres connections for SQL-level prepared statements, session-level advisory locks, and tools such as pg_dump.
Both services work with standard PostgreSQL drivers and ORMs. The Neon serverless driver connects JavaScript and TypeScript workers over HTTP or WebSockets, including serverless and edge environments. HTTP supports individual queries and non-interactive transactions, while WebSockets support sessions and interactive transactions.
ClickHouse Managed Postgres supports serverless and edge applications, including Cloudflare Workers through Hyperdrive with node-postgres for reads and writes.
Neon's pg_cron jobs run only while compute stays active.
ClickHouse Managed Postgres preinstalls pg_clickhouse for remote ClickHouse execution, includes pg_stat_ch for query-level telemetry, and provides full database superuser access. Neither product offers host OS access or unrestricted binary installation.
Vector and keyword retrieval
ClickHouse Managed Postgres supports vector retrieval through pgvector and vchord, with vchord_bm25 and pg_tokenizer providing BM25 ranking and text processing. These retrieval extensions let teams build semantic and keyword search alongside transactional application data. When retrieval workloads outgrow PostgreSQL capacity, teams can store vectors and search indexes in ClickHouse and query them through PostgreSQL via pg_clickhouse. ClickHouse handles vector and text search at scales beyond what PostgreSQL extensions support, while the application retains its PostgreSQL interface. Semantic matching finds relevant concepts, while keyword ranking retrieves exact names, identifiers, and codes. Teams configure the indexes and combine vector and BM25 rankings in SQL or application code for hybrid retrieval.
Neon's Lakebase Search adds vector, BM25 keyword, and hybrid retrieval through lakebase_vector, lakebase_text, and lakebase_tokenizer on PostgreSQL 16 and later. Neon also supports pgvector. Copy-on-write branches preserve search indexes without rebuilding them, so teams can compare retrieval changes against independent copies of the same data.
For either service, evaluate retrieval with the application's embedding dimensions, filters, update rate, recall target, index memory, and latency objective. Use the results to choose the retrieval configuration.
Agent tooling and database diagnostics
ClickHouse Agents inspects schemas, runs read-only SELECT queries, and combines service metrics, slow-query patterns, and query plans to recommend tuning changes. These diagnostics help identify whether slow application requests or agent steps stem from retrieval queries, state updates, or database resource pressure. It can also query Postgres and ClickHouse independently and combine the findings.
ClickHouse Managed Postgres supports external agents and IDEs through the ClickHouse Cloud remote MCP server. Agents can query PostgreSQL, inspect service metrics, and investigate slow-query patterns. Enable MCP in the service's Connect panel. Postgres SQL queries require OAuth, and all remote MCP tools provide read-only access.
Query Insights shows slow query patterns, errors, and waits for ClickHouse Managed Postgres in the ClickHouse Cloud console. Searchable PostgreSQL logs support troubleshooting, and Prometheus-compatible metrics connect the service to existing monitoring tools. These features diagnose database behavior. Application instrumentation supplies the agent's prompts, model calls, and complete execution traces.
clickhousectl gives machine-readable access to Postgres metrics, logs, and slow-query patterns, and supports creating and managing ClickHouse Managed Postgres infrastructure. Its SQL-over-HTTP interface provides read-only access and uses OAuth. Authorized CLI commands, OpenAPI calls, and the Rust Cloud API client support programmatic service management. SQL writes use PostgreSQL connections. The Terraform resource supports declarative provisioning, resizing, HA settings, replicas, and PITR creation, with narrower coverage than the API.
Neon's SDK and agent tools let platforms embed selected database operations into their own agents. A workflow can create a branch and return its connection string in one operation. The Neon CLI and hosted MCP server support provisioning, SQL, migrations, and diagnostics. The hosted MCP server targets development and testing. Application agents use normal PostgreSQL connections or the serverless driver for runtime state and retrieval.
Pricing comparison and total deployment cost
The full deployment cost includes the Postgres service, its recovery configuration, and any CDC pipeline and analytical service. Neon bills compute hours, storage, history, branches, and egress separately. ClickHouse Managed Postgres bundles CPU, RAM, and NVMe per instance. On AWS, ClickHouse Managed Postgres includes native CDC at no additional charge. ClickHouse bills AWS network transfer and backup storage separately, above the provisioned disk capacity. ClickHouse also bills the analytical service separately.
An always-active agent backend and a fleet of intermittently used agent-built applications have different cost profiles. With Neon, autoscaling and eligible suspension can reduce compute usage during quiet periods. Account for stored data, retained history, and branch allowances alongside active compute.
For ClickHouse Managed Postgres, size provisioned instances and standbys for workload performance and recovery needs, and budget separately for any analytical service.
Neon pricing model. Neon's Free, Launch, and Scale plans use the following rates.
| Dimension | Free | Launch | Scale |
|---|---|---|---|
| Compute | 100 CU-hours/project/month included | \$0.106/CU-hour | \$0.222/CU-hour |
| Postgres storage | 1 GB/project included, subject to total Free limits | \$0.35/GB-month | \$0.35/GB-month |
| Included branches/project | 10 | 10 | 25 |
| Public egress/project/month | 5 GB | 500 GB, then \$0.10/GB | 500 GB, then \$0.10/GB |
| History window | 6 hours, up to 1 GB of changes/project | Up to 7 days | Up to 30 days |
| Extra paid branches | Not available beyond 10 included | \$1.50/branch-month | \$1.50/branch-month |
ClickHouse Managed Postgres pricing model. Pricing bundles CPU, RAM, and NVMe across 50+ instance configurations. Sizes range from 1 vCPU, 8 GB RAM, and 59 GB NVMe to 96 vCPUs, 768 GB RAM, and 60 TB NVMe. Use the ClickHouse Managed Postgres pricing calculator to compare instance sizes and HA configurations.
ClickHouse Managed Postgres on AWS includes backup storage up to its provisioned disk capacity. Additional backup storage bills at regional ClickHouse Cloud storage rates. Scaling and maintenance can briefly run old and new instances in parallel, producing overlapping charges.
Worked monthly cost comparison: a 100 GB database
A 100 GB database runs for a full month in AWS us-east-1, with no read replicas, extra branches, or analytical destination. Public egress stays within Neon's 500 GB allowance.
Neon runs for 730 active hours at a fixed 1 CU, which provides 4 GB RAM. The ClickHouse configuration uses an ARM c6gd.large instance.
| Configuration or cost | Neon Launch | Neon Scale | ClickHouse Managed Postgres Scale |
|---|---|---|---|
| Primary compute | 1 CU / 4 GB RAM | 1 CU / 4 GB RAM | 2 vCPUs / 4 GiB RAM, ARM c6gd.large |
| Storage | 100 GB | 100 GB | 118 GiB local NVMe included |
| Operating time | 730 active hours | 730 active hours | Full-month calculator estimate |
| Availability | Multi-AZ storage, no standby compute | Multi-AZ storage, no standby compute | Primary only, 0 standbys |
| Compute | \$77.38: 730 x \$0.106 | \$162.06: 730 x \$0.222 | \$95.31, including storage |
| Storage charge | \$35.00: 100 x \$0.35 | \$35.00: 100 x \$0.35 | Included above |
| Compute and storage subtotal | \$112.38/month | \$197.06/month | \$95.31/month |
The ARM c6gd.large primary with no standbys has an undiscounted monthly estimate of \$95.31. With two synchronous standbys, the same instance configuration has an undiscounted monthly estimate of \$285.93. Neon uses multi-AZ storage without dedicated standby compute. Match the availability topology to the application's recovery objectives when comparing production deployments.
Neon restore history adds \$0.20/GB-month on Launch and Scale. These subtotals exclude it. The ClickHouse Managed Postgres subtotal excludes AWS network transfer and excess backup-storage charges that begin on November 9, 2026. Analytical compute carries a separate cost for either source. Each configuration provides enough storage for the database. Size compute separately for the application's latency and throughput targets.
CDC and analytics costs
Postgres workloads feeding ClickHouse analytics use source compute, CDC, network transfer, and analytical capacity.
| Cost component | Neon → ClickHouse | ClickHouse Managed Postgres → ClickHouse |
|---|---|---|
| Source compute | CU-hour charges continue while a connected replication subscriber prevents suspension | Provisioned instance charges cover CPU, RAM, and local NVMe |
| CDC charges | Generic ClickPipes CDC: \$0.10/GB initial load, \$0.20/GB ongoing changes, plus compute starting at \$0.10/hour on ClickHouse Basic or \$0.20/hour on ClickHouse Scale and Enterprise | Native CDC included at no additional charge on AWS |
| Source network egress | Public egress per project: 5 GB/month on Free, 500 GB/month on Launch and Scale, then \$0.10/GB on those paid plans | ClickHouse Cloud transfer rates apply on AWS from November 9, 2026. Keep services in the same region to avoid egress costs. |
| Analytical capacity | Separately provisioned ClickHouse compute and storage | Separately provisioned ClickHouse compute and storage |
ClickHouse analytics bills separately and appears alongside ClickHouse Managed Postgres on a consolidated ClickHouse Cloud bill. Include the required HA configuration, retained history, read replicas, and branches in the full deployment cost.
Native ClickHouse integration and Neon's analytics options
Teams analyze recorded agent runs, tool outcomes, evaluation results, latency, token usage, and costs. Application instrumentation supplies the traces and relationships among model and tool calls.
Application agents also use analytical tools to query historical events and business aggregates when answering questions or completing tasks.
Those scans and aggregations compete with checkpoint updates, retrieval requests, and other application transactions for CPU, memory, and I/O. Independent analytical capacity lets those workloads grow while Postgres maintains the transactional state.
With ClickHouse Managed Postgres, PostgreSQL remains the transactional system of record. A separately provisioned ClickHouse service runs analytical queries on its own CPU, memory, storage, and caches. Teams scale analytical capacity independently while managing both services through the ClickHouse Cloud control plane and a consolidated bill.
Socialpruf moved dashboard analytics to ClickHouse before migrating its transactional Postgres. Its dashboards took 1 to 3 seconds to load before offload. After offload, ClickHouse aggregated millions of rows in milliseconds. The dashboard and aggregation timings measure different operations within Socialpruf's workload.
Neon can feed ClickHouse or Databricks analytics through CDC connectors while keeping transactional Postgres on Neon.
| Analytics path | Integration and setup | Destination and operating model |
|---|---|---|
| ClickHouse Managed Postgres → ClickHouse | Native ClickPipes integration. Logical replication enabled, network access allowed by default, and source connection pre-filled | Separately provisioned ClickHouse analytical service with independent compute and storage. Both services share the ClickHouse Cloud control plane and bill |
| Neon → ClickHouse | ClickPipes, after enabling logical replication and preparing the source | Separately provisioned ClickHouse analytical service within ClickHouse Cloud. Transactional Postgres stays on Neon |
| Neon → Databricks | Lakeflow Connect PostgreSQL connector, currently in public preview | Delta tables in a separate Databricks analytics environment. Transactional Postgres stays on Neon |
ClickHouse Managed Postgres source setup. For manual setup, allow ClickPipes' static IPs in any configured IP filters and provide the instance CA bundle for verified TLS. Connect directly to Postgres rather than through PgBouncer.
Neon to ClickHouse via ClickPipes. Enable logical replication for the Neon project, which changes the project-wide WAL setting and restarts computes. Configure permissions, a publication, and direct rather than pooled connectivity, then create the ClickPipe in ClickHouse Cloud.
A connected subscriber prevents scale-to-zero. Inactive replication slots without progress can be removed after approximately 40 hours. Neon defaults to 10 replication slots and 10 WAL senders. Neon-to-ClickHouse replication uses generic ClickPipes CDC pricing.
Lakebase within Databricks. Lakebase deployed within Databricks provides native lakehouse integration, including Unity Catalog registration and lakehouse workflows. It runs as a distinct deployment from a Neon-hosted project.
Query ClickHouse through PostgreSQL with pg_clickhouse
With configured foreign tables, the pg_clickhouse extension lets applications, ORMs, and dashboards query ClickHouse analytical data through their PostgreSQL connection. ClickPipes moves the data, and pg_clickhouse pushes supported filters, aggregations, and joins to the ClickHouse service. Unsupported operations and parts of mixed plans still execute in Postgres. The two services maintain separate transaction boundaries.
An agent tool can use this PostgreSQL interface to query historical usage, aggregate business records, or retrieve evaluation summaries from ClickHouse while its current task state stays in Postgres. Read current committed state from Postgres when the tool can't tolerate replication lag.
Replication freshness and source load
ClickPipes replication runs asynchronously, so the analytical copy is eventually consistent and can lag committed Postgres changes. The Postgres source handles logical decoding, initial snapshots, WAL retention, and network transfer. Replicated delete events also propagate source deletions to ClickHouse. Retaining analytical data longer requires explicit configuration.
Monitor replication slots and plan how to resynchronize data after an interruption, especially if the source or destination can idle.
High availability, read replicas, and recovery
For AI agent and application backends, recovery determines which acknowledged writes survive a failure and how quickly clients reconnect. Point-in-time recovery (PITR) restores an earlier database state after an erroneous change. Application code handles reconnects and retries. Database recovery doesn't resume an agent workflow or undo actions in external tools.
| Recovery capability | Neon | ClickHouse Managed Postgres |
|---|---|---|
| Availability architecture | Multi-AZ storage on all plans. Compute runs in one AZ | Primary with zero, one, or two HA standbys |
| Standby replication | Storage durability operates without continuously running standby compute | One standby uses asynchronous replication. Two use synchronous replication, with at least one standby acknowledging each commit |
| Failover | Compute recovery depends on the failure type | Automatic with configured standbys. Zero standbys provide no continuously maintained failover target. One asynchronous standby may miss recent commits if the primary fails |
| Read replicas | Read-only computes share the primary's durable storage with asynchronous replication and no hard lag SLO. Free permits up to three per project | Read replicas on Scale offload read-heavy application and reporting queries to independent database copies with separate endpoints. HA standbys can't serve reads |
| Point-in-time recovery (PITR) | Restores a root branch in place, preserving its previous state in a backup branch. Child branches don't support instant restore | Daily full backup plus archived WAL restores into a new instance, leaving the original available |
| Recovery retention | Free: 6 hours, subject to 1 GB of changes per project. Launch: up to 7 days. Scale: up to 30 days | Basic: one day. Scale and Enterprise: seven days |
Neon compute recovery. Typical recovery takes seconds for certain failures, 1 to 2 minutes for node failure, and 1 to 10 minutes for AZ failure. An unresponsive compute endpoint triggers reattachment after five minutes. These timings depend on the failure and don't constitute a single recovery-time guarantee. Applications need reconnect logic, and cache and session state may be lost.
In May 2025, a Neon control-plane failure in us-east-1 blocked new compute starts and activations for hours while already-running databases continued operating.
Read-replica freshness. For ClickHouse Managed Postgres read replicas, WAL ships by default when a 16 MB segment fills or 60 seconds pass, whichever comes first. This interval doesn't guarantee when changes become queryable. Neither service's replica architecture guarantees read-your-writes at a replica endpoint. Support can configure lower-lag replicas by tuning WAL shipping or enabling streaming replication. Streaming adds CPU and network load on the primary.
Restore timing. Neon's root-branch restores typically take a few seconds, with no fixed completion time.
Set a recovery point objective (RPO) for the acceptable data-loss window and a recovery time objective (RTO) for acceptable downtime. Match the production configuration to those targets.
Migrating from Neon to ClickHouse Managed Postgres
Use ClickPipes migration to move from Neon to ClickHouse Managed Postgres through an initial load, ongoing CDC replication, and a controlled cutover.
Standard pg_dump/pg_restore supports a one-time database-object transfer in both directions. It doesn't copy roles, replication slots, server settings, tablespaces, or runtime statistics.
Socialpruf migrated 0.5 TB from Neon to ClickHouse Managed Postgres in a few hours using ClickPipes. The team kept both databases synchronized for a week of testing before completing its production cutover.
Migration and cutover checklist:
- Confirm the target PostgreSQL version, required extensions, and direct versus pooled connection behavior.
- Prepare the new connection settings and replace the Neon Serverless Driver if the application uses it.
- Adapt branch automation for independent, backup-restored deployments and review pg_clickhouse queries.
- After the initial load, stop writes, let CDC catch up, validate the replicated data, and switch application connectivity.
For migration from ClickHouse Managed Postgres to Neon, follow the Neon migration guide using pg_dump/pg_restore and update the connection settings. Review vendor-specific drivers if the application uses them.
When to choose Neon or ClickHouse Managed Postgres
Workload performance. Neon suits AI agent and application backends with changing compute demand. ClickHouse Managed Postgres targets performance-critical workloads on local NVMe, where consistent disk-bound latency matters more than elastic scaling.
Context retrieval. Both services combine PostgreSQL data with vector and keyword retrieval. ClickHouse Managed Postgres also supports shifting retrieval to ClickHouse through pg_clickhouse when workloads outgrow PostgreSQL. Compare their available indexes, filtering behavior, memory needs, and results on your application's data.
Provisioning and branches. Both support programmatic provisioning and isolated database environments. Neon creates copy-on-write branches at metadata speed for frequent environment creation. ClickHouse Managed Postgres creates API-provisioned services and independently sized branches for testing, validation, and recovery. Copy-on-write branching is planned through the Xata acquisition.
Agent operations. Both provide MCP integration, APIs, client libraries, and CLIs. ClickHouse Agents adds SQL and performance investigation across Postgres and ClickHouse. Terraform supports declarative provisioning.
Durability and recovery. ClickHouse Managed Postgres provides automatic failover with configured standbys, including synchronous replication with two standbys. Neon provides multi-AZ storage without continuously running standby compute. Match the configuration to your durability and recovery requirements.
Analytics integration. ClickHouse Managed Postgres pairs transactional PostgreSQL with independently scaled ClickHouse analytics in one managed platform, with analytical data accessible through PostgreSQL. Neon can remain the transactional backend while feeding ClickHouse or Databricks through CDC.
Complete cost. Neon's autoscaling and eligible idle periods reduce compute usage for variable traffic, but a connected CDC subscriber keeps compute active. ClickHouse Managed Postgres bundles CPU, RAM, and NVMe and includes native CDC at no additional charge on AWS.
Choose ClickHouse Managed Postgres for performance-critical AI agent and application backends, with agent-assisted database operations and a native path to independently scaled ClickHouse analytics. The Xata acquisition aims to add scale-to-zero and copy-on-write branching. Choose Neon for applications and AI agent platforms where compute autoscaling, scale-to-zero, and fast copy-on-write branching prove decisive today.
Frequently asked questions about Neon and ClickHouse Managed Postgres
How do Neon and ClickHouse Managed Postgres support AI agent workloads?
Both services provide PostgreSQL persistence for agent state and context retrieval, plus MCP integration and programmatic provisioning. Neon adds compute autoscaling and fast copy-on-write branches for agent applications and platforms. ClickHouse Managed Postgres combines local NVMe, retrieval extensions, agent-assisted database investigation, and native ClickHouse analytics for execution data and analytical tools.
What vector and keyword retrieval options does each service provide?
ClickHouse Managed Postgres supports vector and BM25 keyword retrieval through pgvector, vchord, vchord_bm25, and pg_tokenizer. Teams combine rankings for hybrid retrieval. Neon supports pgvector and Lakebase Search for vector, BM25 keyword, and hybrid retrieval. Both keep retrieval alongside PostgreSQL application data.
Does ClickHouse Managed Postgres outperform Neon?
ClickHouse Managed Postgres delivered 3.4x Neon's transactional throughput in the tested PostgresBench configuration. Both endpoints had 16 vCPUs and 64 GB RAM in AWS us-east-2, with provider-default settings. ClickHouse ran without standbys and maintains the benchmark.
How does Neon pricing compare with ClickHouse Managed Postgres?
Neon meters CU-hours, storage, history, branches, and egress separately. ClickHouse Managed Postgres bundles CPU, RAM, and local NVMe per instance and includes native CDC at no additional charge on AWS. Include HA, CDC, analytical capacity, and transfer costs in the deployment budget.
How does database branching differ between Neon and ClickHouse Managed Postgres?
Neon creates copy-on-write branches at metadata speed without adding load to the parent. ClickHouse Managed Postgres creates independently sized deployments from backups and WAL replay, usually in minutes. Larger databases take longer. Copy-on-write branching is planned through the Xata acquisition. Neon's model supports frequent isolated copies for agent changes, evaluations, and previews. ClickHouse Managed Postgres branches support isolated staging, agent evaluations, migration testing, and recovery.
Can teams add ClickHouse analytics while keeping Postgres on Neon?
Yes. ClickPipes replicates Neon data into a separately provisioned ClickHouse analytical service while transactional Postgres stays on Neon. Moving Postgres to ClickHouse Managed Postgres brings both services under one ClickHouse Cloud control plane and consolidated bill, with native CDC included at no additional charge on AWS. Both paths use asynchronous replication.
Does Neon include native Databricks analytics?
Neon-hosted projects use Lakeflow Connect to replicate Postgres changes into Delta tables in a separate Databricks analytics environment. The PostgreSQL connector currently runs in public preview. Lakebase within Databricks provides native Unity Catalog and lakehouse integration as a distinct deployment from a Neon-hosted project. Lakebase Search provides vector and keyword retrieval within Neon and differs from the Databricks analytical environment.
Can applications query ClickHouse through a PostgreSQL connection?
Yes. With configured foreign tables, pg_clickhouse lets applications, agent tools, ORMs, and dashboards query ClickHouse through a PostgreSQL connection. It pushes supported filters, aggregations, and joins to a separately provisioned ClickHouse service with its own compute, storage, and metering. Unsupported operations and parts of mixed plans still run in Postgres. The services retain separate transaction boundaries.
Can Neon scale to zero with an active CDC subscriber?
A connected logical-replication subscriber keeps the Neon source compute active and prevents scale-to-zero. Source CU-hour charges continue while the subscriber stays connected.
How do teams migrate from Neon to ClickHouse Managed Postgres?
Managed ClickPipes migration performs an initial load and ongoing CDC. Before cutover, check migration compatibility, including PostgreSQL versions, extensions, drivers, pooling, and branch automation. After the initial load, teams stop writes, let CDC catch up, validate the replicated data, and switch application connections. Transfers back to Neon use standard PostgreSQL dump and restore tools and updated connection settings, following the Neon migration guide.
Top comments (0)