Mod hat off for a moment:

I'm one of the organizers of Postgres Conference, and the Call for Proposals for 2027 is now open.

Next year is the conference's 20th, so we want the program to reflect what the community has actually learned running Postgres in the real world.

When/where: April 21-23, 2027, San Jose Marriott, San Jose, CA

This year’s program brings back our core technical tracks: Essentials, Dev, Ops, and Extensions, now joined by a new AI track.

We’re also continuing Professional Development & Wellness and Life & Fun. These newer tracks have been so well received that they’ve become an essential part of the conference experience.

We're especially interested in talks from people running Postgres in production, such as:

- Lessons from production incidents: what broke, how you found it, and what you changed afterward
- Autovacuum and bloat tuning on large or high-churn tables
- HA and replication setups, including failovers that didn't go to plan
- Building extensions, or running them at scale
- Benchmarks with methodology you're willing to share and defend

You don't need to be a known speaker. A clear story about a real problem is exactly what we're looking for, and first-time speakers are welcome.

CFP and details: https://postgresconf.org/conferences/2027

Happy to answer any questions about submitting here. 

What's a Postgres problem you wish someone would give a talk about?

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!

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.

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.

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.

I am a full-stack developer (back-end and ops heavy), who has recently started learning about the internals of PostgreSQL.
I am currently referring a very beautiful book called PostgreSQL 14 Internals by Igor Rogov.
I am very excited to learn the theory which earlier used to be just a black box to me, things like page layouts, MVCC etc.
Is there any way I can practically use this. The thing is I learn things better if I am able to do hands on, in terms of back-end technologies it was easier just develop something even for a single user that helps you implement the theory you learned, but in terms of PostgreSQL I am not sure what options could be. would you guys help me in suggesting some ways to become hands on with all the theory I am consuming.

ISSUE RESOLVED

I can connect to my local postgresql server with pgadmin4.
Most of my databases on the server are listed.
The most recently created database on the server [teacupdb] is not listed under databases.
The database is active in PostgreSQL. I can connect to the database "teacupdb" as user "postgres" via command line.
I have refreshed the server.
I have refreshed the database list.
I have restarted my system.
I have restarted my postgresql server.
I have restarted pgadmin4.
I have deleted pgadmin4.db to force it to be recreated.

I can not find a reason why this database is not being listed on the server in pgadmin.

UPDATE
I think I found the cause. The database was created as a "template" database.

RESOLVED
Connected to "postgrest" database. Ran: UPDATE pg_database SET datistemplate='false' WHERE datname='teacupdb';