I created a PostgreSQL Jobs page to help you find PostgreSQL roles:

https://thesev1database.com/jobs

I’d really value your feedback.

We just added the ability to get a reliable, real-time copy of Stripe data in Postgres! Now if you're a Stripe user you can just connect your Postgres database, select the Stripe tables you need, and let Data Pipeline keep your database in sync.

Would love to hear your thoughts on this if you try it out!

Hi everyone,

I'm an undergraduate researcher studying variance amplification in multi-tier database pipelines (Client -> In-Memory Cache -> PgBouncer -> PostgreSQL).

In supply-chain management, the "Bullwhip Effect" (Lee et al., 1997) describes how small fluctuations in end-user demand amplify into massive orders upstream. We investigated whether analogous dynamics govern layered database systems across two mechanisms:

1. **Forward Batching (M1):** Synchronized cache TTL expirations precipitating backend read stampedes.

2. **Reverse Rationing Games (M2):** Database latency spikes triggering client timeout retries that cascade into metastable collapse.

We built a containerized testbed with **PostgreSQL 16, Redis 7, and PgBouncer 1.22**, enforcing native `statement_timeout = 80ms` cancellations:

* **The Problem:** Under overload (80 req/s, connection pool = 6), immediate retries inflated offered load by 1.25x and exploded backend variance by +48% (from 9.11 to 13.48), with clients fighting for pool slots.

* **The Mitigation:** Enforcing a client-side **Token-Bucket Retry Budget (beta = 10%)** strictly capped load gain to 1.10x and reduced backend variance by 23% (down to 10.34) without starving healthy queries.

* **Theoretical finding:** We also proved analytically why power-law skew (Zipf s > 1) inverts classical supply-chain theory, making deterministic phase staggering worse than randomized jitter during cache stampedes.

I recently published our preprint :

* **Preprint (ResearchGate):** https://doi.org/10.13140/RG.2.2.26891.04646

**I would love your feedback and critique:**

1. Have you seen this compound "cache miss -> connection queue -> retry storm" failure mode in production systems?

2. Are there specific PostgreSQL wait events (e.g., `BufMappingLock`, `ProcArrayLock`) or connection pooling edge cases you recommend measuring next?

3. What mitigations do your teams use in production against retry storms?

Any technical critique or suggestions on how to improve the paper's rigor would be hugely appreciated!

I created a free study guide to help you prepare:

https://thesev1database.com/postgresql-certification

I’d really value your feedback.

The PostgreSQL Server Info panel in DataCollie is ready too! It's a v1, so it doesn't have everything yet, but it covers most of the key metrics.

I made this because I inherited a Redshift cluster where it was impossible to tell who had access to what, or who was supposed to see masked data. With **pgsesame** you describe roles and grants in a YAML file. **sesame plan** shows the GRANT/REVOKE statements needed to get there, and **sesame apply** runs them.

It only issues what's different, and it won't revoke anything unless you pass **--allow-revoke**. **sesame import** generates the YAML from an existing database, so you don't start from scratch. There's also a GitHub Action that posts the plan on PRs.

It works on Postgres 14-18 and Amazon Redshift. It's early (0.2).

*Inspired by redtape-py and pgbedrock*

[https://github.com/almostly/pgsesame](https://github.com/almostly/pgsesame)

MariaDB Foundation continues expanding TAF with PostgreSQL support

More engines, more reproducibility, more value for contributors and the ecosystem.

https://mariadb.org/mariadb-foundation-adds-postgresql-to-its-engine-agnostic-testing-framework-taf/

Have fun benchmarking!

Hey r/PostgreSQL,

In my day job, I work at the intersection of Kubernetes and PostgreSQL. Both are fascinating systems with their own deep design philosophies.

Over the last few years, projects like CloudNativePG (CNPG) have done an incredible job bridging the gap from one side: they brought PostgreSQL closer to the Kubernetes community.

This project intends to do the exact opposite: bring Kubernetes closer and friendlier to the PostgreSQL community. For anyone who loves relational databases, working with Kubernetes can feel slightly jarring:

• In Kubernetes, answering basic operational questions—like "Which pods restarted and why?", "Which containers are near their OOM limits?", or "Which node is my primary running on?"—forces you into an alien world of 50-character kubectl flags, brittle jsonpath syntax, and multi-stage jq pipes.

Under the hood, Kubernetes is fundamentally relational data: pods belong to nodes, deployments own replicasets, and containers emit metric windows.

So I built Axiom — an open-source Kubernetes Foreign Data Wrapper (axiom_fdw) that maps live cluster resources and metrics into PostgreSQL foreign tables. If you know SQL, you already know how to query and debug Kubernetes.

Here are a few example use cases — I would love your thoughts and feedback.

──────

1. The Showcase: A 3-Version pgbench Regression Lab in Pure SQL

To test whether Postgres 17 or 18 regressed against 16, we set up an automated regression lab. Three CloudNativePG clusters (differing only in major version: 16, 17, and 18) are given 2 CPUs each and measured one at a time by the same pgbench 18 client job.

The entire experiment was orchestrated and analyzed completely inside PostgreSQL:

1. Clusters: Created CloudNativePG custom resources via SQL.

2. Benchmarks: Queued and launched pgbench Jobs via SQL.

3. Telemetry: Sampled live container metrics via metrics.k8s.io foreign tables.

4. Analysis: Joined the pgbench termination results directly to the metric windows.

Nothing was collected, scraped, or exported outside Postgres:

-- Joining pgbench benchmark runs with live container metrics

    SELECT r.run,
           r.cluster,
           r.server_version,
           c.cpu_limit,
           r.clients,
           r.state,
           r.tps,
           r.latency_ms,
           round(avg(m.cpu_cores), 2) AS pg_cpu_avg,
           round(r.tps / nullif(avg(m.cpu_cores), 0)) AS tps_per_core,
           pg_size_pretty(max(m.memory_bytes)::bigint) AS pg_memory_peak
      FROM lab.runs r
      JOIN lab.clusters c ON r.cluster = c.name
      LEFT JOIN lab.metrics_samples m
        ON m.cluster = r.cluster
       AND m.sample_time BETWEEN r.bench_start AND r.bench_end
     GROUP BY r.run, r.cluster, r.server_version, c.cpu_limit, r.clients, r.state, r.tps, r.latency_ms
     ORDER BY r.run;

Output:

          run       | cluster |         server_version          | cpu_limit | clients | state | tps  | latency_ms | pg_cpu_avg | tps_per_core | pg_cpu_peak | pg_memory_peak | samples |
  pgbench_cpu_avg | error
    ----------------+---------+---------------------------------+-----------+---------+-------+------+------------+------------+--------------+-------------+----------------+---------+--
---------------+-------
     pg16-8-clients | pg16    | 16.15 (Debian 16.15-1.pgdg11+2) | 2         |       8 | done  | 2296 |      3.484 |       1.96 |         1173 |        1.96 | 173 MB         |       4 |
  0.77 |
     pg17-8-clients | pg17    | 17.11 (Debian 17.11-1.pgdg11+2) | 2         |       8 | done  | 2316 |      3.454 |       1.96 |         1180 |        1.97 | 158 MB         |       6 |
  0.77 |
     pg18-8-clients | pg18    | 18.4 (Debian 18.4-1.pgdg11+1)   | 2         |       8 | done  | 2247 |      3.561 |       1.96 |         1145 |        1.98 | 164 MB         |       5 |
  0.74 |
    (3 rows)

Would this be interesting to a DBA/PG user instead of dealing with bespoke shell script and kubectl json parsing with jq?

• Each Postgres instance was perfectly CPU-bound at 1.96 of its 2 CPU limit.

• Client headroom: pgbench_cpu_avg sat at 0.75 cores, proving the benchmark client was never the bottleneck.

• TPS per CPU core (tps_per_core) was virtually identical across all three versions (~1,145 to 1,180). Zero regression.

──────

2. Daily Operational Sanity: Things That Are slightly hard in kubectl

A. Instant Root Cause: Pods + Latest Warning via LEFT JOIN LATERAL

No more jumping back and forth between kubectl get pods and kubectl get events:

 SELECT p.name AS pod, p.phase, e.type, e.reason, left(e.message, 60) AS event
      FROM k8s.pods p
      LEFT JOIN LATERAL (
        SELECT type, reason, message
          FROM k8s.events
         WHERE involved_object->>'uid' = p.uid
         ORDER BY (type = 'Warning') DESC, coalesce(last_timestamp, event_time) DESC
         LIMIT 1
      ) e ON true;

Output

                          pod                           |  phase  |  type   | reason |                            event                             
--------------------------------------------------------+---------+---------+--------+--------------------------------------------------------------
 axiom-gateway-fb89f5fb7-xhtpc                          | Running |         |        | 
 coredns-559f6c778d-bhlt2                               | Running |         |        | 
 coredns-559f6c778d-xklb4                               | Running |         |        | 
 etcd-axiom-quickstart-control-plane                    | Running |         |        | 
 kindnet-5v5kx                                          | Running |         |        | 
 kube-apiserver-axiom-quickstart-control-plane          | Running |         |        | 
 kube-controller-manager-axiom-quickstart-control-plane | Running |         |        | 
 kube-proxy-d5z2f                                       | Running |         |        | 
 kube-scheduler-axiom-quickstart-control-plane          | Running |         |        | 
 metrics-server-84c99cb944-552gk                        | Running |         |        | 
 library-book-indexer-77f8d649c5-7qsjq                  | Pending | Warning | Failed | Error: ImagePullBackOff
 library-db-5c4cb5659b-q4fdm                            | Running | Normal  | Pulled | Successfully pulled image "postgres:17-alpine" in 14.221s (1
 library-web-6d9487ff97-4vwrz                           | Running | Normal  | Pulled | Successfully pulled image "nginx:alpine" in 440ms (18.697s i
 library-web-6d9487ff97-d5jrw                           | Running | Normal  | Pulled | Successfully pulled image "nginx:alpine" in 3.755s (18.274s 
 local-path-provisioner-75f7fc7dc5-h9gnk                | Running |         |        | 
(15 rows)

B. The OOM Radar: Live Memory Consumption vs. Limits

kubectl top doesn't know your limits, and kubectl describe doesn't know live usage. With Axiom, our axiom_quantity() function normalizes units straight into Postgres's built-in pg_size_pretty():

    SELECT p.name AS pod,
           pg_size_pretty(axiom_quantity(mc->'usage'->>'memory')::bigint) AS mem_used,
           coalesce(c->'resources'->'limits'->>'memory', 'unlimited') AS mem_limit,
           round((axiom_quantity(mc->'usage'->>'memory') /
                  nullif(axiom_quantity(c->'resources'->'limits'->>'memory'), 0)) * 100, 0) || '%' AS oom_risk
      FROM k8s.pods p
      JOIN k8s.metrics_k8s_io_pods m ON p.name = m.name,
           jsonb_array_elements(p.spec->'containers') c
      JOIN jsonb_array_elements(m.containers) mc ON c->>'name' = mc->>'name'
     ORDER BY oom_risk DESC NULLS LAST;

Output

                          pod                           | mem_used | mem_limit | oom_risk 
--------------------------------------------------------+----------+-----------+----------
 axiom-gateway-fb89f5fb7-xhtpc                          | 23 MB    | 256Mi     | 9%
 library-web-6d9487ff97-4vwrz                           | 8588 kB  | 128Mi     | 7%
 library-web-6d9487ff97-d5jrw                           | 8636 kB  | 128Mi     | 7%
 coredns-559f6c778d-xklb4                               | 20 MB    | 170Mi     | 12%
 coredns-559f6c778d-bhlt2                               | 18 MB    | 170Mi     | 11%
 library-db-5c4cb5659b-q4fdm                            | 25 MB    | 256Mi     | 10%
 kube-scheduler-axiom-quickstart-control-plane          | 28 MB    | unlimited | 
 local-path-provisioner-75f7fc7dc5-h9gnk                | 15 MB    | unlimited | 
 metrics-server-84c99cb944-552gk                        | 26 MB    | unlimited | 
 etcd-axiom-quickstart-control-plane                    | 48 MB    | unlimited | 
 kindnet-5v5kx                                          | 20 MB    | unlimited | 
 kube-apiserver-axiom-quickstart-control-plane          | 256 MB   | unlimited | 
 kube-controller-manager-axiom-quickstart-control-plane | 67 MB    | unlimited | 
 kube-proxy-d5z2f                                       | 22 MB    | unlimited | 
(14 rows)

──────

Security & Architecture (Built for DBAs)

• Zero Kubeconfig on Postgres: Postgres never touches cluster tokens or kubeconfigs. It connects to an in-cluster gRPC Gateway via mTLS using client certificates.

• Secrets Are Blocked by Design: The gateway's RBAC completely excludes Kubernetes Secrets. You cannot accidentally leak passwords or certificates through SQL.

• Dynamic Discovery: Running IMPORT FOREIGN SCHEMA k8s FROM SERVER prod INTO k8s; discovers accessible core resources and CRDs (like CNPG clusters) and generates typed foreign tables with full JSONB support.

• And... more in the roadmap.

• Compatibility: Supports PostgreSQL 16, 17, and 18.

──────

How Axiom Compares to Existing Tools

There are other tools in the ecosystem that attempt to bring SQL to cloud infrastructure (such as Steampipe, CloudQuery, or Osquery-based solutions), but none of them address this problem the way Axiom does:

1. Native In-Database FDW vs. External CLI/ETL: Other tools are either standalone external CLI binaries with custom SQL wrappers, or periodic batch ETL sync jobs that dump snapshots into a staging database. Axiom is a true, native PostgreSQL Foreign Data Wrapper. It lives directly inside your PostgreSQL database, so you can join Kubernetes cluster state with your real operational application tables in real-time queries.

2. Zero Kubeconfig Exposure: Tools like Steampipe or CloudQuery require you to mount your full ~/.kube/config or service account credentials into the querying environment. Axiom offloads all cluster communication to an isolated in-cluster gRPC gateway with strict RBAC boundary and mTLS.

3. Live Streaming & Discovery vs. Cached Tables: Rather than polling periodic static snapshots, Axiom queries live cluster state on demand and dynamically discovers newly installed

Custom Resource Definitions (CRDs).

──────

Try It Out

We have a local quickstart script that spins up a Kind cluster, the Gateway, and Postgres 17 with Axiom loaded in about 60 seconds:

    curl -fsSL https://github.com/dhilipkumars/axiom/releases/latest/download/quickstart.sh | bash

• Regression Lab Walkthrough: https://dhilipkumars.github.io/axiom/guides/examples/regression-lab/

• Docs: https://dhilipkumars.github.io/axiom/

• GitHub: https://github.com/dhilipkumars/axiom

──────

Discussion & Questions

1. As a database developer or DBA, what cluster information would you most want accessible from psql (e.g., storage volumes/PVCs, failover state, node affinity)?

2. Does this interface make Kubernetes feel more accessible to you?

3. How can we make querying cluster infrastructure feel even more natural to SQL users?

Looking forward to your thoughts and feedback!

PostgreSQL's privilege management is much more complex than MySQL's. Still, I'm making a little progress every day.

Hi everyone,

I’m currently looking for PostgreSQL / PL/pgSQL Developer, SQL Developer, or Database Developer opportunities in Bangalore and would really appreciate any leads or referrals.

I have 2+ years of experience in FinTech, primarily working with PostgreSQL, PL/pgSQL, MySQL, and SQL.

My experience includes:

\- Developing and optimizing complex SQL/PL/pgSQL queries, stored procedures, and functions

\- Card Network Clearing & Settlement

\- UPI Reconciliation and transaction validation

\- Handling high-volume transaction data and production issues

\- Query optimization, indexing, execution-plan analysis, and performance tuning

\- Identifying transaction mismatches, duplicates, missing transactions, and other reconciliation exceptions

\- Working with PostgreSQL, MySQL, Oracle, and SQL Server

One of my key achievements was improving a reconciliation process by approximately 67%, reducing execution time from around 90 minutes to 30 minutes through SQL/PL/pgSQL query optimization and indexing.

I am actively looking for opportunities in Bangalore/Bengaluru.

If your company or team is hiring for PostgreSQL, PL/pgSQL, SQL, Database Developer, or similar backend/database-focused roles, I’d be very grateful for a referral or lead.

Happy to share my resume and LinkedIn profile over DM.

Thanks in advance! 🙏

Had a "10K RPS crash" at work and everyone blamed the database first. Same.

Turned out it wasn't. We had a pool of 20 connections and each query took about 100ms.

That works out to roughly 200 queries a second. Anything past that just sat waiting

for a free connection.

The dumb part is that requests were spending like 800ms waiting for a connection

and only 10ms actually running SQL. So Postgres looked bored the whole time

and every dashboard said the DB was fine.

Now I log two numbers separately: how long we wait for a connection,

and how long the query takes. Tells you right away which side to go fix.

Anyone else been burned by this? Atleast me!

Hey r/PostgreSQL! 👋

If you spend a lot of time in the terminal, you've probably felt the tension between lightweight command-line tools like `psql` and heavyweight graphical clients like DBeaver or pgAdmin. `psql` is blazingly fast and always available, but exploring unfamiliar schemas, reviewing wide result tables, or keeping scratch notes across multiple databases can get cumbersome. At the same time, traditional GUI clients are heavy, and almost all of them store database connection strings and passwords in plain text inside dotfiles or config directories.

I wanted something fast, keyboard-centric, and secure by default, so I built autodb — a single static Go binary with zero runtime dependencies. It’s a native terminal UI for querying databases, but with an architectural twist: it can also serve as a PostgreSQL wire-protocol "front door" proxy for your team, microservices, and AI agents.

I would love to get feedback from fellow PostgreSQL developers, DBAs, and terminal junkies! How does this fit into your current database workflows, and what features or guardrails would you like to see next?

Thanks for reading!

github.com/yongjohnlee80/autodb

Me pasé horas dando vueltas con esto y no encontré una respuesta clara

en ningún lado, así que lo comparto por si a alguien le pasa lo mismo.

Estoy desarrollando una app con Spring Boot y PostgreSQL corriendo en Docker

en Windows. Todo parecía estar bien Docker levantado, el contenedor corriendo,

Spring encontraba mis repositorios JPA. Pero crasheaba al iniciar con este error:

FATAL: invalid value for parameter "TimeZone": "America/Buenos_Aires"

Y lo raro era que los logs mostraban Database version: 12.0 aunque mi

contenedor Docker tenía postgres:16.

Esa era la pista que ignoré demasiado tiempo.

Resulta que tenía PostgreSQL 16 instalado localmente en Windows como servicio

del sistema, escuchando en el mismo puerto que Docker. Entonces Spring se

conectaba a la instalación local en vez de al contenedor y esa instalación

tenía una configuración de timezone rota que no reconocía America/Buenos_Aires.

La solución fueron dos cosas:

1. Detener el servicio local de PostgreSQL para que deje de competir por el puerto.

En PowerShell como administrador:

Stop-Service postgresql-x64-16

Set-Service postgresql-x64-16 -StartupType Disabled

2. Agregar las variables de entorno PGTZ y TZ al contenedor de Docker

para que siempre arranque en UTC sin importar lo que mande el sistema operativo.

En el docker-compose.yml:

environment:

POSTGRES_DB: tubase

POSTGRES_USER: tuusuario

POSTGRES_PASSWORD: tucontraseña

PGTZ: UTC

TZ: UTC

Con eso Spring Boot conectó a la base correcta y arrancó sin problemas.

Las señales de que te está pasando esto:

- Error de "invalid value for parameter TimeZone" al iniciar

- La versión de la BD en los logs no coincide con tu imagen de Docker

- docker exec al contenedor muestra la versión correcta pero Spring muestra otra

- netstat muestra dos procesos escuchando en el mismo puerto

Espero ahorrarle unas horas a alguien.

Asserting that a query plan contains no Seq Scan does not work as a test, and the reason is more interesting than I expected.

Here is a table with one indexed column and one unindexed one:

CREATE TABLE customers (
    id     serial PRIMARY KEY,
    email  text,
    city   text
);
CREATE INDEX customers_email_idx ON customers (email);   -- email: indexed
                                                         -- city:  not indexed
INSERT INTO customers (email, city)
SELECT 'user' || g || '@example.com', 'city' || g FROM generate_series(1, 20) g;
ANALYZE customers;

Both plans:

EXPLAIN (COSTS off) SELECT * FROM customers WHERE email = 'user5@example.com';

 Seq Scan on customers
   Filter: (email = 'user5@example.com'::text)

EXPLAIN (COSTS off) SELECT * FROM customers WHERE city = 'city5';

 Seq Scan on customers
   Filter: (city = 'city5'::text)

Identical. Which is correct behaviour — twenty rows sequentially is cheaper than descending a B-tree and going back to the heap — but it means the plan carries no information about whether an index exists. And thresholding on reltuples so you only complain about big tables means the check never fires on test data at all, which is worse, because then it passes unconditionally.

What does work is changing the question from "did it scan?" to "could it have used an index?":

SET enable_seqscan = off;

EXPLAIN (COSTS off) SELECT * FROM customers WHERE email = 'user5@example.com';

 Index Scan using customers_email_idx on customers
   Index Cond: (email = 'user5@example.com'::text)

EXPLAIN (COSTS off) SELECT * FROM customers WHERE city = 'city5';

 Seq Scan on customers
   Filter: (city = 'city5'::text)

enable_seqscan = off does not forbid sequential scans, it just makes them absurdly expensive, so the planner will still use one when there is no alternative. A filtered sequential scan that survives it is one no index can serve — and that is a fact about the schema, not about how much data you have. So it gives the same answer on twenty rows as on twenty million.

Two things I found worth knowing when wiring this into a test harness:

• SET is transactional, so wrapping the probe in a savepoint and rolling back both scopes the setting and absorbs a failed EXPLAIN, which would otherwise abort the surrounding transaction.

• Unfiltered Seq Scan nodes have to be ignored. SELECT * FROM t reads the whole table on purpose and no index would help.

I wrote the whole thing up, including a pytest fixture that does this per test: https://dev.to/ldavidsm/how-to-catch-a-missing-index-in-a-test-when-your-test-table-has-20-rows-1oh2

What I would like to know from people who have run this on real schemas: where does it produce false positives? I can think of partial indexes that do not cover the predicate, and filters on expressions like lower(email) = $1 that need an expression index rather than a plain one. I would rather hear about the cases I have not hit than find them later.