Latest Blog Posts

GitLab has a public story about deleting the wrong thing. In January 2017 an engineer who was trying to restore replication wiped a data directory they believed was on the secondary. It was on the primary. The postmortem they published afterwards is still one of the better things written about a database outage.

At PGConf.EU in Valencia last week a few people from GitLab came to me with the inverse problem. They have one table, 4 TB, on a primary with ten replicas, and they want it gone, on purpose, with as little impact as they can manage. It's an archival table: nothing writes to it, and nothing is supposed to read it.

DROP TABLE is the obvious answer and most of the time the right one. On eleven servers, a WAL (write-ahead log) archive and load balancer that routes reads by replica lag and the cost depends on three things. One is whether something still reads the table. The others are how much of it the kernel has cached and how the files sit on disk. So I measured it twice, on a Hetzner pair with a real streaming replica and on a GCE machine where a 1 TB table can't fit in the page cache. The other half is what happens when "nothing is supposed to read it" turns out to be only mostly true.

It’s been exactly one month since I published my work porting Greenplum to PostgreSQL 19 and isolating the minimal PostgreSQL core patches needed to run this minimal fork. It all started as a way to extract its ORCA analytical query planner and turn PostgreSQL into a modern, vectorized, high-performance DBMS. And I pulled it off! After a month of development, the database keeps getting faster. I’m now working on a GPU version. Even as a rough draft, on my MSI Raider A18 HX A9W laptop it runs queries faster than LTS ClickHouse: on MergeTree, 1.9x faster by geometric mean and 1.3x by total time, and on vexec_parquet, 13x faster by geometric mean and 18x by total query time.

I’d like to share the results of pg_vexec, an experimental vectorized database that beats ClickHouse on query execution time on Parquet and nearly catches up on MergeTree. I’ve published the telemetry from its ClickBench runs. It should be an interesting read, with plenty of charts, metrics, DBMS logs and numbers from deep inside the engine: https://igor-suhorukov.github.io/sql_report/

What pg_vexec is: https://igor-suhorukov.github.io/blog/2026/10/07/vectorized-postgresql-extension/

Source code for the CPU version:

• https://github.com/igor-suhorukov/pg_vexec
• https://github.com/igor-suhorukov/pg_ch_table_engines
• https://github.com/igor-suhorukov/cloudberry/tree/extension_postgresql_19

A financial firm hired me in 2010 to revise their Postgres cluster architecture. During my stint there, I learned a healthy respect for their event_log table. But perhaps “respect” is the wrong word here, as it was more of a deep loathing. This table, you see, was the canonical ledger of system events and consisted of several million rows.The high row count wasn’t a problem by itself. We kept a tight visibility window and archived frequently. Unfortunately for us, one of the columns was an unconstrained TEXT type that commonly held a large blob of XML. Thus any fetch from this table was inordinately slow. Writing was equally painful. We went through great pains to shape the application itself to avoid touching it except when absolutely necessary. It was evil incarnate.The performance of this table initially confused and enraged me—until I remembered about TOAST. Postgres likes to innocuously dub this backronym “The Oversized-Attribute Storage Technique” but DBAs in the field maintain a love/hate relationship with the system. Whether that’s justified is a different question.On the surface, it’s a way to store huge blocks of data elsewhere to keep tuples small and avoid exceeding the relatively petite 8KB data page size. Postgres creates a shadow table for the bulky content, splits it up into chunks, and stores a pointer in the original row. It’s an elegant solution to a pressing issue, but there are deep performance implications.So let’s dig into precisely why DBAs secretly dread large text-based columns, shall we?

Getting TOASTy

Over the past decade, the timing of PostgreSQL major releases has become very predictable: no earlier than the middle of September, and no later than the middle of October. This year is going to be different. PostgreSQL 19 most likely won’t be released until November, and it’s not impossible that the project could decide to postpone the release further.

Moreover, this year, several rather large features were reverted quite late in the beta period: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), and ALTER TABLE … MERGE PARTITION/SPLIT PARTITION were all reverted between August 27 and September 15. While major feature reverts are not especially uncommon immediately after feature freeze, which each year occurs on April 8, it is unusual to see multiple major features get pulled from the release at such a late date. So, what happened?

The PostGIS Team is pleased to release PostGIS 3.7.0! Best Served with PostgreSQL 19 RC 1 , GEOS 3.15.0 , postgis_tiger_geocoder 2025.2 , and address_standardizer.

This version requires GEOS 3.10+, PostgreSQL 14-19, Proj 6.1+, and libgmp. To take advantage of all postgis extension features, GEOS 3.15+ is needed. To take advantage of all postgis_sfcgal extension features SFCGAL 2.3+ is needed. Python 3 is a new requirement to build the documentation images. Visual examples in the docs are off by default. To build docs with them, configure with --with-visual-examples and make sure you have a running PostgreSQL instance; they are then generated automatically when building the docs (or explicitly with make -C regress visual-examples).

This release contains fixes since 3.7.0 release.

• source download md5

• NEWS

• HTML Online en ja zh_Hans fr

• PDF docs: en ja, zh_Hans, fr

• Cheat Sheets:

  • postgis: en ja zh_Hans fr
  • postgis_raster: en ja zh_Hans fr
  • postgis_topology: en ja zh_Hans fr
  • postgis_sfcgal: en ja zh_Hans fr

This release is a release candidate of a major release, it includes bug fixes since PostGIS 3.6.4 and new features.

If you store PHI on Supabase, you need a signed BAA and a project set to High Compliance. That takes care of the platform. It doesn't cover your RLS policies, your functions or your audit tables, and a HIPAA review will ask about those too.

Supabase's shared responsibility model says the same. It tells you to "always apply Row Level Security (RLS)" and leaves the access rules on sensitive tables to you.

The part Supabase handles

On the hosted platform, Supabase encrypts data at rest and in transit, signs the BAA and checks your project settings. Its HIPAA guide asks you to turn on Point in Time Recovery, SSL enforcement, network restrictions and Postgres connection logging, and to use MFA on every account that can reach the project. The Security Advisor warns you if any of that gets switched off.

The advisor and the database linter also flag a few risky shapes, like a table in public with RLS turned off. What they don't do is run your policies. They won't tell you whether a nurse at one clinic can read visits from another, or whether a deleted record left a trace in your audit table.

The part you handle

A HIPAA review will ask three things about your database.

• Who can reach which patient rows?
• Is every change to that data recorded?
• Can anyone change that record afterwards?

These map onto the Security Rule. Access control is 164.312(a)(1), which asks that access go "only to those persons or software programs that have been granted access rights". Audit controls are 164.312(b). Integrity, 164.312(c)(1), is about protecting PHI "from improper alteration or destruction". 164.312(d) covers authentication, and 164.308(a)(8) asks you to evaluate all of it from time to time and whenever things change.

On Supabase, nearly all of that lives in SQL you wrote. A screenshot of your policies won't show what the database does when authenticated calls one of your functions.

Getting the evidence from your own project

I built unitautogen hipaa for this part. Run it from y

Agent memory has been in fashion ever since agents appeared: it fights hallucinations and lets an LLM base its answers and decisions on your own information. Whether it is better to query that information from tables or from a graph is often decided on faith, after reading posts on the internet, without experiments and measurements of your own. In a study by Sequeda et al., GPT-4 answered questions over an enterprise SQL database correctly 16% of the time, and over a knowledge graph on top of the same database 54% of the time; the graph had an ontology with descriptions, while the SQL schema had only DDL: types and table and column names.

In my GraphRAG, the same information comes in two different forms. I extracted the data from the article “My PostgreSQL is faster than yours and has almost caught up with ClickHouse” into 34 PostgreSQL tables and turned them into a graph with an R2RML mapping. I connected both forms of knowledge to an agent over MCP and asked it 15 questions about the article: through SQL, through SPARQL, and with the agent free to choose between the two. In my experiment, the agent ran on three open-weight LLMs in turn. You can deploy them on your own infrastructure or laptop, and your data and questions won’t end up in the logs of a provider or of an aggregator between you and the LLM.

I also checked and calculated which is better for vector storage and semantic search: Lance or pgvector. I’ll share my measurements on current models of how best to search and where to store knowledge.

In the experiment, I caught DeepSeek coming up with an SQL injection to answer my question.

Two representations of the same data

With the help of LLMs, NLP, morphology and other scary words, my data turned into a graph representation and frames bound to RDF quads. The words of the text were broken down into entities, theses, measurements, replies, processes and so on. Each such fragment has its source in the original text, following the W3C Web Annotation standard. A derived layer of data wa

As promised during the session, I'm sharing the slides from the "Fostering Inclusivity with the PostgreSQL Europe Diversity Committee" presentation at the New PostgreSQL Community Members - Summit at PostgreSQL Conference Europe (PGConf.EU) 2026.

The community day sessions weren't recorded, so there won't be a video of this one. I've made an attempt at a transcript to go with the slides!

As with most people in the Postgres community, I wear multiple hats.

• In my day job, I’m a Senior Software Engineer at Snowflake.
• I talk about databases at Postgres events and at developer events to help spread the love for Postgres outside of the Postgres community.
• I’m on the org team for PGConf.EU.
• I chair the PostgreSQL Europe (PGEU) Diversity Committee.
• And I dream of "just quietly getting on with techie stuff"!

The PGEU Diversity committee wants to encourage increased diversity of all kinds within the Postgres Europe community. Whether that's ethnic diversity, gender diversity, work background, education, socioeconomic situation...

Why do we have a diversity committee?

Because we know that diversity is good for the whole Postgres project. Diverse people bring unique skills and viewpoints, making the Postgres project better for all of us.

One of our main goals is to make sure that everyone feels welcomed, represented, and valued within our community. and I know that the vast majority of people in the Postgres community also want everyone to feel welcome.

But if you look around, and you don’t see anyone else who looks like you, or who does the same type of job as you, or who has the same type of background as you, it can sometimes be hard to believe that you really belong.

This is an anonymised but sadly pretty accurate picture of the org team and the speaker lineup for a Postgres event in Europe in 2025, so it’s easy to see why sometimes not everyone feels represented.

Fortunately, the vast majority of the folks in the Postgres community really do wan

In the previous two posts you could see how to manage storage for create and drop and also to work with transactions. In this post you’ll learn how to handle TRUNCATE, which replaces the arena of a table with a new one. Doing that safely means choosing which arena to release based on how the transaction ends. This post handles the normal path, the in-place path Postgres takes for tables created in the same (sub)transaction, and the rollback cases for both.

In Part 5 you could see how the arena of a table was tied to the outcome of the transaction, so that CREATE TABLE and DROP TABLE neither leak nor lose an arena when a transaction or a savepoint rolls back. When TRUNCATE is called, relation_set_new_filelocator is called for a table that already has an arena, and it should replace that arena with a new one.

The normal TRUNCATE path

Postgres assumes that you truncate a table by giving it a new relfilenode and let the old one be reclaimed. For pg_memtable it is necessary to either create a second arena and point the relfilenode at it, or truncate the arena in-place. It is not possible to blindly truncate the existing arena, and you will soon understand why.

To deal with TRUNCATE, the memtable_ProcessUtility function is extended to call the finalize function for TRUNCATE in the same way as is done for CREATE. Because the finalize function ignores relations that have no cache entry, tables that use other table access methods are unaffected and the finalize function can be called blindly without checking the table access method.

static void memtable_ProcessUtility(PlannedStmt* pstmt, const char* queryString,
                                    bool readOnlyTree,
                                    ProcessUtilityContext context,
                                    ParamListInfo params,
                                    QueryEnvironment* queryEnv,
                                    DestReceiver* dest, QueryCompletion* qc) {
  Node* parsetree = pstmt->utilityStmt;

  if (prev_ProcessUtility)
 

A first look at what CloudNativePG 1.31 will bring to PostgreSQL credentials: a DatabaseRole can now generate its own password, keep it in a Secret the operator owns, shape it with criteria and rotate it on a schedule, with PostgreSQL enforcing the lifetime through VALID UNTIL. The feature is merged but not yet released, so this recipe anticipates 1.31 and shows how to try it today on the latest development snapshot.

On 12 October, the PostgreSQL User Group Vienna met, organized by * Cornelia Biacsics * Ranjeet Kumar

Speakers:

• Mayur B.
• Radim Marek

On 13 October, the San Francisco Bay Area PostgreSQL Meetup Group met online. Christophe Pettus delivered a talk. The meetup was organized by:

• Katharine Saar
• Stacey Haysler
• Christophe Pettus

On 13 October, Devrim Gündüz and Pavlo Golub staffed the PostgreSQL booth at DATA STACK CONF 2026.

On 14 October, the PostgreSQL Istanbul User Group met

Organizers:

• Devrim Gündüz,
• Gülçin Yıldırım Jelínek
• Bilge Korkmaz Erdim

Speakers:

• Melih Mutlu (Tiger Data)
• Mehmet İnce (Prodaft)

On 14 October, Claire Giordano and Aaron Wislang hosted and published a new podcast episode “From Oracle DBA to Postgres contributor with Karen Jex" from the Talking Postgres series.

On 15 October, the PostgreSQL User Group Edinburgh met, organized by Jimmy Angelakos. Elizabeth Garrett Christensen delivered a talk.

On 16 October the PostgreSQL Ghana User Group met, organized by Ezra Yendau and Julius Boakye. Ezekiel Sebastine delivered a talk.

From 20-23 October, PostgreSQL Conference Europe 2026 took place.

Organized by:

• Andreas Scherbaum
• Chris Ellis
• Dave Page
• Ilya Kosmodemiansky
• Karen Jex
• Magnus Hagander
• Marc Linster
• Martin Marques
• Samed Yildirim
• Stefan Fercot
• Valeria Kaplan

Talk Selection Committee:

• Samed Yildirim
• Floor Drees
• Gülçin Yıldırım Jelinek
• Jan Wieremjewicz
• Mayuresh Bagayatkar
• Andrei Lepikhov
• Jan Karremans
• Priyanka Chatterjee
• Stefanie Janine Stölting

Code of Conduct Committee:

• Stacey Haysler
• Ellyne Phneah
• Pavlo Golub
• Samed Yildirim

Speakers:

• Andres Freund
• Alexander Korotkov
• Alexander Kukushkin
• Alicja Kucharczyk
• Andreas Karlsson
• Andrei Lepikhov
• Ants Aasma
• Ashutosh Bapat
• Bertrand Drouvot
• Boriss Mejias
• Chris Ellis

Yesterday, I spoke about pg_acm at PGConf.EU. Speaking at the biggest Postgres conference in the world is an honor in itself, and it’s not that I have a chance to present there every year, so I am incredibly thankful to the CfP committee for choosing this talk.

This talk has a long history of rejection and denial of the fact that something could be wrong with Postgres, which made me appreciate this opportunity even more.

My presentation earlier this year at Tallinn PUG definitely helped me shape it better, and I think it went as well as it could have.

Not only do I have a dream, but I also have a request: please try pg_acm and give me feedback! From my perspective, the tool is complete, but I am sure other people will find issues. If you find them, please let me know! Please open an issue on GitHub!

https://github.com/hettie-d/pg_acm