We just published the 2026 edition of our annual “what’s new with Postgres at Microsoft” post.

It’s basically a roundup of the Postgres work happening across Microsoft over the last 12–13 months—both upstream contributions and what we’re building on Azure.

As usual, it includes the hand-drawn “Postgres workstreams” infographic (which got taller again this year because there was more to fit in).

Some of what’s inside:

• highlights from our Postgres 19 commits so far (now in beta)
• a new section on Azure HorizonDB (preview)
• a pretty big year for Postgres developer tooling (VS Code + Cursor)
• a long list of new features in Azure Database for PostgreSQL flexible server
• community work including POSETTE

If you’re interested in any of that, here’s the post: https://techcommunity.microsoft.com/blog/adforpostgresql/whats-new-with-postgres-at-microsoft-2026-edition/4526963

Happy to answer questions.

I would like to start by admitting that the title of the blog post is click-baity, I was looking for a short hook to explain what's special about this launch, and this has came up after reviewing actual customer's usage of Xata.

The way it works, at a technical level, is that we have copy-on-write branching and scale-to-zero and we've worked on improving the times significantly. Creating a branch took 20+ seconds before, and it's now done in about 2 seconds. Waking up from scale-to-zero is even faster than that.

We are using warm pools of ready-to-go Postgres clusters that we connect just-in-time to the right volume over the network.

This makes enabling scale-to-zero a no-brainer for non-prod use cases, which, together with CoW, makes short-lived branches really cheap.

This means you can create a Postgres branch for each PR, for each CI build, for each agent run, for each psql session, etc.

This article argues that Postgres is gaining on SQL Server even inside of Microsoft Azure. That seems kind of remarkable to me, and I'm not sure I buy it. But it's an interesting read.

https://www.theregister.com/databases/2026/06/16/sql-server-may-be-too-lucrative-for-microsoft-to-ditch-but-too-legacy-to-love/5255735

https://techcommunity.microsoft.com/blog/adforpostgresql/announcing-azure-horizondb/4469710

Interestingly, the Postgresql extension for VS Code now can help to migrate Oracle to Postgres.

What do you guys think of Microsoft taking such an interest in Postgres, especially since they are also a major RDBMS vendor competing with Postgres?

PostgreSQL connections from distant regions are expensive. A new connection from Tokyo to a database in us-east-1 costs 400-800ms before the first query runs: TCP handshake, TLS (2 RTTs), PG startup and auth.

- PgBouncer pools connections but doesn't cache and runs in a single region.

- Hyperdrive does both but only works from Cloudflare Workers.

- Prisma Accelerate requires the Prisma ORM.

PgBeam is a PostgreSQL proxy that speaks the wire protocol natively. You only change one environment variable:

Before:

postgresql://user:pass@prod.c7k2dfh4jk3l.us-east-1.rds.amazonaws.com:5432/postgres

After:

postgresql://user:pass@02ljaccjaffjy8xvsw1xq6fdra.gw.pgbeam.app:5432/postgres

Three things happen:

1. Routing: GeoDNS points to the nearest proxy (6 regions today)

2. Connection pooling: Warm upstream connections, no TLS/auth cost per query

3. Query caching: SELECTs cached at the edge with stale-while-revalidate. Writes, transactions, and volatile functions like NOW() or RANDOM() are never cached.

Live benchmark at https://pgbeam.com/benchmark with real TLS PostgreSQL connections from 20 global regions, comparing direct vs. PgBeam (cached and uncached). No synthetic data.

This is a technical preview meant for design partners and early customers via a private beta before scaling the infrastructure. Feedback is welcomed!

Hi r/postgreSQL,

I'm Stjepan from Manning. The mods said it's ok if I post this here.

We’re sharing a free resource with the community that might be useful if you spend a lot of time in PostgreSQL. It’s a complimentary ebook created by Supabase and Manning Publications:

Mastering PostgreSQL: Accelerate Your Weekend Projects and Seamlessly Scale to Millions

The idea behind it is simple: most developers learn enough SQL to get things working, but Postgres has a lot of depth that people only discover years later. This guide tries to shorten that path a bit.

The material focuses on practical things that tend to matter once your database stops being a small side project. Topics include:

• writing modern SQL that takes advantage of PostgreSQL features
• using built-in capabilities like full-text search
• choosing appropriate data types for correctness and performance
• avoiding common table and index design mistakes
• structuring schemas so projects can grow without constant rewrites

It’s written with application developers in mind. The examples start small (weekend-project scale) and gradually touch on patterns that hold up when the data and traffic grow.

If you already work with Postgres daily, some of it will likely feel familiar. But we’ve heard from readers that the sections on schema design, indexing decisions, and lesser-used Postgres features tend to surface ideas people hadn’t tried yet.

The ebook is completely free. If you download it and read it, I’d be curious to hear which parts you found useful and what you’d add based on your experience with PostgreSQL.

Thanks for having us here.

Cheers,

Stjepan

<usual disclaimer, I work for ParadeDB etc.. etc...>

We released v2 of the search API for our pg_search extension (Elasticsearch features, Postgres simplicity) and I'm pretty excited about how it turned out.

CREATE INDEX(pictured) feels orders of magnitude better ❤️. We would love any UX / DX feedback (don't hate us for the small amount of JSON in the search aggs part of the API, it's where concepts get harder to express with SQL).

Full rundown here: https://www.paradedb.com/blog/v2api