urbanists.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
We're a server for people who like bikes, transit, and walkable cities. Let's get to know each other!

Server stats:

523
active users

#postgresql

29 posts25 participants1 post today

What's new with Postgres at Microsoft? The 2025 edition of our annual blog post is now live.

Over the past year, the team at Microsoft who work on Postgres has contributed across multiple fronts:

🛠️ New features in Azure Database for PostgreSQL - Flexible Server
🧠 Code contributions to Postgres 18 (including async I/O!)
📦 Open source work on the Citus extension
🌍 Contributions to the Postgres open source community—things like @posetteconf, helping make @pgconfdev happen, the Talking Postgres #podcast, and sponsoring #PostgreSQL conferences around the globe

This year's blog post includes a hand-made infographic that maps out the major workstreams—plus highlights, explanations, links, and shout-outs to some of the many people behind the work.

If you care about PostgreSQL—as a user, contributor, or fan—I hope you'll give it a read.

📝 Read the full blog post on Microsoft Tech Community: techcommunity.microsoft.com/bl

I'm very impressed how easy it is to use #OpenStreetMap data locally:

1. Download a subset of OSM on download.geofabrik.de/ for your country.
2. Use Osmium to filter by tags and export into a TSV.
3. Import the TSV into #PostgreSQL using a single \copy command.
4. Create a btree_gist index for #PostGIS geospatial and ordinary queries.

In less than 5 min, you're ready to run queries like "nearest restaurants around me" locally & fast!

Kudos for making it so simple, which is not easy. =)

download.geofabrik.deGeofabrik Download Server

In a short exchange with @jankatins I was stimulated to figure out a concise answer to needing to grab the previous or the upcoming non-null value in a column in PostgreSQL, in the order decided by the user, which would be similar to using `lead` and `lag` with the non-supported IGNORE NULLS directive.

The implementation I came up with nears poetry in its simplicity and elegance: gist.github.com/diraneyya/4455

previous() and upcoming() are window functions that retrieve the previous or the upcoming non-null value within a column in pgsql. - upcoming_previous_window_functions.sql
Gistprevious() and upcoming() are window functions that retrieve the previous or the upcoming non-null value within a column in pgsql.previous() and upcoming() are window functions that retrieve the previous or the upcoming non-null value within a column in pgsql. - upcoming_previous_window_functions.sql

🔎 Can PostgreSQL really handle vector search for AI? Absolutely.
Watch Vladlen Popolitov share how PostgreSQL is evolving with new index types, data formats, and query strategies—enabling high-performance AI-powered search without needing to reshape your data at #PostgreSQLDayBangkok

🎥 Watch the full session on the FOSSASIA YouTube channel: youtu.be/nql66umVM0I

After a month of serious use and study of PostgreSQL, I can say that I absolutely stand by this technology. It is rare that I found something that disappointed me.

Speaking of which, I find PostgreSQL's lack of support for the IGNORE NULLS behaviour on window functions to be quite unfortunate.

Continued thread

The #PostgreSQL upgrade (14->15) was shockingly easy on all three servers, which makes me wonder what horrors it has in store for me when I go to do the same thing on my work database servers, which have much more complicated access controls, replication, and other fun stuff like that.

After supper tonight, I'm going to try upgrading three #PostgreSQL "clusters" from 14 to 15. I don't think there are any anticipated gotchas, but that's why we do these things on little personal databases before taking a wrecking ball to prod.

Still going to have to research how to upgrade a "cluster" that is running streaming replication. That'll be a hassle for sure.

Some issues/tips with #AWS io1/io2 and #PostgreSQL replicas.

For io1/2 volumes on AWS you get provisioned IOPS and burst IOPS. If you read the fine print, MBpS throughput is computed based on provisioned IOPS, and works out to something like 1MBpS/80iops.

Think is, the walreceiver actually does relatively few IOPS but high MBpS because it's writing 16mb WAL segments and block flushes on tables. So you have to overprovision a lot. You've been warned!