ClickHouse Is Acquiring Xata and Made Managed Postgres Generally Available on AWS. Branching and Scale to Zero Are Not in It Yet. Here Is What I'd Do as a Xata Customer.
On November 9, ClickHouse said it is acquiring Xata, and Xata said it is joining ClickHouse. On the same day ClickHouse declared its Managed Postgres service generally available on AWS. If your side project's database sits on Xata because of instant branches or because it suspends when idle, the two posts tell you your service keeps running and that you will be migrated at some point. They do not tell you when, at what price, or to what plan.
What the two posts say
Xata's post, written by Monica Sarbu, makes two statements that matter to customers. "Nothing changes for Xata customers in the short term and we continue to accept new sign-ups." And: "We will eventually migrate Xata customers to ClickHouse Managed Postgres." The plan is to bring Xata's features into the ClickHouse service and, once there is feature parity, to migrate customers "as smoothly as possible, ideally with no impact on the service."
ClickHouse's post, by Sai Srirampur, confirms the direction and adds that if you need instant branching and cloning today, they are still onboarding customers to Xata.
Neither post states a price for the deal or says whether it has closed. Both use the present tense.
What ClickHouse Managed Postgres is today
The generally available service runs on AWS. Google Cloud is in private preview, and Azure is not mentioned. It is built on local NVMe storage, which ClickHouse says delivers 2 to 10 times the performance on transactional workloads. That is a vendor benchmark and I have not reproduced it. The feature list reads like a production database: up to two standbys across availability zones, automatic failover, backups with point-in-time recovery, built-in PgBouncer, read replicas and private networking. ClickHouse says it has hundreds of production customers, with some migrating from Aurora, RDS and Neon.
Two things in the post affect a small bill. With general availability the beta discount ends, and backup storage and public network egress become billable. ClickHouse says it expects those charges to be modest for most customers. The post has no per-unit prices and points to a pricing calculator instead.
What is not in it yet
Read the "coming next" section before you assume the migration is a straight swap. Branching, cloning, automatic idling and scale to zero are all listed there as planned, along with a dedicated tier for agents. None has a date.
Those are the features a solo builder typically chose Xata for. Xata's post says its scale to zero wakes a suspended database in about one second and that a branch of a multi-terabyte database takes around three seconds to create. Those are Xata's figures for Xata's current platform. Nobody has promised the same numbers on the ClickHouse side.
The posts also say nothing about pricing for Xata customers after migration, the future of the free tier, or a sunset date for Xata's cloud. "Ideally with no impact" is a goal. It is not a commitment I could hold anyone to.
The open source question
Xata's open source page says its core platform is Apache 2.0, and lists pgroll (about 6,600 GitHub stars) and pgstream (about 1,200) under the same license. Neither announcement says what happens to those projects. ClickHouse's own list of open source work in its post does not include them.
An Apache 2.0 license cannot be taken back from code that is already published, so if you depend on pgroll for zero-downtime migrations, the version you run today stays yours. What can change is who maintains it and how fast. I would pin the version and watch the commit activity over the next quarter.
What I'd actually do
If Xata is my database, none of this is an emergency. It is 30 minutes of preparation that I would do this week while it is easy.
- Take a plain
pg_dumpand restore it somewhere else, even a local Postgres in Docker. The point is to prove the restore works, and to learn whether you rely on anything that is not stock Postgres. - Write down what you pay now and which plan you are on, with a screenshot. If pricing changes at migration, you want the before number without digging through old invoices.
- List the Xata features you depend on. For most small projects it is three things: branches for preview deploys, scale to zero, and the price of the lowest tier. Those are the three to check when the migration notice arrives.
- Set your tripwire now. Mine would be this: if the migration email arrives before branching and scale to zero exist on the other side, or if the post-migration price for my usage is more than double, I move. Deciding the rule in advance means I will not rationalize it later.
- Do nothing else. Do not migrate preemptively to ClickHouse Managed Postgres. It is a production service priced for production workloads, and its hobby-scale story is still on the roadmap.
If you are choosing a database for a new project today, I would not start on Xata unless branching is the reason you are there. You would be signing up for a migration with no date. Plain Postgres on any provider with a standard connection string keeps your options open.
Where this could be wrong
This could turn out well. ClickHouse has money and a managed service with real customers, and Xata's team has built the branching technology ClickHouse wants. A small database company being bought by a larger one that needs its product is a better outcome than the shutdown Val Town announced this week. If the agent tier arrives with scale to zero and a low entry price, Xata customers may end up on faster storage for about the same bill.
I am also assuming that a migration means disruption. Both companies say they aim for no impact, and since Xata is Postgres underneath, a careful migration could be a changed hostname and nothing more.
My caution comes from the wording. "Short term" and "eventually" are the two time words in the customer section, and neither is a date. I would rather have a tested dump and a rule written down than find out what "eventually" meant from an email.
Author
Lukas
@lukcombinator