Xata alternatives: the free tier is gone, and the new product is a branching competitor
Short version: Xata is not the product you signed up for in 2023. The serverless data platform with the 15 GB free tier is gone, and in its place is a rebuilt, quite good, copy-on-write Postgres branching service that bills by the hour with no free plan. If you came for the free tier, the closest replacement is a free tier that sleeps rather than one that expires: ours is 2 databases, 5 GB, and 8 engines with no card. If you came for branching, Xata now competes directly with Neon and with us, and the honest comparison is below.
What Xata was, and what it is now
Xata launched in 2022 as something between Airtable and a database: a hosted data platform with records, search, file attachments, and a TypeScript SDK, with Postgres underneath. The free tier was the pitch. In their own words it gave you "15 GB of storage space, no cold starts, and no pausing in case of inactivity," which is a remarkable thing to give away and is exactly why so many side projects ended up there.
That tier started shrinking on January 10, 2025, when Xata pulled the search and files APIs out of the free plan. Then in May 2025 the company announced a rebuilt product: vanilla, unmodified Postgres with instant copy-on-write branches, data anonymization powered by pgstream, and storage separated from compute over NVMe/TCP. The old platform was renamed Xata Lite for a while. As of the date on this post, lite.xata.io returns HTTP 410 Gone. Later in 2025 they open-sourced the core under Apache-2.0.
I want to be clear that the new product is a serious piece of engineering. Branching at the storage layer, chunks tracked by a metadata index, a write copies only the chunk it touches. That is the right way to build it. This post is not "Xata got worse." It is "Xata became something else, and the something else has a different price."
The price ladder
Verified 2026-09-06 from xata.io/pricing:
| Plan | Price | Notes |
|---|---|---|
| Open Source | Free | Self-host the Apache-2.0 core on your own infrastructure |
| Xata Cloud | $0.012/hr + $0.28/GB/mo storage | Fully managed, pay as you go, 14-day trial, no card for the trial |
| BYOC | Quote | Their platform in your AWS, GCP, or Azure account |
There is no free plan. The trial is 14 days.
Do the arithmetic on the hourly number. $0.012 an hour is $8.76 per 30-day month for one branch that stays up, before storage. Scale-to-zero is what keeps that from being the bill: a branch nobody is connected to costs nothing for compute, and only the $0.28 per GB per month for its storage. That is a fair model for what Xata is now, which is a platform for spinning up many short-lived branches. It is not a model for "one database for my side project that gets a visit every few hours," because a database that keeps waking up is a database that keeps billing.
Storage is where the branching story gets interesting. Copy-on-write means a branch shares chunks with its parent and you pay only for the deltas, so ten branches of a 5 GB database do not cost 50 GB. That is the same property our branching has, and it is the reason both of us can make a branch in seconds regardless of size.
Where the two angles split
There are two kinds of people searching for a Xata alternative right now, and they want different things.
You were on the free tier and it stopped being free. You had a small Postgres, maybe a few hundred megabytes, maybe a few gigabytes, with an app in front of it that gets real but modest traffic. The old Xata cost you nothing and never paused. The new Xata costs a few dollars a month once it is awake often enough, and the trial clock is running.
You want copy-on-write branching for previews and CI. You read the rebuild announcement, you liked it, and you are comparing Xata against Neon and against whoever else does branching properly. Price matters less than whether the branch comes up with real data in it.
The rest of this post handles them separately.
If the free tier was the point
What the old free rung was actually holding up was a database that cost nothing while it sat idle. That is the thing to replace, and the replacements for it are free tiers that hibernate rather than expire.
Ours: Free is $0 with no card, 2 databases, 5 GB, and 8 engines (Postgres, MariaDB, SQLite, libSQL, DuckDB, Redis, Valkey, and TypeDB). A free database sleeps after 15 idle minutes and wakes on connect, so the first query after a quiet spell takes a moment and the rest are normal. You get 1 branch per database and 1 manual backup slot. Nothing about it expires, and the address does not go away unless the database sits untouched for a long time, in which case it is archived with its data intact rather than deleted.
The honest difference from what Xata used to give you is the sleeping. Old Xata was always on. Ours is not, at $0. If you need always-on, Solo is $5/month for 2 databases with one of them pinned always-on, 10 GB, MySQL and FerretDB added to the engine list, 3 branches per database, and 7-day rolling daily backups. Pro is $15/month for up to 10 databases, 25 GB, all 18 engines on Layerbase Cloud, 10 branches per database, 30-day backups, and point-in-time restore on always-on Postgres.
Compare that against Xata Cloud for one small always-on database: $8.76 a month plus storage, versus $5 flat. For one database that mostly sleeps: a few dollars a month that depends on how often it wakes, versus $0.
Turso is the other free tier worth a look if your data fits in SQLite. Neon's free tier is 0.5 GB per project with compute that suspends after five minutes and cannot be told not to. Both are real options. Neither gives you 5 GB of Postgres for free.
If branching was the point
Now the more interesting comparison, because the new Xata is genuinely good at this.
| Xata Cloud | Layerbase Cloud | |
|---|---|---|
| Engines that branch | Postgres | Postgres plus 15 more (MySQL, MariaDB, Redis, Valkey, FerretDB, DuckDB, and the rest) |
| Branch mechanism | Copy-on-write at the storage layer | Copy-on-write at the storage layer |
| Data in a new branch | Parent's data as of now, optionally anonymized | Parent's data as of now |
| PII anonymization | Yes, pgstream-based, first class | No |
| Schema migrations | pgroll, zero-downtime, reversible | Your ORM's migrations, as usual |
| Idle branch cost | $0 compute, storage billed per GB | Inside the flat plan, sleeps when unused |
| Free plan | No | Yes |
| Self-host | Yes, Apache-2.0 core | No |
| Reachability | Public TLS, -rw and -pooler endpoints | Public TLS, direct and pooled endpoints |
The row that should decide it for a Postgres-only team is anonymization. Xata's branches can be created with production data scrubbed of PII according to rules you define, which solves a real problem: a copy-on-write branch contains exactly what its parent contains, including the columns your compliance team does not want on a developer's laptop. We do not do that. If your production data has PHI in it and you want engineers branching from production, Xata built the feature you need and I would rather you use it than pretend we have it.
The row that should decide it for a team running more than one engine is the first one. A preview environment for a real app usually needs the Postgres and the Redis next to it, and sometimes the search index too. Xata branches the Postgres. We branch all of them, from the same dashboard, wired to the same pull request. The preview environment comparison goes through where every platform lands on the "what is in the database when the preview comes up" question if you want the wider field.
Connecting to either is plain Postgres. A Xata branch string looks like this, with -rw for the direct endpoint and -pooler for the PgBouncer one:
postgresql://user:pass@<branch-id>-rw.us-east-1.xata.sh:5432/postgresXata's own pooler post is explicit that pg_dump and schema migrations need the -rw host, because the pooler runs in transaction mode. Keep that in mind when you copy data out, whichever direction you are copying it.
The move, if that is where you landed
Xata is unmodified Postgres now, which makes leaving it a dump and a restore. The Xata migration page walks the wizard path: create a Postgres on Layerbase, choose Migrating from another platform, pick Xata, paste the -rw connection string for the branch you want, and it reads the branch once and copies schema and data. Nothing is written back to Xata.
By hand it is one pipe:
pg_dump "postgresql://user:pass@<branch-id>-rw.us-east-1.xata.sh:5432/postgres" \
--no-owner --no-acl \
| psql "postgresql://layerbase:<password>@<host>.cloud.layerbase.dev:5432/appdb?sslmode=require"Then swap DATABASE_URL, redeploy, and compare row counts before you delete anything. The step-by-step version, including what does and does not travel (branches, pgroll history, and anonymization rules do not), is in Migrating from Xata to Layerbase.
Stay on Xata if
I would not move a database off Xata reflexively. Four cases where staying is clearly the right call:
You need anonymized branches. If developers must never see real PII and you still want production-shaped data in every branch, Xata's pgstream-powered anonymization is the feature, and nobody else on this page has it.
You use pgroll. Zero-downtime, reversible schema changes with the old and new schema served simultaneously during a migration is a genuinely hard thing that Xata made routine. If your deploy process depends on it, that is worth more than a price difference.
You want BYOC. Xata will run the whole platform inside your own AWS, GCP, or Azure account. If your security posture says the data does not leave your VPC, that is a category we do not compete in.
You are the agent-scale story. Xata's pitch for the rebuild is millions of ephemeral databases for AI agents that run in parallel, retry, and explore. If you are provisioning branches by the thousand from an orchestrator, a platform designed around that from the storage layer up is the right tool, and a flat plan with a branch cap per database is not.
The case for moving is narrower and specific: the free tier was the reason you were there, or you need branching on more engines than Postgres, or you want a bill that is a number rather than a rate.
FAQ
Does Xata have a free tier in 2026?
No. As of 2026-09-06 the pricing page lists Open Source (self-host, free), Xata Cloud at $0.012 per hour plus $0.28 per GB per month with a 14-day trial, and BYOC on quote. The old 15 GB free tier belonged to the original platform, which was renamed Xata Lite and whose site now returns HTTP 410.
What happened to the old Xata product?
Xata rebuilt itself in 2025 as a copy-on-write Postgres branching platform and open-sourced the core under Apache-2.0. The search and files APIs left the free tier on January 10, 2025, and the original platform was retired as Xata Lite after that. The new product is unmodified Postgres you connect to with any Postgres client.
How much does Xata Cloud cost for one small always-on database?
$0.012 per hour is about $8.76 for a 30-day month before storage, and storage is $0.28 per GB per month. Scale-to-zero stops the compute charge while nobody is connected, so a database that is mostly idle costs less, and one that keeps waking up costs close to the full number.
Is Xata's branching the same as Layerbase branching?
Mechanically similar: both are copy-on-write at the storage layer, both make a branch in seconds regardless of size, and both charge for deltas rather than full copies. Xata adds PII anonymization and pgroll schema migrations and only branches Postgres. We branch 16 engines and put the branches inside a flat plan.
Can I pg_dump a Xata database?
Yes, against the -rw endpoint. The -pooler endpoint runs PgBouncer in transaction mode, which breaks pg_dump, pg_restore, LISTEN/NOTIFY, and session-level SET. Use the direct host for the copy and the pooler for application traffic.
What is the best Xata alternative for a side project?
A free tier that hibernates instead of expiring. Ours is 2 databases, 5 GB, and 8 engines with no card, sleeping after 15 idle minutes and waking on connect. Turso is the other one worth a look if SQLite fits. Neon's free tier is 0.5 GB per project.
The wrap-up
Xata made a hard, correct decision: stop subsidizing a free serverless data platform and build the best Postgres branching service they could. The result is worth paying for if branching with anonymized data is your problem. It is not a free database anymore, and it does not pretend to be.
If you need the free database back, create an empty Postgres and see whether a database that sleeps bothers you as much as a bill that runs. If you have data to bring, start at the Xata migration page.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Layerbase vs Crunchy Bridge: two ways to buy managed PostgresCrunchy Bridge is Postgres specialists selling instance-hours across AWS, Azure and GCP. Layerbase is a flat monthly price, 18 engines and branching. A head-to-head on pricing, versions, extensions, HA, backups and placement, with worked examples.
- Prisma Postgres alternatives: the plan with neither meterPrisma Postgres bills per operation, Neon bills per CU-hour, and Prisma frames the whole decision as a choice between those two meters. There is a third option: a flat plan with no meter at all. Here are the current Prisma numbers, the arithmetic for a chatty app, where operations pricing genuinely wins, and how to move with the direct TCP string.