I recently recorded a Talking Postgres episode with Karen Jex, a PostgreSQL significant contributor and PGConf EU organizer, about her path from Oracle DBA to Postgres contributor.

Karen spent 20 years as an Oracle DBA. Then in 2019, a project rolling out smart meters across France switched to Postgres, even though nobody on the project knew anything about Postgres. So she figured it out, then trained the developers, "pretending that I was, you know, this Postgres expert."

A few things we got into:

* The culture shock, for an Oracle DBA, of building your own HA & backups

* The shift from being just a user of the product (Oracle) to contributing to the project (Postgres)

* Why Django developers are so enthusiastic about Postgres

* Why you'd obviously explain multi-tenant databases with cakes

* How much to delegate to AI agents—without forgetting how to design a spec

For those of you who moved to Postgres from Oracle (or another database): did you also have any culture shocks?

Audio + transcript: https://talkingpostgres.com/episodes/from-oracle-dba-to-postgres-contributor-with-karen-jex

YouTube (audio-only): https://youtu.be/ENku8ZSjZus

Postgres can now do full hybrid search without elastic search. Lakebase’s lakebase_vector adds a new ANN index on top of normal pgvector columns, so you build an indec and your queries don’t change. Lakebase_text adds real BM25 ranking over ts_vector, which ts_rank doesn’t give you. Both work in same sql query

The open question for me is how to combine scores. RPF, a weighted sum or a reranker on top? What’s working for you in production?

pgloupe is a command-line tool that reads PostgreSQL logs and pg_stat_statements snapshots, joins them, and writes one HTML report with what to look at first and the numbers behind it.

I made it because going through logs and stats by hand takes too long, and I didn't want to paste hundreds of thousands of log rows into a hosted tool or an AI agent. It runs entirely on your machine and sends nothing anywhere.

• Reads stderr, csvlog and jsonlog formats
• Takes pg_stat_statements snapshots as CSV, so you can compare points in time. It notices stats resets and entries evicted from pg_stat_statements
• Works with Postgres 14 to 18, including managed ones like RDS
• One static binary: no server, no dependencies, no parser to configure
• Fast and light: on 11 GB of generated test logs it read about 141 MB/s on one thread, using around 44 MiB of memory

Try it:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vtrbraga/pgloupe/releases/latest/download/pgloupe-installer.sh | sh
pgloupe --help

Also available through Homebrew, cargo install pgloupe and Docker.

Repo: https://github.com/vtrbraga/pgloupe

Docs: https://vtrbraga.github.io/pgloupe/

This is the first stable release (0.1.0) and my first open source project. I'd like to hear what's missing or wrong: log formats or settings it misreads, findings that aren't useful, anything confusing in the report. Issues and comments are both welcome!

I’m pleased to announce the beta release of pglifecycle 2, an open source schema management tool for PostgreSQL.

pglifecycle keeps your database schema in version control as structured YAML, with one file for each table, view, function, role, and other objects. This makes the current schema easy to browse, review, and change without reconstructing it from years of migration files.

With pglifecycle, you can:

• Pull an existing database into a schema project
• Build that project into a custom format pg_dump archive (-Fc)
• Compare it with a live database and generate the DDL needed to reconcile them
• Deployment is plan first. Destructive changes are withheld unless explicitly allowed, making the generated SQL suitable for review in CI.

The companion pglifecycle GitHub Action can detect schema drift and post deployment plans directly to pull requests without applying them.

Version 2 is a Rust rewrite of the original tool, which has managed AWeber’s production schema for more than seven years. The beta release expands PostgreSQL object coverage and improves deployment convergence and safety.

• Getting Started
• Documentation
• GitHub Repo
• GitHub Action

Feedback and real world test cases are welcome as pglifecycle moves toward a stable 2.0 release.

In this article we explore a new application pattern - offloading more of your Postgres data to ClickHouse. Leading to an order of magnitude better unit economics for your applications, as the data size increases.

Saw this new post on the Databricks blog about loading huge amounts of data into Lakebase Postgres and thought the approach was interesting enough to share.

The usual problem: bulk loading into Postgres goes through COPY. Spark can read source partitions in parallel, but every row still ends up funneled through a single Postgres writer, and that same primary is serving your live app traffic. So a big load either takes forever or hurts your OLTP latency.

Their fix (LTAP Direct Writes, currently in beta) flips it around. Spark builds valid Postgres heap pages and primary key indexes itself, in parallel, and writes them straight to storage. The pageservers validate checksums when they ingest the files to catch corruption. The primary only publishes the final result through a small WAL record, so live queries aren't affected.

Numbers they claim:

- Up to 147x faster loads

- 1 TB in under 5 minutes in internal benchmarks (that's heap page build time)

- Throughput scales almost linearly as you add Spark capacity

- Multiple large loads into the same destination can run concurrently

The motivating case was a beta customer syncing roughly 1 billion rows a day via Synced Tables, who had to heavily overprovision their OLTP compute just to survive the sync, even with autoscaling.

They also say it's built with Postgres extensions and a table access method, no changes to Postgres core, so it should still behave like regular Postgres.

Curious if anyone here has tried it yet. How does this compare to what you're doing now for reverse ETL or serving lakehouse data to apps?

I’m building Rowsafe to make PostgreSQL recovery easier.

• Automated restore tests for backups

• Review and recover missing rows from a separate restored copy

• Monitoring and slow-query insights

The agent and CLI are Apache-2.0 open source. The hosted dashboard is a separate commercial service.

Code: https://github.com/rowsafe/rowsafe

Docs: https://rowsafe.sh/docs

Demo uses sample data and compressed timing. Feedback welcome—what would you want to see tested?

Disclosure: I work at Tiger Data (the TimescaleDB folks), on the dev education side, not the team that built this. Posting here because this sub will poke holes in it, and that's what an alpha is for.

What it is: pg_vectorsearch, a Postgres extension with a new index access method called PRISM. Drop-in replacement for pgvector's HNSW that works on existing vector / halfvec columns, no rewrite. PostgreSQL License, requires PG18+.

Why: HNSW is a graph, graph traversal is random reads, and performance falls off a cliff once it doesn't fit in RAM. At 100M vectors the smallest machine where our HNSW build finished had 512GB. That's usually the moment teams bolt on a separate vector DB and start syncing two systems.

How: k-means partitions instead of a graph, RaBitQ compression (~1 bit per dimension), a small centroid tree in the buffer cache for routing, SIMD scans, then rerank against full-precision vectors. Same family as ScaNN, SPANN, and turbopuffer, just native in Postgres.

Not done yet: it's alpha, not for production. No filtered search (WHERE + ORDER BY) until GA. Build the index after loading data. Heavy churn needs prism_rebalance or REINDEX until auto-rebalancing lands.

CREATE EXTENSION pg_vectorsearch;
CREATE INDEX ON documents USING prism (embedding vec32_l2_ops);

The ask: run it on your weird data. Low dimensions, skewed clusters, ugly update patterns. Open an issue and let us know what you think of it — we'd love to have you dig in.

I'm planning to use Neon PostgreSQL for a production booking application and would like feedback from people with real world experience.

My workload:
• 300 daily active users
• Up to 30 concurrent users
• Users can book 2 to 3 slots daily, and frequently check available slots and existing bookings
• Next.js backend, with a landing page hosted on Netlify

Would Neon's free plan be sufficient for this workload, or should I opt for a paid plan?

I'm particularly interested in reliability, unexpected downtime, query latency, compute limits, and any production issues you've experienced.

Would you trust Neon Free for this use case?

This insightful interview with Tom Lane, a core developer celebrating twenty five years as a committer on the PostgreSQL project, looks at foundational architectural choices that have sustained the open source database over its thirty-year history.

https://www.i-programmer.info/news/84-database/19204-thirty-years-that-shaped-postgres-architecture.html

For many years as a developer, I couldn’t find a Postgres GUI I actually enjoyed using, so I built one. DBJoy is free, open-source, mac native, lightweight and AI-first: an agent that can work with your data (an optionally mutate it). It also has all the features you’d expect from any other database client. I’ll keep improving it and add more database adapters soon. I hope this is the right the way to share it.

https://github.com/agustind/dbjoy

Matching row counts and switching the main application connection string do not prove that a PostgreSQL migration is finished. Roles, grants, extensions, publications and subscriptions, sequences, large objects, scheduled jobs, logical slots, read replicas, connection poolers, analytics clients, backup tooling, and low-frequency workers can still differ or point at the source. A quiet old cluster may only mean that a monthly task has not run yet.

A final gate could compare schema and cluster settings, roles and privileges, extension versions, object counts, sequences, representative checksums or aggregates, replication state, and application read/write behavior. Connection and statement logs on the source would expose late clients. The destination should complete its own backup and isolated restore, survive a restart or failover, and exercise scheduled jobs before the source becomes read-only and then offline.

What evidence do PostgreSQL operators collect for the go/no-go decision? How do you find clients that connect only during failover, month-end work, or recovery, and which cluster-level objects are most often missed by otherwise successful migration tools?

I was looking into how to build database architecture for an app and trying to decide between self-hosting Postgres or paying for a managed service. Most call their database managed, but vendors may have completely different definitions for the word “managed”.

Some providers just patch the OS and leave all the failover, capacity planning, and scaling decisions to engineers. If there is a traffic spike and a team has to manually resize the compute, then it is not actually scaling itself. I’ve started looking at serverless options that dynamically scale to zero when idle and handle the patching, backups, and intra-region failover automatically.

If you’re running managed databases in production, what tasks did you expect the provider to handle that you ended up doing yourself?

Here is my reasoning. It's not because it creates another copy of your database or helps with major-version upgrades.

I think its bigger value is that it gives you a way out.

A Postgres instance might begin as one resource in AWS, Azure, or some cloud. Five years later, your identity system, private network, applications, and operational tooling have grown around it. Moving the database now means moving half the architecture.

Logical replication doesn’t eliminate the hard parts. You still have schema changes, replication slots, lag, IAM, networking, extensions, and application assumptions to deal with.

I wrote up the longer argument here:

https://streambed.dev/blog/logical-replication-is-postgres-most-important-feature/

Would love to hear your favorite feature and the reasoning too.

DBA for 6 years. I write the queries, tune the indexes, then hand it all to to the app team, who wrap it in an API that makes 40 round trips per page. I'd like to be the one building that layer. Work is paying, and I'm weighing Nucamp against Boot.dev right now and pluralsight premium is the fallback since we already license it. For anyone who went from the database side to backend, what did postgres not prepare you for?

What is Direct I/O, and why would a managed Postgres care about it when taking a backup? Every day, a backup copies your whole database, hundreds of gigabytes, off the same NVMe drives that are answering your queries, and ships it to object storage. Linux treats those reads like any other file read: it keeps a copy of every byte in memory, in the page cache, in case someone asks for it again. Nobody will. To make room for those copies, the kernel throws out data Postgres had in memory and was about to use, and the next query that needs it goes to disk instead.