Forem: AlexF

PostgreSQL Branching: Xata vs. Neon vs. Supabase - Part 2

AlexF — Mon, 30 Jun 2025 18:58:59 +0000

Introduction

In Part 1 we dissected how each platform branches a Postgres database under the hood. This post zooms in on pricing. We’ll explore how Xata, Neon, and Supabase pricing strategies stack up when you require:

CI preview databases for a five engineer team
HA deployment with two read replicas + always-on staging
Per-tenant isolation for SaaS offerings
Data-science sandboxes for model training
Autonomous agents with high branch churn

Pricing

One of the first questions any team asks when evaluating platforms that are critical to their infrastructure is “how much is this actually going to cost us?” Since each service has a different pricing model, this won't be an exact apples-to-apples comparison. I’ll break down the pricing for Xata, Neon, and Supabase, then provide some scenario-based comparisons to illustrate the differences. Please note that the pricing and packaging of each solution were collected on June 25, 2025.

Neon vs. Supabase vs. Xata

Focusing on branching, here’s a quick breakdown of the pricing plans.

Provider	Plans	What’s Included	Typical Instance Rates	Overage / Extras
Xata	Pay-as-you-go	Unlimited branches, pay for vCPU-hrs & GB-months only	Example: xata.small (2 vCPU / 2 GB) → $0.024 hr xata.xlarge (4 vCPU / 16 GB) → $0.192 hr	Storage $0.30 GB / mo
Neon	Launch $19 / mo Scale $69 / mo Business $700 / mo	Launch: 300 CPU-hrs & 10 GB Scale: 750 CPU-hrs & 50 GB Business: 1k CPU-hrs & 500GB storage	Compute charged in CPU-hrs Example: 2 vCPU for 1 hr = 2 CPU-hrs	CPU overage $0.16 per CPU-hr Storage overage $0.50–1.75 GB / mo
Supabase	Pro $25 / mo Team $599 / mo	$10 compute credit Pro: 1 Micro instance (2 CPU / 1 GB) & 8 GB storage Team: higher limits + support	Add-on instances: Micro $10 / mo Small $15 / mo Medium $60 / mo Large $110 mo XL $210 / mo	Instance add-ons charged by the month Defaults to Micro rate of $0.01344 / h Storage overage $0.125 GB /mo

Xata

We aimed for simple, transparent pricing. Xata’s pay-as-you-go model charges for compute instance hours and storage GB months, period. There are predefined instance sizes with a certain vCPU and RAM combination and an hourly rate for each. For example, a small dev instance (2 vCPUs, 2 GB RAM) is $0.024 per hour (~$18/month if running 24/7). Storage is $0.30 per GB per month, charged only on actual data usage since we don’t pre-allocate disk. All the additional features are included at no extra cost. We don’t charge separately for number of branches or anything like that. You can create unlimited branches and you’ll just pay for the storage difference they incur and any compute hours if those branches are spun up and running.

Neon

Neon uses a tiered plan model with a mix of free quotas and pay-as-you-go for overages. For instance, Neon’s Launch plan is $19/month which includes 300 hours of compute and 10 GB of storage. The Scale plan is $69/month and includes 750 compute hours and 50 GB storage. If you exceed the included hours or storage, you pay overage fees. Neon measures compute in “compute hours” which are basically CPU-hours; e.g., running a 2 CPU instance for 1 hour consumes 2 compute hours. Overage compute hours are billed at $0.16 per CPU-hour beyond the included amount. Storage overages are around $1.50–$1.75 per GB-month depending on tier.

Supabase

Supabase’s pricing has two components: the base plan fee and usage add-ons. Their Pro plan is $25/month base, which includes certain limits (like 8 GB database space, 100GB file storage, etc.) and importantly includes $10 of compute credits. Those credits cover a certain amount of database instance time. Supabase essentially offers fixed-size instance add-ons: a micro instance (roughly 2 CPU, 1GB RAM on ARM) costs $10/month, Small is $15, Medium $60, Large $110, etc. The $10 credit in the base plan means you can run one micro instance included. If you upgrade your database to a larger size or add more branches, you incur additional instance charges. Each branch environment is treated like an additional instance in terms of billing, and you’re only charged for the hours it’s actually running. The base $25 plan’s $10 credit does not apply to branch instances, it only covers the main project instance. So if you spin up branches, those consume compute credits separately (about $0.32 per day on a micro instance).

Cost scenarios

To make the analysis concrete, let’s compare costs in a few different theoretical scenarios. Please note that all scenarios are estimates, actual bills will vary. These scenarios assume certain architectural decisions and also do not take into account enterprise level discounts provided at certain scales for each offering.

Scenario 1: CI preview databases for a five engineer team

In this scenario, you have a production Postgres (~10 GB data) and a dev workflow where 5 developers frequently create isolated databases for feature work. Each dev branch is used ~3 hours per weekday for active development or running CI tests, then torn down. Additionally, you maintain a long-lived staging environment that is refreshed with production data nightly for final QA. Let’s compare monthly costs for enabling this on each platform.

TL;DR

Cost Breakdown	Xata (Pay-as-you-go)	Neon (Scale plan)	Supabase (Pro plan)
Baseline env (staging only*)	~$21. `xata.small` (2 vCPU / 2 GB) 24×7 ($18) + 10 GB storage ($3).	~$180. Persistent 2 vCPU staging instance; exceeds 750 CPU-hr quota, so ~$113 overage on top of the $69 base.	~$25 - 30. $25 Pro plan covers one always-on Micro instance for staging; add +$5 if you upsize staging to a Small ($15/mo, first $10 covered by plan credits).
Dev-branch usage (5 devs × 3 h/day)	~$4. 330h on micro instances ($0.012 / h).	~$5. 330 CPU-h of overage at ~$0.016 / CPU-h.	~$4.44. 330 branch hours ($0.01344 / h).
Estimated monthly cost	$25 - 30	$180 - 185	$29 - 34

Xata

Staging on xata.small runs $18 in compute plus $3 storage. Ephemeral dev branches add about $4 (minute-billed at $0.012 / h) and negligible storage, keeping the bill around $25 – 30/mo. Copy-on-write means you never pay to duplicate the 10 GB dataset. Granular billing also lets you leave a branch up for an unusually long CI run without being penalized by hourly rounding.

Neon

The Scale plan’s 750 compute-hour quota is mostly eaten by the always-on staging node (1,460 CPU-h), so 710h spill into overage at $0.16 / h. Add the $69 subscription and you arrive at about $183/mo. The short-lived dev branches fit inside what’s left of the allowance. Any spike in staging load or an extra CPU added for performance pushes more hours into overage, so monthly spend can fluctuate noticeably.

Supabase

The Pro plan’s $25 base buys you one always-on Micro instance, which is perfect for staging. Dev branch compute is only about $4.44 (330h × $0.01344/h). With that surcharge, monthly spend climbs to about $29–34. Keeping branch counts low or recycling a single shared preview databases are some ways to avoid this steady drip.

Scenario 2: HA deployment with two read replicas + always-on staging

To meet strict uptime and guarantee zero-downtime fail-over with realistic testing environments you’ll want to run one primary writer and two read replicas (three AZs total) with an always-on staging branch. This is a pretty common production setup. In our scenario, every node is an 8 vCPU / 32 GB instance holding the same 100 GB dataset. All four nodes will stay online 24 × 7.

Cost Breakdown	Xata (Pay-as-you-go)	Neon (Business plan)	Supabase (Team plan)
Primary + 2 replicas + staging (4 × 8 vCPU)	~$1,121. `xata.2xlarge` $0.384/h × 4 × 730h	~$4,278. $700 plan + (23,360 CPU-h − 1,000 incl.) × $0.16	~$2,240. $599 plan + 4 × 2XL compute ($0.562/h)
Storage	~$30. 100 GB × $0.30 / GB-mo	In-plan (≤500 GB included)	~$49. 400 GB total - 8 GB quota × $0.125/GB-mo
Estimated monthly cost	$1,151	$4,278	$2,289

Xata

Four always-on xata.2xlarge nodes run about $1,121/mo in compute. With copy-on-write, the primary, two replicas, and staging branch all reference the same 100 GB dataset. Adding only $30 for storage costs. The total cost ends up being $1,151/mo. Fail-over or promotion is simply a metadata flip and recovery time is nearly instant.

Neon

Each 8-vCPU endpoint burns 5,840 CPU-h per month. With four nodes that is 23,360 CPU-h. After the Business plan’s 1,000 CPU-h allowance, 22,360 CPU-h are billed at $0.16 ($3,578), plus the $700 subscription. Storage is CoW-backed, so the single 100 GB copy stays inside the 500 GB quota of the Business plan, keeping the bill at around $4.3k/mo.

Supabase

The primary, two read replicas and the staging branch all run on 2 XL compute add-ons (8 vCPU / 32 GB, $0.562 / h). Four nodes for a full month total about $1,641 in compute. Adding the $599 Team-plan base fee and storage for four physical copies (400 GB billed at $49) brings the cluster to about $2.3k per month. Because Supabase stores full files per database, storage grows linearly with every replica and the staging branch.

Scenario 3: Per-tenant isolation for SaaS offerings

A common SaaS enterprise pattern is tenant isolation, also described as having a database-per-customer. In this scenario, we assume 200 isolated customer branches, each holding about 10 GB of data and running on smaller instances (2 vCPU / 1 GB).

In this scenario, branches are live 9 AM – 5 PM on work days (~ 176h/month), then hibernate outside of those hours. Storage is always allocated, so the fleet’s overall footprint is about 2 TB.

TL;DR

Cost Breakdown	Xata (Pay-as-you-go)	Neon (Business plan)	Supabase (Team plan)
Tenant compute (200 × 176h)	~$422. 35,200h × $0.012 / h (`xata.micro`)	~$6,172. 35,200 CPU-h: 1,000 incl. = 34,200h × $0.16 + $700 base	~$1,072. 35,200h × $0.01344 / h + $599 base
Storage (~2 TB total)	$600. 2,000 GB × $0.30 / GB-mo	~$750. 1.5 TB over 500 GB allowance × $0.50 / GB-mo	~$249. 1,992 GB over 8 GB × $0.125 / GB-mo
Estimated monthly cost	$1,022	$6,922	$1,322

Xata

We bill strictly for what’s used. When a tenant branch sleeps, its compute cost drops to zero. Only storage continues at $0.30 / GB-mo. With all 200 customer databases active during the day, the PostgreSQL fleet’s compute adds up to about $422. Copy-on-write means each branch stores just the pages it changes, keeping the 2 TB footprint flat. As a result, for roughly $1k/month you can have 200 isolated tenants.

Neon

Every active vCPU is metered. Running even a single-CU compute for 176 hours racks up 176 CPU-h. Multiply that by 200 branches and it quickly adds up to 35,200 CPU-h. After the 1,000h allowance the overage alone is $5.5k, plus the $700 plan fee. Storage beyond 500 GB is another $750. Scale-to-zero helps overnight, but eight hours a day across 200 databases still adds up, landing the total near $7k/month.

Supabase

Branches are billed exactly like any other database, defaulting to $0.01344/h on the Micro instance. The fleet’s 35,200h therefore costs about $474 per month. Assuming certain features and support are required for this use case, add the $599 Team plan and about $249 for disk. The monthly total is roughly $1.3k.

Scenario 4: Data-science sandboxes for model training

In this scenario, five analysts spin up 2 TB clones on 32 vCPU / 128 GB nodes for supervised fine-tuning runs against their models one day each week. Each clone runs about 8 hours every Monday (~32 h/mo), so the platform logs 160 instance-hours a month. We estimate the storage growth by assuming the training job rewrites about 10% of the source pages (roughly 200 GB per branch). Multiplied by five analysts that yields to about 1 TB of new data for training.

TL;DR

Cost Breakdown	Xata (Pay-as-you-go)	Neon (Business plan)	Supabase (Team plan)
Model-training (32 vCPU × 160h)	~$246. `xata.8xlarge` at $1.536 / h × 160h	~$1,359. $700 plan + 5,120 CPU-h – 1,000 incl. = 4,120 × $0.16	~$410. 8 XL compute at $2.562 / h × 160h
Storage overhead (2 TB base + 1 TB deltas)	~$900. 3 TB total × $0.30/GB-mo	~$1,250. 2.5 TB over 500 GB allowance × $0.50/GB-mo	~$1,535. 12 TB total × $0.125 / GB-mo
Estimated monthly cost	$1,146	$2,609	$2,544

Xata

You pay strictly for the 160 hours on xata.8xlarge, about $246. Because the primary 2 TB production database also lives inside Xata, storage now totals 3 TB (2 TB base + 1 TB dirty pages) at $0.30/GB-mo, or roughly $900. Branches hibernate the remaining 672h each month, so there’s no idle-time compute charge. The total cost is about $1,146/mo, still linear to the minutes the big node is powered on and the pages that are actually modified.

Neon

The Business tier includes 1,000 CPU-hours and 500 GB storage for $700/mo. One 32-vCPU node burns 32 CPU per hour. Across 160h, that’s 5,120 CPU-h and 4,120h over that will be charged an overage cost $0.16 ($659). On top of this, you can add 2.5 TB of extra storage at $0.50/GB ($1,250), resulting at roughly $2.6k/mo for this use case.

Supabase

Each sandbox uses the 8 XL compute add-on ($2.562/h), so 160h costs $410. Supabase lacks copy-on-write for data pages, so each sandbox must hold a full 2 TB copy, bringing total stored data to 12 TB vs 3 TB like Xata and Neon. Add the $599 Team plan and $1.535k for 12 TB of storage, the total comes to $2.54 k/mo. Note that 12 TB exceeds the Team cap and an enterprise tier may be required, and multi-terabyte disk resizes add lead time before each training run.

Scenario 5: Autonomous agents with high branch churn

In the last few weeks, we’ve seen the importance of databases in the AI agent race explode. With Databricks recent acquisition of Neon and Snowflakes recent acquisition of CrunchyData, it’s fair to say PostgreSQL is a well positioned database for the use case. In this scenario, an AI platform creates 1,000 ephemeral branches every day, each on a small instance (2 vCPU/1 GB).

Because of the task oriented nature of the agents and speed of iteration, every branch lives only for about 30 min. In total, the PostgreSQL fleet logs 15,000 instance hours per month. In this hypothetical, the working set is tiny (20 GB total), and branches are dropped as soon as the agent finishes.

TL;DR

Cost Breakdown	Xata (Pay-as-you-go)	Neon (Scale plan)	Supabase (Pro plan)
Agent compute (15,000h)	~$180. 15,000h × $0.012 / h (`xata.micro`)	~$2,349. $69 plan + (15,000 CPU-h - 750 incl.) × $0.16	~$418. $25 plan - $10 credit + 30,000 billable h × $0.01344
Storage (20 GB)	~$6. 20 GB × $0.30 / GB-mo	Covered by the plan	$1.5. (20 GB – 8 GB) × $0.125
Estimated monthly cost	$186	$2,355	$420

Xata

Billing is minute-level at Xata. Each 30-minute micro branch costs $0.006. Aggregate that over the month and it’s about $180 in compute. Because branches are copy-on-write, the 20 GB hot set is only stored once, adding only $6. There are no control-plane limits throttle the 1,000-per-day create / delete cycle. In total, it’s about $186/mo for effectively unlimited amounts of ephemeral databases for your agents.

Neon

The Scale plan includes 750 CPU-h and 50 GB storage for $69. The workload uses 15,000 CPU-h, which after the 750h included, 14,250h overage at $0.16 adds $2 280. Bringing the bill to $2.35k. Storage fits inside the quota, and scale-to-zero doesn’t help because branches expire after 30 min.

Supabase

Branches are metered by the hour and rounded up. 30,000 billable hours × $0.01344 brings us to $403 for compute. Subtract the Pro plan’s $10 compute credit, add the $25 subscription fee and $1.5 for 12 GB extra storage the monthly total comes to just under $420.

Pricing analysis conclusion

Across all five scenarios the headline prices turn out to be only part of the story. And realistically, at certain scales discounts would come into play or different architectural decisions would be made. At the end of the day, Xata’s pay-as-you-go model remains linear. You add up vCPU-minutes and the copy-on-write storage actually in use. A 2 vCPU dev instance always costs $0.024h and an 8 vCPU production instance always costs $0.384h, no matter how many branches you keep around. Neon, by contrast, bundles a fixed pool of compute hours with each plan. Once a project’s vCPU-hours cross that quota, every extra hour is billed at $0.16 per CPU-hour. Supabase sets a low entry price for compute, but every branch is rounded up to the next full hour and large fleets for production-like data sets require full physical storage.

Those hidden costs quickly become the surprise line-items in your monthly invoice. In Neon, keeping a single 8-vCPU database online 24×7 burns 5,840 CPU-hours a month, over five times the Scale plans allowance. Overage quickly eclipses the base fee in long-running, high-CPU workloads. With Supabase, ephemeral use cases are rounded up to the hour and if there are a lot of them, can double your cost. Because Xata has neither quota overages nor per-branch levies, its costs stay proportional to the resources you use, making final invoices more predictable when workloads scale up or branch counts explode.

Wrapping it up

Branching a PostgreSQL database has officially moved from an interesting idea to being common in daily developer workflows. Xata, Neon, and Supabase each prove the pattern works and is reshaping the way developers and agents build, test, and ship software. With branching, the old bottlenecks of one shared developer database or the risk of production data leaking into your staging environment can disappear. Teams get parallel feature work, reproducible CI pipelines, and more efficient release practices.

Where the platforms diverge is in how their architectures convert that experience into dollars and developer experience. Xata keeps costs linear to the resources you actually hold open, Neon prioritizes burstable, serverless efficiency for short-lived workloads, and Supabase offers an all-in-one stack at a predictable entry price. Each model suits a different style of workflow. When considering adopting branching, make sure your choice matches your reality and expectations.

At Xata we spent a lot of time weighing those trade-offs and identifying who we’re building this platform for. Ultimately we landed on a vanilla-Postgres, copy-on-write storage layer that scales and improves performance, with an invoice that’s easily predictable. If that sounds interesting to you, we’re currently in private beta onboarding new teams every day. You can request access here or drop by our Discord to chat.

PostgreSQL Branching: Xata vs. Neon vs. Supabase - Part 1

AlexF — Wed, 25 Jun 2025 16:24:42 +0000

Introduction

As head of product at Xata, I’ve had a front-row seat into the recent (r)evolution of Postgres and the rise of database branching these last few years. Functionally, this capability mirrors the branching behavior in git allowing you to quickly clone or fork your data and schema alongside your application feature branch. With modern development practices and the speed at which agents are being adopted to build applications, the ability to branch a database has moved from a nice-to-have to a must-have.

Multiple platforms have emerged to tackle this, each with a unique approach. Neon popularized the idea of copy-on-write branches in Postgres, letting teams spin up full data copies in seconds. Supabase integrated database branching with git workflows, providing full-stack preview environments for every feature branch. With our new PostgreSQL platform at Xata, we’ve reimagined branching from the ground up to address the limitations we saw in existing solutions.

In this blog series I’ll compare the features, architecture and cost for Xata, Neon, and Supabase implementations. Because I go into a bit of detail, I’ll start each section with a comparison table and TL;DR for those of you that want the cliff notes.

Features

In this section, we’ll compare the different database branching and related features that each platforms supports.

TL;DR

All three platforms recognize the value of database branching, but they differ in both features and philosophy.

Feature	Xata	Neon	Supabase
Branching types	Full schema + data (copy-on-write) branches	Full schema + data (copy-on-write) branches	Schema only branches
PII and sensitive data	Built-in anonymization masking of PII and sensitive data	Masking possible through extensions or scripts	Masking is possible through seed scripts
Isolation and creation time	Fully isolated and instant branches regardless of data size	Fully isolated and instant branches regardless of data size	Fully isolated and branch creation time dependent on seed scripts
Merging schema changes	Built-in, zero-downtime merge of branch schema back to production	No built-in merge back to production, requires external tooling	No built-in merge back to production, requires external tooling and leans on code-as-truth
Deployment flexibility	Managed cloud offering, BYOC and on-premise supported, built on open-source solutions	Managed cloud service only, core offering open source managed by you	Managed cloud service only, core offering open source managed by you
Redundancy and HA	At both Postgres level and at storage level	At storage level only	At Postgres level only
Compatibility	Unmodified Postgres	Modified Postgres	Unmodified Postgres

Here’s a more in-depth overview of how Xata, Neon, and Supabase compare in these feature categories.

Branching types

Xata and Neon support instant copy-on-write branching that duplicates both schema and data. This means a new branch starts as a complete copy of the parent database’s data without physically copying it. Supabase’s branching, on the other hand, is currently schema-only. New branches include the schema and run migrations, but no data is copied from the parent. Supabase currently requires you to provide a seed script for the data. That could be random sample data or pulled from an existing database.

PII and sensitive data

Xata’s pipeline removes PII before branches exist. We use pgstream to replicate production into an internal staging replica, applying masking / anonymization rules during the initial snapshot and every subsequent WAL change. Because the replica already contains only scrubbed data, any branch you spin off that replica inherits the same protection automatically with no risk of an engineer seeing real emails or SSNs or PII ever leaving your prod environment.

Neon and Supabase have no built-in masking. Neon users typically install the open-source pg_anonymizer extension on a staging database and script a pg_dump → pg_restore workflow. It works whether production is on Neon or elsewhere but still requires exporting sensitive data out of production first. Supabase offers schema-only branches, so teams either rely on synthetic seed data or build a similar dump/anonymize/import process themselves.

Isolation and creation time

On all platforms, branch creation is effectively instant and the child branch is fully isolated from the parent. In Xata and Neon, this is achieved by copy-on-write at the storage layer. The new branch initially references the same data, and only deviates when writes occur. This means branch creation time does not depend on database size at all. A 1 TB database can be branched instantly on both Xata and Neon. A branch in Supabase depends on how fast migrations run and seed data loads. You pay the cost of applying DDL and inserting seed rows, which can take minutes to hours depending on your setup. Once created, changes in a branch don’t affect the parent.

Merging schema changes

Branching is only half the battle, eventually you want to merge changes to your schema back to the parent branch. Xata provides an integrated schema migration workflow that works with branches to facilitate zero-downtime schema changes (leveraging pgroll). Neither Neon nor Supabase offer an out-of-the-box solution for merging branch changes. With Neon, you typically apply schema migrations to the primary database manually (or with your migration tool / ORM) after testing in a branch. Supabase’s model relies heavily on your git workflow. When you merge your code branch to main, any new database migrations in that branch are automatically run on the production database.

Deployment flexibility

Xata can be run as a managed cloud service, in your own cloud (BYOC) or on-premises. Our new platform is cloud-agnostic. This optionality means you can keep data in-house or in-region for compliance purposes. It also allows you to use your existing cloud credits or pre-committed spend. The platform is built entirely from open-source solutions. Neon is a fully managed cloud service with its core technology open-sourced. Supabase is also a managed service with its core service open-sourced. Both solutions can be run in a self-managed fashion if you are willing to run, manage and support the infrastructure yourself.

Redundancy and HA

Xata offers double the protection at both the Postgres and storage layer with a multi-AZ Postgres replica set handled by CloudNativePG and an erasure-coded Simplyblock storage cluster. If either a compute pod or an entire zone fails, a new pod mounts the same copy-on-write volume and traffic resumes in seconds with no data loss. Neon concentrates its HA logic in the storage engine. WAL is synchronously streamed to Safekeepers across zones and rebuilt by the Pageserver, so the data is always durable. If a stateless compute endpoint dies you just spin up another one, but in-flight sessions are dropped. Supabase has simple Postgres semantics with each branch having its own VM/container. You can add a read replica or enable PITR, yet fail-over and cold-start behavior remain per-branch responsibilities, making HA simple but largely self-managed.

Compatibility

Xata’s platform runs vanilla PostgreSQL with no proprietary forking, it supports all Postgres extensions and features out of the box. In contrast, Neon’s approach involves a custom storage engine and components, meaning they maintain a modified Postgres backend to integrate with that system. As a result, extensions that assume low level disk access might require modifications. Similar to Xata, Supabase operates standard Postgres, so most extensions that don’t conflict with their platform can be used. From a developer’s standpoint, all three should feel like Postgres, but when you’re 100% compatible you’ll never hit a weird edge-case of “oh that extension isn’t supported”.

Architecture

Underneath the hood, Xata, Neon, and Supabase employ very different architectures to achieve database branching. The design decisions at this level have big implications for performance, reliability, and cost.

TL;DR

Here’s a quick overview of the different ways each platform approached branching in PostgreSQL.

Platform	Architecture	Branch creation	Pros
Xata	Stateless Postgres pods in Kubernetes via CNPG
NVMe-oF block-storage cluster (Simplyblock)	Controller writes a new block-index, CoW at block level	100 % vanilla PG, BYOC/on-prem, NVMe-class latency, built-in PII masking	Requires dedicated storage cluster; scale-to-zero in active development.
Neon	Stateless compute streams WAL to Safekeepers to Pageserver
Storage in S3	New timeline at an LSN, CoW at page level via WAL	Instant branches/PITR, scale-to-zero, active OSS community	Extra network hop means higher tail latency, overage costs, no managed BYOC
Supabase	One full Postgres + Auth + Edge stack per branch
Local disk per VM/container.	Forks schema, runs migrations, optional manual seed script	Simple “just Postgres”, whole backend cloned (auth, storage, funcs) for branches	Schema-only by default, heavy per-branch resources, cold-start after auto-pause, slow & costly to copy large datasets.

That’s the 10,000 foot view, let’s go a bit deeper.

Xata

Xata’s new platform uses a decoupled storage and compute architecture similar in spirit to Aurora, but with a critical difference. We do it strictly at the storage layer, without modifying Postgres itself. On the compute side, we run unmodified PostgreSQL instances in containers orchestrated by Kubernetes, using the CloudNativePG operator for high availability and failover. On the storage side, we’ve partnered with Simplyblock to provide a distributed block storage cluster accessible over NVMe-oF (NVMe over Fabrics).

In practical terms, when a Xata Postgres instance writes to disk, it’s writing to a virtual NVMe volume backed by our storage cluster. That storage cluster handles replication, durability, and importantly copy-on-write branching at the block level. We mount and unmount these virtual volumes dynamically for each branch and database.

The copy-on-write mechanism works roughly like this. Our storage cluster breaks the database into chunks (data blocks). When you create a new branch, it creates a new metadata index that initially points to all the same data blocks as the parent. No actual data is copied, so it’s instantaneous. If neither the parent nor child branch makes any writes, they remain two “views” of the same underlying data. When a write does occur, the affected chunk is copied and written to a new location, and the child’s index now points to that new chunk. The parent keeps pointing at the original chunk. This is textbook copy-on-write (CoW). Only diverging data is duplicated, and only at first write. Most chunks remain shared as long as they aren’t modified, saving a ton of space when branches are short-lived or only lightly edited (which has become quite a common use case with AI agents).

The benefit of Xata’s approach is that it behaves exactly like a normal Postgres instance, because it’s just Postgres, with CoW branching and elastic storage behind the scenes. We didn’t have to fork or alter Postgres to do this, and instead innovated at the storage layer and in orchestration. Our Postgres instances see what looks like a very fast disk. The heavy lifting of making that disk CoW-capable, highly redundant, and network-accessible is handled by the Simplyblock storage layer. We chose this path so that we maintain 100% Postgres compatibility (extensions, planner behavior, etc.) and can take advantage of the huge ecosystem around Postgres.

From a performance standpoint, Xata’s storage architecture is built for low-latency and high throughput. The storage nodes bypass the kernel using user-space drivers via SPDK (Storage Performance Development Kit) to squeeze every drop of performance from NVMe drives. Data is synchronously replicated across nodes with an erasure-coding scheme for fault tolerance (think RAID, but distributed at cluster level). In plain English: it’s fast and durable. We’ve benchmarked it and, even with a network hop, observed throughput and latency very close to well-tuned local-NVMe setups and markedly faster than typical cloud block storage (e.g., EBS/RDS) or modern serverless solutions thanks to these optimizations. We plan to publish these benchmarks soon.

Because the Xata stack has been built with a cloud-agnostic architecture that is out-of-the-box Postgres on Kubernetes with a self-contained storage layer, we can offer Bring-Your-Own-Cloud deployments with minimal lift. Our control plane can launch the Postgres compute nodes in your cloud account or bare metal servers, attaching to the Xata storage cluster over the network. The data stays in your environment and never traverses the public internet. This is a big advantage in enterprise scenarios where this level of scrutiny matters.

Neon

Neon can be credited for building the first open-source storage-compute separation design for Postgres. They implemented it by building a bespoke storage engine for Postgres. In Neon’s architecture, when a Postgres compute node runs, it does not write to local disk. Instead, it streams all its WAL (write-ahead log) to a service called Safekeepers. Safekeepers are like a durable WAL buffer. They accept the WAL entries and replicate them across availability zones to ensure they’re not lost. Meanwhile, another component called the Pageserver is responsible for actual data storage. Pageservers consume the WAL stream from Safekeepers and apply it to a database page store. They keep recently used pages in memory and also store data on disk or in cloud object storage as the source of truth.

How does Neon achieve branching? They use a non-overwriting storage format in the pageserver. Essentially copy-on-write at the page/version level. When you create a branch in Neon, under the hood it’s like creating a new timeline starting at a specific WAL LSN (log sequence number). The pageserver doesn’t duplicate all pages for the new branch; it just starts a new sequence of WAL for it. Initially, the branch shares all history with its parent until a divergence occurs. Only when new WAL comes in (writes on the branch) do new page versions get written. This is effectively the same outcome as Xata’s copy-on-write, just implemented via a logical WAL timeline mechanism rather than at the block device layer.

One effect of Neon’s approach is that the Postgres compute nodes are stateless. If a compute node crashes or is stopped (say due to inactivity), you can later spin up a new compute node, point it at the appropriate timeline (branch), and it will retrieve whatever pages it needs from the pageserver. This is how Neon achieves scaling to zero and fast cold starts. The database state persists in the pageserver/S3, and a compute node can be brought up on demand to service queries, then shut down when idle.

The trade-off is that Neon’s architecture introduces additional indirection and complexity in the performance-critical data path (WAL network hops, page retrieval on cache miss). In other words, there is some inevitable overhead compared to a single-node Postgres with network attached storage. Particularly for very write-heavy workloads or very random OLTP reads that can’t all fit in memory. For many developer and test workloads, this overhead is might be acceptable. At larger scale or sustained high throughput, data retrieval might observe higher tail latencies due to that extra network/storage indirection. This additional complexity is one of the disadvantages of running a modified version of Postgres.

Supabase

Supabase’s approach to branching is the simplest conceptually. Each branch is just a new Postgres instance (plus the accompanying services) created from scratch. When you create a branch in Supabase, the platform essentially provisions a new Postgres container (or VM) for that branch, sets up a blank database, runs your migration + seed scripts to create the schema and to populate data.

There is no special storage magic here like copy-on-write. If you want a branch to have production-like data, you have to script it. Today, that means writing a seed.sql that inserts sample rows or copying a subset of data from prod through your own processes. At the moment, Supabase explicitly does not clone your data into the branch.

Because each branch is a full Postgres instance, they are fully isolated at the OS level (not just at data level). Aside from shared control plane components, one branch’s activity can’t impact another’s performance since they don’t share underlying storage or CPU. This is good for isolation, but it means branches are heavier weight. Supabase mitigates cost by auto-pausing these preview branches when not in use. Unless the branch is marked as persistent, you’ll incur a cold start after it’s been idle for > 5 minutes. You can mark the branch as persistent and flip between ephemeral and persistent options.

Supabase branching is leveraging the standard Postgres stack and as a result, the performance on a branch is the same as performance on any Postgres instance of that size. There’s no extra overhead of remote storage or CoW bookkeeping. The trade-off is that branch creation is much slower if you wanted to copy large amounts of data. In practice, Supabase expects you to only seed a small amount of data that is enough for simple tests. That is fine for testing logic and migrations, but it’s not adequate if you want to, say, test a complex query on a full-size dataset or train your latest model on production-like data. In those cases, Xata’s or Neon’s approach of branching the actual data shines.

Because each Supabase branch is a standalone Postgres, if your production DB is, say, 50 GB, and you wanted a full copy for staging, you’d need another 50 GB in storage for the branch. Xata and Neon would not double your storage unless you modified all that data in the branch. So for storage-intensive scenarios, Supabase’s model can be costlier.

Conclusion

Database branching isn’t a checklist feature, it’s a fresh take on how you should operate and interact with a database.

Xata treats branches as light, block-level snapshots, so large teams can clone production-sized datasets safely and predictably.
Neon re-architects Postgres for serverless elasticity and instant branches.
Supabase keeps things familiar, favoring full stack branches with additional microservices around Postgres.

Features and architecture tell only half the story. What does this look like in the real world and how do these choices impact pricing and cost for customers? In part 2 we’ll translate architectures into invoices, walking through each pricing model and three common branching scenarios.

If you’re a Postgres user and are branch-curious, I invite you to give Xata a try. We’re currently in private beta and onboarding new teams on a daily basis. You can sign up for early access here. Feel free to pop into our Discord to ask any questions or simply say hi.

Xata Agent v0.2.0: Powered-up chat, custom playbooks, GCP support & more

AlexF — Wed, 16 Apr 2025 16:37:18 +0000

Last month, we introduced the Xata Agent — an open-source AI agent designed to monitor and optimize your PostgreSQL databases. The feedback has been tremendous so far and our community tends to agree that the future of observability is significantly more agentic than our current one. With the v0.2.0 release today, we are doubling down on that belief with a bunch of new features and improvements.

Improvements to chat

One of the key parts of the agent workflow is chat. Every playbook ran, event captured and notification sent leads back to a chat interface with the agent. We recently made some improvements that level-up our chat experience and open the door to some amazing possibilities.

Chat persistance

Previously, chats were only persisted as part of the playbooks run history. You can see the expanded run history for the scheduled playbook below.

Now you can spark up a conversation with the agent and revisit it at any time. This makes it perfect for any ad-hoc queries or an opportunity to build context over time for any long-running investigations.

Better syntax highlighting

There are many times when the agent will be sharing SQL or configuration parameters to help optimize performance issues or troubleshoot errors in real time. With this updated design, you can visually see what’s important faster. When it comes to databases, sometimes even seconds of downtime can be expensive.

Artifacts

Tables tend to be one of the most common outputs required when interacting with a database. In v0.2.0 we’ve added artifacts to chat, making it possible to output and interact with a table or document. These are transparent to the user and the agent will decide when best to surface them, but if you ask nicely, I’m sure you’ll get the output you’re looking for ✨

We’re especially excited about artifacts, this framework allows us to introduce a variety of new chat experiences. We plan to build out a library of artifacts for the agent starting with an interactive SQL editor.

Custom playbooks

If you are one or have ever worked with an SRE, playbooks are a foundational part of observability workflows. They are critical to ensuring uptime and typically the reason for swift recoveries when downtime occurs. Every unwanted behavior or degraded pattern observed has explicit steps and actions to remediate. If an event has never been observed before, a new playbook is added. Playbooks are a core element to the monitoring and actions taken by the agent and we ship with a handful of generic playbooks that are useful for most PostgreSQL instances.

We realize every company, business and database are unique and different. With custom playbooks, you can create your own playbook or fork one of Xata’s. This is the first step toward building out a library of custom workflows specific to your needs. Taking this further, we have already started work on adding custom tools via MCP and envision the agent authoring and revising its own playbooks.

Support for GCP CloudSQL Databases

Our initial release supported vanilla PostgreSQL instances and AWS flavors of PostgreSQL. Adding native support for cloud providers allows us to pull in monitoring data and logs available as context for the agent. With this latest integration, you can now use CloudSQL logs and monitoring data to help monitor, troubleshoot and optimize your PostgreSQL database.

Starting today, you can add a CloudSQL database to any new project through the agents interface.

Support for new models

We’ve heard it from numerous leaders in the industry, Gemini provides pretty good answers when it comes to PostgreSQL. While it was on our roadmap, we’d like to give a shout out to a valued member of our community Leonardo Benedet for adding support for Gemini! You can now choose Gemini 2.0 Flash, Gemini 2.0 Flash Lite and Gemini 2.5 Pro as the model for any chat or scheduled playbook.

Given the timing of the release, we've also just snuck in support for GPT-4.1 and GPT-4.1 Mini ⚡

Connection re-use

Agents can be pretty chatty. If you have an active database, there can be multiple conversations happening in parallel. Each tool interacts with a target database and we now ensure that the connection is re-used between tool calls. This will help restrict the number of connections open to your database from the agent. You can read more up on the implementation in this pull request.

Errors as context

There is now more robust error handling by the agent. With v0.2.0 all errors are fed back to the models as context so it can react to errors in real time.

Up next

This was an exciting release and we encourage you to check out the full changelog to dig into all the other improvements and bug fixes that came with this release. We are dogfooding the agent with the Xata platform, monitoring and optimizing ~40,000 active databases and continually improving the agent to work with PostgreSQL at scale.

On our near term roadmap you can expect to see:

Support for custom tooling and MCP servers so you can customize not just your playbooks, but the actions the agent takes.
Approval workflows through GitHub to review changes recommended by the agent.
A hosted SaaS version of the agent so you don’t need to run any infrastructure yourself.

We can't wait to hear what you think about v0.2.0! If you'd like to see a new feature, supported model or enhancements in the Xata Agent, we welcome you to open up an issue, create a pull request or just come say hi in discord.

Automating the creation of Shopify stores with Xata

AlexF — Thu, 14 Dec 2023 15:00:07 +0000

Katriel Lucas is a self taught, full stack developer out of Brazil who favors SvelteKit, Astro and serverless tools. He and the team at Loja De Dropshipping Oficial are looking to remove the technological barrier for any small business that wants to make a web store.

Making Shopify even more accessible

Shopify, a platform that millions of entrepreneurs choose to build their business, operates in a market where approximately 23% of all online sales are fulfilled through dropshipping (MarketSplash, 2023). Their platform is wonderful for digital natives, but still requires you to have some technical knowledge to build a good store front and connect the dots. Katriel and Loja De Dropshipping Oficial (LDO) are looking to make the benefits of Shopify accessible to absolutely everyone.

How are they planning to do this? By automating the creation of Shopify stores. Simply provide some information about your business and their solution will create a customized website for you that includes customer tracking, production statistics, and more.

Serverless for the win

Their solution is built on a modern serverless architecture with SvelteKit, TypeScript, Cloudflare Workers and Xata as the chosen tech stack. Each customer gets their own table in Xata.

Katriel initially came across Xata while searching for a serverless database to begin developing LDO's MVP. Xata was chosen because of the vertically integrated experience and generous free tier. What was originally meant to only be used for a prototype, eventually made its way to production because of the reliability and performance seen during the development phase.

LDO leverages Xata to extend and better facilitate Shopify's personalization capabilities. When a customer buys the LDO services, a large JSON object is automatically created. The JSON object created for each customer includes details like email, phone number, Brazilian ID, address, product data, and order status, among others. As customers personalize their shop through the chat interface, they input specific details such as credentials, logos, URL, name, color schemes, etc. This facilitates in shop customization and also gathers feedback for continuous improvement. Additionally, data on LDO agents’ responsiveness and efficiency in helping with shop creation is collected, enhancing overall service quality and refining the user experience.

All data, ranging from shop metadata and user permissions to business logos and agent productivity metrics, is stored directly in Xata. Xata powers the entire application and all customizable aspects of the stores.

There were a lot of things that Xata solved for us. Our app is divided into three parts. The shop profile with customer information, time series data for sales metrics, and the images for the shop itself. All three use cases use only one database, Xata.\
Katriel Lucas - Full Stack Developer

Katriel, Dymas, Heron, and the rest of the team at LDO are building out a new solution that lowers the barrier of entry for any store owner or entrepreneur to have an online presence. In addition to their automated approach to shop creation, the company also offers courses and mentoring to help people start a dropshipping business. Teaching their customers proven strategies that tend to convert more.

Their success is already taking off and it’s tied directly to the speed at which they can introduce new features and provide value to their customers. Having a modern, serverless architecture empowers them to do much more with a smaller team.

Feedback and feature requests

As the conversation steered towards what’s next, we asked Katriel to share some of his favorite parts about Xata and where he thinks we can improve. Here were some of the reasons Katriel chose Xata for this application.

TypeScript SDK. The TypeScript SDK is very easy to get started with and made development much quicker for Katriel and his team.
Zero Ops. There is no need to manage a database or infrastructure. This was huge for them because they could focus on the application and customer needs.
File attachments. File attachments really reduced the amount of tools we needed for image uploads and the logo definition process. The out of the box transformations were killer.

When asked what he’d like to see from Xata, here’s what Katriel shared.

Serverless functions. Cloudflare is the only other service required to make this solution possible. If Xata supported serverless functions, they could consolidate all their tools.

Share your Xata story

Do you have a similar story or community contribution you’d like to share? Send us an email or ping us on Discord if you’d like to be featured in our community spotlight. Until then, happy building 🦋

Add feature flags in Astro apps using Xata and Vercel

AlexF — Tue, 12 Dec 2023 21:07:33 +0000

In this tutorial, we're going to show you how to incorporate feature flags into your Astro app using Xata and Vercel. Imagine you're working on a feature, and you want to use email addresses to define the controlled rollout of the feature. We'll guide you through setting up these feature flags in Xata, allowing for a controlled rollout of new features. This enables you to gather feedback from a select group of users before launching it more broadly. So, let's get started on enhancing your app's functionality.

What are feature flags?

In this tutorial, we'll show you how to use feature flags in your Astro app with Xata and Vercel. Imagine you're working on a feature and want to control its release using email addresses. We'll guide you through setting up these feature flags in Xata, allowing for a controlled rollout of new features. This way, you can gather feedback from a select group of users before a broader release. Let's get started:

Before you begin

Prerequisites

Tool	Description
Xata	A serverless database platform for data management.
Astro	A framework that combines frontend and serverless backend capabilities for building modern web apps.
Tailwind CSS	A CSS framework for rapid and responsive styling.
Vercel	A cloud platform for deploying and scaling web applications.

You will need a Xata account
Node.js 18 or later

Configuring Xata

Start by creating a Xata account, then log in to create a database.

After creating your database, you'll need to make a table for your feature flag attributes.

Great! Now that you've completed that step, you should see the table in its default state, as shown below 👇🏻

Let's move on to adding the feature flag with it’s relevant properties in the table you’ve created.

Creating feature flags in Xata

In this particular example, you’ll create a feature flag that allows us to process email domains, such as @someone.com, @gmail.com, etc. and define a percentage number so that the feature flag can be rolled back whenever required.

First, add the percentage attribute. Click + and select Integer.

Set the column name to percentage and avoid any null values. Select the Not null option and set the default value to 51.

Great! Now, let’s add the contains attribute. By setting up a contains attribute, you can target specific conditions or criteria within your app. For instance, if the attribute is set to @someone.com, you can tailor the app's behavior for users with email addresses containing this domain. To add the attribute, click + and select String from the dropdown.

Set the column name to contains and again avoid any null values. Select the Not null option. Choosing the string data type allows you to specify text-based conditions. Marking the field as Not null ensures that every record in the database has a value for this attribute, maintaining the consistency and reliability of your data. Set a default value of, for example, @someone.com.

Awesome! We’re now done with configuring the feature flag table and now can use it in your frontend to customize the onboarding flow.

Setting up the project

Fork the repository by navigating to the original GitHub repository at https://github.com/rishi-raj-jain/adding-feature-flags-to-your-astro-app-with-xata-and-vercel.
Click Fork at the top right corner of the page. This creates a copy of the repository in your GitHub account.

Once the repository is forked, clone it to your local machine. Replace your-username with your GitHub username in the following command:

git clone https://github.com/rishi-raj-jain/adding-feature-flags-to-your-astro-app-with-xata-and-vercel
cd adding-feature-flags-to-your-astro-app-with-xata-and-vercel
npm install

Configure Xata with Astro

To use Xata with Astro, install the Xata CLI globally:

npm install @xata.io/cli -g

Authorize the Xata CLI to associate with the logged in account:

xata auth login

Great! Initialize the project locally with the Xata CLI command with something like what is presented below:

xata init --db https://Rishi-Raj-Jain-s-workspace-80514q.us-east-1.xata.sh/db/feature-flags-with-astro

Lastly, answer some quick prompts to make the integration with Astro seamless for you.

Configure the Astro frontend

In this section, you'll learn how to customize an onboarding flow using feature flags set in Xata. You'll implement form actions in Astro routes, fetch feature flag from Xata, and define your own onboarding logic.

Implement form actions in Astro

With Astro, you can also allow transitions on form submissions.

Enable form actions with view transitions in src/layouts/Layout.astro:

---
import { ViewTransitions } from "astro:transitions";
---

<html>
  <head>
    <ViewTransitions handleForms />
  </head>
  <body>
    <!-- Added info here -->
  </body>
</html>

This setup allows you to combine both backend and frontend flows for a page in Astro. Suppose you want to handle a form submission that includes the user's email, process it server-side, and display various outcomes based on your logic, all on the homepage. You can achieve this seamlessly within a single Astro route, like src/pages/index.astro:

---
const response = { form: false }

if (Astro.request.method === 'POST') {
  try {
    // Indicate that the request is being processed
    response.form = true

    // Get the user email from the form submissions
    const data = await Astro.request.formData()
    const userEmail = data.get('email') as string

        // Fetch feature flag from Xata

        // Define our own processing logic
  } catch (e) {
    // pass
  }
}
---

{response.form && <DisplayLogicComponent />}

<form method="post" autocomplete="off">
  <input
    required
    name="email"
    type="email"
    placeholder="Email Address (a demo)"
  />
  <button type="submit">
    Proceed &rarr;
  </button>
</form>

Fetch the feature flag object from Xata

To customize the onboarding flow, the first step is to fetch the feature flag object from Xata. In this example, we’re gonna be using the percentage and contains properties of the feature flag to define our processing logic further. Using Xata Read, you can retrieve a record with a given ID, the-flag and destructure the relevant properties.

---
// Import the Xata Client created by Xata CLI in src/xata.js
import { XataClient } from '@/xata';

if (Astro.request.method === 'POST') {
  // ...
  // Fetch Feature from Xata

  // Create a Xata Client to fetch the flag from
  const xata = new XataClient({
    apiKey: import.meta.env.XATA_API_KEY,
    branch: import.meta.env.XATA_BRANCH
  });

  // Get the percentage property set in the flag
  // Get the contains property set in the flag
  const { percentage, contains } = await xata.db['my-flag-name'].read('the-flag');

  // Define your processing logic
  // ...
}
---

Implementing your own onboarding logic

Based on the extracted values from the feature flag object, we'll onboard users whose emails end with @someone.com, as specified in the contains variable, only if the percentage value for this feature flag in Xata is over 30. By adjusting the percentage value in the [Xata dashboard] to be above or below 30, you can effectively switch this feature flag on or off.

---
const response = { form: false, onboarded: false, userEmail: '' }

if (Astro.request.method === 'POST') {

    // ...
    // Define our processing logic

  if (userEmail) {
    response.userEmail = userEmail

    // Check if email contains the expected,
    // if yes onboard the user to a new flow
    if (percentage > 30 && userEmail.endsWith(contains)) {
      response.onboarded = true
    }

    // If not, let's not onboard the user to the new flow
    else {
      response.onboarded = false
    }
  }

}
---
<!-- Render conditional states using the onboarded flag -->
{response.form && <>{response.onboarded ? <Success /> : <Failure />}</>}

Deploy to Vercel

The repository, is now ready to deploy to Vercel. Use the following steps to deploy: 👇🏻

Start by creating a GitHub repository containing your app's code.
Then, navigate to the Vercel Dashboard and create a New Project.
Link the new project to the GitHub repository you just created.
In Settings, update the Environment Variables to match those in your local .env file.
Deploy! 🚀

Way to go! You've now successfully added feature flags to you Astro app with Xata and Vercel, equipping your app for further development and success!

What's next??

We'd love to hear from you if you have any feedback on this tutorial, if you'd like to know more about Xata, or if you would like to contribute a community blog or tutorial.
Reach out to us on Discord or join us on X | Twitter. Happy building 🦋

Holiday Hackathon

AlexF — Fri, 08 Dec 2023 20:09:09 +0000

In the past year, we've had a ton of fun hosting a number of hackathons and giving away cash prizes with premium swag to our community of Xataflies. That is why we're beyond excited to announce the second annual Xata Holiday Hackathon 🎉

It's the holiday season, and that means work is starting to wind down a bit. There's more time for family and friends. If you're fortunate (and brave) enough to travel during the holidays, maybe even a vacation. But with all that time on your hands, there's a nagging feeling in the back of your mind. You have had a million dollar idea that you've been wanting to build all year. Maybe you already bought the domain and have been sitting on it just waiting for the time to build.

We're here to tell you that now's your chance. With Xata Holiday Hackathon, you can turn that side project into a side hustle and win up to $500 for an app built on top of Xata. The best part? If it takes off, you can easily take that prototype to production scale with our generous free tier in the new year. Take advantage of features like file attachments, our LangChain integrations and full-text search to scratch that itch and build the next big thing.

Rules

Excited? We are too! Here are the rules ✅

Xata engineers will vote to select the winners of the Holiday Hackathon
The top 5 entries will receive $500 each
The top 10 entries will receive limited-edition swag
All entries must be submitted by January 15, 2024
You can submit more than one entry, however, only one app participant will be eligible for a prize
Ensure your app's code is publicly available, to showcase your use of Xata
Submissions for this hackathon must be original and unique to this challenge; entries used in previous hackathons are not permitted or eligible

How to submit your entry

After you've built your app, submit your entry using the form here.

We will need:

Your name and email
A link to the application URL
A link to the application repository
Any social profiles you'd like to receive shout outs in

Ready to join in on the fun? Pop into our Discord if you have any questions and follow us on X | Twitter to stay up to date with the latest. Sign up today, we can't wait to see what you build 🦋

Simplifying architecture for a hotel management SaaS solution

AlexF — Fri, 03 Nov 2023 13:00:00 +0000

Emanuel Arcos, a full-stack developer from Buenos Aires with over 7 years of e-commerce experience, is making waves. He recently left the e-commerce world to become and entrepreneur and start his compnay Triqueta Software Solutions, with his eyes set on a brand new type of subscription service.

From scaffolding to solutions

Emanuel discovered Xata through the Next.js conference last year and thought he would try it out for his newest venture. Back then, he wasn’t thinking about building a SaaS solution for hotel management. He was focused on building management software for two businesses he’s a partner in — a kinesiology center and a local hotel.

With a stack built on Next.js, Tailwind, and Tremor, he was in search of a serverless database. Remembering Xata, he realized it checked the boxes for reliability, operational management, and feature sets he was looking for. Emanuel admitted that in the beginning, it was a little scary choosing Xata. When a platform is new and you’re building a big application, it’s important to really trust it. In a sense, it’s a gamble.

What turned him around? Our community was the largest deciding factor.

His first management software project was for a kinesiology center. Emanuel created a system that handled scheduling, invoices, and administration, transforming the center's operations and business.

With learnings from this business, he expanded on the application scaffolding and applied some of the same ideas and capabilities to hotel management workflows. The application he built handles check-ins, monitors client transactions, stores bookings in a calendar, handles room inventory, and even sends quotes via WhatsApp to future customers.

The foundation around all these experiences are built on Xata. Booking and transactions are stored as relations between tables, finance time series data leverages the aggregation endpoint, and the app itself puts the Xata TypeScript SDK to heavy use. Because Xata removed a lot of complexity at the data layer and plugged right into his developer workflow, Emanuel was able to build out both of these solutions in just a few months.

Xata was a game-changer for me. I’m not great at DevOps and database infrastructure management, which I find rather tedious. Xata takes care of this with an excellent developer experience. Thanks to Xata, I was able to build out both of these applications in just two months.
Emanuel Arcos - Entrepreneur

Turning success into a subscription

These days, Emanuel is building off of his success in crafting these different management solutions and planning to deliver a suite of functionality for a full-fledged hotel management SaaS solution.

The global hotel and hospitality management software market is expected to grow at a CAGR (Compound Annual Growth Rate) of approximately 8-10% over the years leading up to 2025. This growth can be attributed to increasing technological adoption in the hospitality industry. There is a ton of opportunity here and Emanuel is excited to enter this space.

He plans to offer various features, including scheduling, invoice generation, inventory, and revenue management, across different tiers. Hotels can then select from these options, much like an a la carte menu, to best meet their requirements.

The new software is still in the works, and Emanuel is planning to add full-text search and file attachments to a number of experiences. If you’re interested in learning more, don’t hesitate to reach out to Emanuel on LinkedIn.

Feedback and feature requests

As we chatted about the future, we asked Emanuel to share some of his favorite parts about Xata and where he thinks we can improve. Here were some of the reasons Emanuel chose Xata for his businesses.

Xataflies. Throughout the interview, Emanuel gave many shout outs to the responsiveness and engagement of the Xata community.
Zero DevOps required. Not having to worry about database monitoring or management was one of the key deciding factors of choosing Xata for his solutions.
Tool consolidation. The combination of OLTP and OLAP data stores allowed Emanuel to simplify his architecture for future and current transactional, time series, full-text search and storage use cases.
Developer experience. The TypeScript SDK and in-app playground experiences made development much faster across the board.

When asked what he’d like to see from Xata, here’s what Emanuel shared.

Better support for Next.js server components. Emanuel is using the app router paradigm in Next.js and ran into some issues caching Xata results using the SDK directly on the server components. He’s looking for better support in the docs for this use case.
Lower latency globally. Related to the caching use case, Emanuel would like to see better support and lower latency on the edge.

Share your Xata story

The next era of databases are serverless, adaptive, and collaborative

AlexF — Wed, 14 Jun 2023 19:18:31 +0000

Tell me how you really feel about your database

First, let’s get real. Before we dive into where we believe databases are heading, let’s take a step back and level set on where we are today. If you’re operating an application at any type of scale and have business critical data in it, you’re likely terrified to make changes to your production database. And rightfully so. It’s a time intensive process to backfill, many things can generally just go wrong and there are downstream impacts to your application, non-primary data stores and external services. As a result, you are likely to choose to only make additive changes, never renaming or modifying columns, until the schema becomes a weird puzzle that mirrors the evolution of your company and application.

Take yourself out of reality for just a second. Doesn’t this feel wrong? You shouldn’t be afraid to make real changes to your database in production. You and your team should only be worrying about one thing, building the best and most efficient application for your users.

Most applications have similar data requirements

The story feels as old as time, or at least as old as January 1, 1970. Whether it’s a monolithic application built through the waterfall methodology or a modern app crafted by a multitude of micro-services that deploy 100 times a day, you eventually run into the same problem: history does, in fact, repeat itself.

As the needs of your users grow, so do the capabilities required to support their new use cases. Search experiences require different backends for recommendations, natural language and free text search. Event driven applications require a time series data store for real time analytics and workflows. Machine learning and artificial intelligence models vary by use case. The combination of these different requirements result in applications composed of various data services exposed through a wide range of developer experiences, pricing models, and new domain expertise within the team. As your business scales, this complexity grows exponentially and execution tends to slow down. Things get sticky when there’s a lot of glue.

Tomorrow’s builders will expect more from their database

Databases have been around for a while now. The database as we know it today starts in the 1970’s, over 50 years ago. Since that time we’ve seen the birth of the relational database, the rise of NoSQL, the ever persistent lingua-franca of data (SQL), and the evolution from on-premise to “the cloud”. Over the last few years, serverless technologies have taken off and the database is no exception. Data stores that have been around for decades are in the process of or already providing serverless offerings. We’ve shared our thoughts on serverless databases in this blog and now live in a world where you really do not have to worry about configuration, scaling, upgrades or maintenance of your infrastructure. At the scale most applications operate at, things “just work”, production readiness is assumed, and low latency is an expectation.

Alongside the rise of serverless are a few other emerging technologies. Maturing low code platforms and the explosive innovation surrounding generative AI. Building applications is getting easier and every developer is assumed to be a full-stack engineer. As these new offerings level-up the individual developer, the expectations placed upon them are also increasing. With the current state of the industry, smaller teams are not only being forced, but also empowered to be more impactful. If you’re interested why developer experience is important to your business, this recent blog from GitHub provides a great overview to the problem space and shares how generative AI is changing the landscape. Removing friction and providing larger building blocks will allow junior, senior and non-traditional developers to tackle more complex problems faster.

With this perfect storm of serverless infrastructure, an influx of tools to boost developer efficiency, and more people empowered to build applications, the next generation of builders will look a lot different than they do today. The 99% developers will be more generalists. Meaning, they will not care to learn the intricacies of a new data store or service to provide some additional functionality to their application. Most applications eventually need similar flavors of the same things. The database for tomorrow’s applications is multi-model, configurable, and built for developer efficiency. At Xata, we believe a data platform will fuel the next wave of applications - one service that provides a complete data layer and evolves with your application needs.

A data experience for everyone

Now this won’t be easy. Databases are hard, and hard for good reason. Data is at the heart of every businesses, user experience, and use case. The database is the one thing you don’t mess with. Ideally, it’s battle-tested, resilient, highly available and performant. Which is why it’s so hard to make changes to it in production applications. That being said, there are common data problems that don’t quite yet have standardized solutions. Data replication between services, zero downtime schema migrations, and horizontal sharding are just a few examples. These are the types of technical challenges that must be solved in order to make a data platform the go-to-solution for this next generation of application developers. Databases are hard, but the data experience for modern developers needs to be easy and quickly add value, not a time sink or system you’re terrified to touch.

As the non-functional requirements tied to the data layer become solved problems and the harder parts about databases become easier, tools of choice will be selected based on the overall experience. We’ve seen this mental shift occur in many industries, technologies and consumer applications. Data solutions will be chosen based on what they can integrate with, how much more efficient they’ll make your team and how accessible they are to the broader organization. When availability, scalability, security and performance are simply expectations — an Amazon-style customer obsession towards developer and user experience becomes equally as important.

Taking this a step further, there are data paradigms that will never go away. Primarily, the familiarity and flexibility of a tabular data store (spreadsheet) and the logical way to communicate with your data (SQL). These ways to enter, transform, and collaborate with data are understood by most today and commonly taught in school as tools to make you successful, regardless of future profession. As application builders become more generalists, they will gravitate towards solutions that not only meet their application needs, but are also easily understood by their colleagues. Not only because this is a good user experience, but because it makes the team more effective. There is less of a learning curve when accessing your data feels familiar.

Building the next phase of databases

Application builders will need a database that meets all of their application needs, is built for developer efficiency and collaboration with everyone, not just your engineering team. At Xata, we believe this is the way the world is heading and we’re building a solution to meet the needs of tomorrow’s builders. Since our launch last November, we’re seeing that our vision is resonating with our community. Folks are excited to not have to worry about bolting on services to their application and that they do not have to sacrifice great development experience for their data layer. We meet them where they are today or where they will be soon.

Looking ahead, you’ll see further investment in both our data platform, making hard data problems at scale feel magical and exposing this all through a non-negotiable, premium developer experience. To see what’s on deck, you can view our roadmap here. If you’d like to chat more about where we’re going, come find us on Discord or book some time to chat.

If you find the types of problems we’re trying to solve interesting and our vision clicks with you, we’re also hiring.

Modern database workflows with GitHub, Vercel, Netlify, and Xata

AlexF — Wed, 17 May 2023 16:44:23 +0000

We’re excited to announce a brand new workflow for developing with databases and preview deployments! With todays announcement, Xata is releasing an application for GitHub, an integration for Vercel, an integration for Netlify, git-like commands for our CLI and preview branches. The combination of these features create the ideal workflow for modern application development.

The X is for extended

Before we dive in, let’s quickly recap what Xata is. The X in Xata stands for extended, as in an extended database. Xata was founded with the goal to go beyond a serverless database offering and provide a single service that handles all of your data needs. We know management of multiple services and data synchronization between them is hard. Xata takes care of all of that for you.

In support of that goal, it is our mission to radically simplify how developers work with data. The Xata platform includes a relational database, a search and analytics engine, a vector database, and AI capabilities. All of these features are built on industry best practices, ensuring a reliable and scalable solution that can be accessed through a RESTful API and type-safe SDKs.

While we plan to continue to invest in new types of data stores for our multi-model data platform, today’s announcement is focused on our new workflow and improvements to the developer experience when working with your data.

Previews will replace pre-production environments

There is one thing that every engineering team, in companies big or small, has in common: pre-production environments. Dev, QA, staging, or whatever code name you’ve landed on — there typically is an environment for daily builds and another with all the feature flagged turned on. This is a great way to build and collaborate with your team, but comes with its own set of downsides. Not only are these environments another piece of infrastructure to manage, if they go down, they impact tens, hundreds, or even thousands of developers shipping code.

In the last few years with innovations from companies like Vercel and Netlify, preview deployments of your application have empowered the individual developer to ship fast and collaborate with their team before pushing to production. Over time, we expect this workflow to negate the need for pre-production environments entirely. Until very recently, there has been a gap in this workflow at the data layer.

Introducing preview branches

As scalability and availability in the cloud become solved problems, focus is now turning towards user and developer experience. A number of solutions (Xata included) have began introducing git-like branching to your database. Making it easy to diverge from your main database and merge any changes back in. This workflow is very similar to the git, a version control system nearly every developer is familiar with.

With preview branches now available in Xata, every pull request will be paired with a preview-{owner}-{branch_name} branch of your database. The data from your main database will be copied over. This unlocks a new way to work and has a number of benefits:

Safely iterate on your application with production data knowing you won’t impact your production environment and end users.
Freely modify schema and code changes alongside your application in an isolated preview environment.
Obfuscate sensitive data and PII for individual developers who do not have the appropriate permissions (this is coming soon).

While these advantages are great, they are only useful if you can actually use them. Which is why the team at Xata focused heavily on a developer experience optimized for efficiency and security.

A database that meets you where you are, in git and GitHub

With this release, Xata is the first solution to complete the end-to-end developer workflow for a database.

Schema and migrations exist as code in git, where they are stored as files in your repository and can be reviewed like any other code change.
A new preview database branch is created automatically for each pull request and copies the data from the main branch.
When a pull request is opened and on every push to the branch, a comment in GitHub provides the current status and any failures that occur are shared in a new comment.
When the pull request is merged in GitHub, Xata simultaneously merges the database branch to the main database branch.
If there are migration failures detected, Xata will block the promotion of the build to avoid breaking the application until the failures are resolved.

In order to take advantage of this new workflow, you’ll need to install the Xata App for GitHub.

Once you have successfully installed the GitHub app, you can connect your database to a GitHub repository.

After you’ve paired your GitHub repository with your Xata database, working with preview branches is only a few commands away.

git checkout -b review_stars
xata branch create review_stars
xata pull review_stars
git add .
git commit -m 'add rating column to db and stars'
git push --set-upstream origin review_stars

xata branch, xata pull , git commit and git push will automatically create a preview branch with data from your production database for your new pull request.

Each pull request will have a comment with the latest status of your preview branch. If you’re not making changes to the database, you can confidently build without impacting your end users. If you are making changes to the database, the pull request will be blocked from merging until all checks have passed ensuring a seamless migration.

Completing the preview deployment with Vercel and Netlify

Similar to GitHub, Xata is also releasing an integration for both Vercel and Netlify. Integrating with either of these platforms will result in a Xata preview branch paired with each preview deployment.

For more details on how to get these set up, check out our documentation.

While we’ve decided to focus on these two platforms first, we have all the foundational pieces in place to create integrations for other preview deployment platforms. Have one in mind? Drop a feature request here.

A new way to build

At Xata, we are empowering a new age of developers to build more advanced applications without needing to think about the data layer. We are excited about what this new workflow unlocks and the capabilities we plan to build on top of it. You can view our publicly available roadmap to see what’s on the horizon and come chat with us on Discord if you have any questions.

If you’re interested in using this new workflow for your next project, sign up today to take advantage of our production ready-free tier (no credit card required). For those that are already using Xata, simply update your SDK and CLI to the latest version to take advantage of this new workflow. Our documentation is the best place to get set up.

We can’t wait to see what you build 🦋