Xata.io

Monica Sarbu is at AWS Summit Hamburg today with Divyendu Singh and Simona Pencea, in the AWS Startup Zone, Hall 4. Postgres for agent scale is the conversation we're here for. If you're building anything that needs thousands of database environments, per-agent isolation, or branches for agent sandboxing, come find us. In the AWS Startup Zone (Hall 4) until close.

The Xata team is live at AWS Summit Hamburg 2026 today. If you're building AI agents and hitting the wall where Postgres wasn't designed for what you need - thousands of isolated, production-like database environments, spun up instantly, without paying for always-on compute - come find us. We're at the AWS Startup Zone, Hall 4. Stop by the booth to see how Xata gives every agent its own Postgres branch, and let's talk about what database infrastructure for agent scale actually looks like.

There’s something we’ve been feverishly working on, and today we finally made it public: pg_deltax (δx) -> a fast time-series extension for PostgreSQL. Think: an Apache-licensed alternative to Timescale. It’s still very early days, but the benchmarks already look really good. On ClickBench, pg_deltax is significantly faster than Timescale on almost all queries, with a combined score 4.7× better. It’s still slower than analytics-focused databases like ClickHouse or DuckDB, but honestly not that far behind. And you get that kind of performance without ever having to move the data out of Postgres. 🐙 GitHub link: https://lnkd.in/dxijzkMi

DeltaX is now public: the TimescaleDB alternative with Apache 2.0. Preliminary ClickBench shows DeltaX running analytical queries ~4.7× faster than TimescaleDB; the full methodology is in the README. DeltaX is a Postgres extension that adds columnar storage and time-series compression to PostgreSQL 17 and 18. The compressed data lives in regular Postgres tables, so pg_dump, replication, crash recovery, and your existing backup tooling all keep working without change. Under the hood: type-specific codecs (Gorilla XOR for floats, Gorilla delta-of-delta for timestamps, dictionary for low-cardinality text, block-LZ4 for high-cardinality text, bitmap for booleans), vectorized Rust execution via custom scan nodes that bypass per-row ExecQual, segment pruning with bloom filters and value-presence bitmaps, parallel aggregation, and a shared-memory blob cache. Status is alpha, PostgreSQL 17 and 18. If you find it interesting, please star the project on GitHub: https://lnkd.in/dhzdqGDf

Months of work just turned public. Star the repo and try the quickstart: https://lnkd.in/dhzdqGDf

If you're at AWS Summit Hamburg on May 20th, swing by Hall 4 Startup Zone. Monica Sarbu and the team will be there to talk Postgres for agent scale. Book a slot at the booth in the post below.

We shipped pgstream v1.0.2 this week. Three things changed: Stream-mode WAL batching in the Postgres-to-Postgres sink. Post-snapshot catch-up no longer stalls on high-churn tables full of bulk INSERTs or DELETEs. We are honest about scope: it's the Postgres sink only, and only INSERT plus DELETE coalesce. UPDATE and TRUNCATE still process row by row. Decode-time table filtering inside the source Postgres. The wal2json plugin now accepts add_tables and filter_tables directly, so the rows you do not care about never enter the pipeline. This one is a community contribution from Blake Watters. Go 1.26.3 for the security fixes that drove the release. If you are still on the v0.9.x maintenance line, v0.9.12 is the same bump with no functional changes; upgrade now. Release: https://lnkd.in/d4Jq8-_6

Every Xata Postgres branch now ships with a managed PgBouncer endpoint, included. A Postgres connection costs about 5MB of backend memory. That's fine when traffic comes from a handful of app servers. It breaks when traffic comes from serverless functions, edge workers, or AI agents that open a connection per request. Postgres wants fewer, long-lived connections; modern apps produce many short-lived ones. A pooler reconciles that. We chose to ship one PgBouncer pod per branch, on the same node as the database, in the same memory budget. Pool size auto-tunes to 0.9 of max_connections and re-tunes when the instance changes. If you connect directly to Postgres, append -pooler to your branch ID. One-line change in your connection string. Branching gives you cheap copies of Postgres. Pooling gives those copies somewhere to take traffic. We needed both. Writeup: https://lnkd.in/dEgeSkf4

We rebuilt the storage layer behind Xata Cloud. Xatastor is the new storage engine that powers Xata’s database branching and per-tenant Postgres at scale. Our CTO Tudor Golubenco published the architecture deep-dive. Link in the first comment.

We’re seeing this firsthand with AI platforms we partner with: 👉 every agent needs its own isolated Postgres database 👉 at scale, that quickly becomes millions of databases 👉 many run on free tiers → cost matters a lot That combination pushes traditional storage past its limits. Most storage systems are built for a few always-on volumes. Agent workloads need the opposite: millions of mostly idle databases, created and discarded constantly. So we built Xatastor. A storage layer designed for this new reality. It enables Postgres-per-tenant use cases and ephemeral databases for agents, with copy-on-write snapshots, instant clones, and thin provisioning. Full details in the blog: https://lnkd.in/dTynRHy7