# Xata is joining ClickHouse: what Xata users should do now

> Xata is not shutting down, and there is no announced migration deadline. What the ClickHouse acquisition means for your Postgres branches, pricing, and options.

Published: 2026-11-12
Canonical: https://layerbase.com/blog/xata-joining-clickhouse-what-to-do

[Xata announced on November 9 that it is joining ClickHouse](https://xata.io/blog/xata-is-joining-clickhouse). Its message to customers is straightforward: keep using Xata normally. New sign-ups remain open, and customers will move to ClickHouse Managed Postgres after the services reach feature parity. The announcement gives no migration deadline.

This is different from [Gadget's shutdown](/blog/gadget-shutting-down-shopify-migration). There is no reason to schedule an emergency database move just because the ownership changed. If Xata fits your workload today, staying while you evaluate the transition is reasonable.

I run Layerbase, so I have an alternative to offer. But moving a working production database has a cost, and an acquisition by itself is not evidence that paying that cost will improve your system.

## What changes, and what is still a plan

ClickHouse Managed Postgres became generally available on November 9. Xata's announcement describes instant branching, scale-to-zero, and an agentic tier as work being brought into that service. Do not treat the acquisition announcement as proof that your existing Xata workflow already works unchanged in ClickHouse.

Make a list of what your team actually uses. A single production Postgres with a few development branches has a different migration surface from a system creating isolated branches on every pull request. Anonymization rules, branch automation, pgroll workflows, and wake behavior matter even when the application itself only speaks ordinary SQL.

Ask for a transition plan covering those dependencies when it becomes available. Keep the answers with your infrastructure notes so the decision is based on your workload, not the word "acquisition."

## Current pricing is not a future migration quote

As of November 12, [Xata's pricing page](https://xata.io/pricing) lists Cloud starting at **$0.012/hour plus $0.28/GB-month for storage**. At 730 active hours, that starting compute rate works out to $8.76 before storage. That is an illustration of the hourly rate, not a flat subscription or a quote for every region and instance. Scale-to-zero changes active compute usage.

ClickHouse now publishes GA pricing terms for Managed Postgres. Do not budget a future Xata migration from an old beta screenshot, and do not assume your Xata bill will automatically become a particular ClickHouse configuration's bill. Ask about the destination configuration and commercial terms when your migration is proposed.

The [updated ClickHouse Managed Postgres comparison](/blog/clickhouse-managed-postgres-alternative) explains its current VM-based pricing, backup allowance, and data-transfer charges, alongside the differences from Layerbase.

## If you stay, prepare an exit without using it yet

Confirm that you have a tested export and restore procedure. Record extensions, database size, roles, and the connection settings your application uses. Inventory branches and decide which contain work worth retaining.

Rehearse application migrations and representative queries against a disposable restored copy. Include CI and preview environments in that exercise. A production connection string can be easy to change while a dozen build jobs still assume a particular branch API.

These are useful checks whether you remain with Xata, accept its eventual managed transition, or move elsewhere. They give you a way to estimate the work before committing to it.

## When Layerbase is a reasonable alternative

Layerbase makes sense to evaluate if you want a small managed Postgres with a fixed monthly plan, or several database engines on the same account. [Our plans](/pricing) are Free at $0, Solo at $5/mo, and Pro at $15/mo, checked November 12. Free databases sleep when idle; paid plans add always-on capacity. Shared resource and bandwidth allowances still apply.

That is a different packaging model, not a claim that a shared plan has the same resources as a Xata instance. Compare your working set, concurrency, backups, and uptime requirements before comparing the invoice totals.

Layerbase has database branching, but that does not make Xata's branch lifecycle, anonymization, or automation portable. If those are the reason you chose Xata, verify the replacement workflow before moving the production branch. If your main goal is integrated Postgres-to-ClickHouse analytics, also evaluate the managed transition: Layerbase does not supply a managed CDC pipeline between those engines.

## What the Xata migration actually carries

The [Xata migration page](/migrate/xata) is the starting point for moving a current Xata Postgres branch into Layerbase. Supply the branch's direct connection string and rehearse the copy into a new target. Treat old Xata Lite applications separately; this is not a promise that proprietary SDK behavior becomes a normal Postgres application automatically.

The database copy does not transfer all branches at once, pgroll migration history, anonymization rules, secrets, or your deployment integration. Inventory and rebuild those separately. Check required extensions before the import, and validate application behavior afterward.

A read-once copy also needs a cutover plan. Changes made at the source after the copy starts need a final catch-up or a controlled write pause. Keep the source until you have validated the destination and decided how to handle any writes made after switching the app.

If nothing is broken today, start with the dependency inventory and a restore rehearsal. If your costs or requirements already justify a move, [test a Xata migration](/migrate/xata) before committing production. You have time to make this a measured decision.