@PostgresSummit US 2026 is this week (NYC, Sept 30-Oct 2) - will we see you there? pgEdge co-founder @phillipmerrick keynotes Wednesday on what we learned shipping three open source agentic AI tools for Postgres this year, including the guardrails that matter once agents touch production databases. Thursday, he's back for our sponsor session on agentic AI across the Postgres lifecycle: the pgEdge Agentic AI Toolkit for developing AI applications on PostgreSQL, the pgEdge AI DBA Workbench for detailed monitoring and insights into your database operations, and pgEdge ColdFront, which tiers cold data to Apache Iceberg so agents can query years of history without leaving Postgres. Full schedule: 📖 lnkd.in/eKaDZjv6 #PostgreSQL #Postgres #PostgresSummit #NYC #OpenSource #DevRel #AgenticAI #DevOps #DataEngineering #NewYork #PostgresNYC

Postgres Summit US 2026 lands in New York next week, and pgEdge is going as a Platinum sponsor. Three days at Convene, from September 30 through October 2. If you're going, come by the pgEdge table in the sponsor area and say hello. We'll have people from our team who will be happy to talk to you about tiering old data out to Apache Iceberg without touching your SQL while keeping it queryable and still writable years later, putting an AI agent to work on your query plans, running the same Postgres wherever it has to live, or whatever else you've been fighting with lately - no pitch required. Not registered yet? There’s still time - schedule and registration 🎙️ hubs.la/Q04y5z7l0 #postgres #postgresql #database #dba #devops #opensource #apacheiceberg #dataengineering #aiagents #sql #nyc #postgressummit #postgresnyc

In PostgreSQL, an app that generates SUM(x ORDER BY x) has no way to touch the query, and the database sorts the column anyway, even though the sum doesn't care what order the values arrive in. Andrei Lepikhov, pgEdge's planner specialist and a PostgreSQL Significant Contributor, ran the numbers on a 10 million row sum: 5.7 seconds with the sort, 3.7 seconds without it, for a query that produces the exact same result either way. PostgreSQL 19 (currently in beta) adds the hook that makes a fix possible without touching core or the application: a new planner support request called SupportRequestSimplifyAggref. It lets an extension rewrite an aggregate at planning time and strip a sort that can't change the outcome. Core only uses the hook for one narrow case so far, turning COUNT(1) into COUNT(*). Everything past that is up to whoever writes the extension. There's still no DDL to attach a support function to a built-in aggregate like sum(). Andrei's demo does it by hand, editing the system catalog directly, because the ALTER AGGREGATE ... SUPPORT syntax that would make this official hasn't landed in core yet. 🔗 Andrei walks through the planner internals and the catalog surgery in his new post on the pgEdge blog: hubs.la/Q04xhGz_0 #PostgreSQL #Postgres #OpenSource #Database #SQL #DevOps #Programming #SoftwareEngineering #DBA #OpenSourceSoftware

You may find it hard to believe, but a little over 20 years ago, I essentially hated Postgres. My, how things change! This Phriday, follow me down Memory Lane, where I relate the trials and tribulations of a moody DBA transformed through, of course, the Power of Postgres. 😆

In PostgreSQL, the pg_replslot directory can sometimes balloon to hundreds of megabytes overnight, then empty out again by morning, with no error and nothing in the logs to explain what happened. That's Postgres logical replication doing exactly what it's built to do. The "why" is buried in a subscription option that doesn't often see the light of day. Every subscriber gets its own decoder and its own reorder buffer. A single transaction gets decoded and spilled to disk once per subscription, not once total. Three subscribers reading the same publication means three separate copies of the same spill. One open transaction produced 114 MB per slot in testing, 342 MB total, from data that exists exactly once in the WAL. The fix lives in the streaming subscription parameter. Postgres 18 flipped its default from off to parallel, which routes that load to the subscriber instead of piling it onto the publisher. Running 17 or earlier? One ALTER SUBSCRIPTION and no restart needed does the trick. Even on 18, wide TOAST data can still force a spill. Streaming shrinks the exposure... but it doesn't erase it. @BonesMoses walks through the whole investigation, spill files and all, in this week's PG Phriday: 📖 hubs.la/Q04xfYyg0 #PostgreSQL #Postgres #OpenSource #Database #DBA #DevOps #LogicalReplication #SQL #PGPhriday #DataEngineering #Programming #Developer

The second speaker slot at this month's PostgreSQL Edinburgh meetup (#PostgresEDI) is still open. If you've been thinking about giving your first Postgres talk, this is a friendly room to start in. Thursday 24 September, 6pm 📍 Paterson's Land, Edinburgh. Free to attend, with pizza and drinks from the door 🍕 and everyone heads over to The Canons' Gait afterwards to keep talking. Jimmy Angelakos will be talking during the 7pm slot about "ColdFront: Transparent PostgreSQL Data Tiering to Apache Iceberg" 🐘 pgEdge ColdFront is an extension (open source under the PostgreSQL License) that lets a Postgres table span hot heap storage and cheap object storage under one table name, with the cold data still writable through normal SQL. Jimmy is the lead developer, so bring all your questions to the table. The 8pm slot is yours if you want it. Email Jimmy and tell him what you'd like to talk about: vyruss000@gmail.com 🎙️ RSVP here: 📖 hubs.la/Q04xbRxV0 If you're a PostgreSQL user in Scotland, be sure to bookmark this page: 🔗 hubs.la/Q04xbRJD0 Jimmy runs it on a volunteer basis; it's where Postgres events across Scotland get listed. Contact info@postgres.scot if you have a PostgreSQL event to add to the page. #postgresql #postgres #edinburgh #scotland #meetup #opensource #database #dba #datatiering #apacheiceberg #callforspeakers #devcommunity #techcommunity

pgEdge's AI DBA Workbench ships with AI-driven diagnostics as the whole point of the tool. But some environments can't call an external AI service at all - compliance rules that block outside connections, or deployments that have to be air-gapped entirely. So we ran the whole thing locally instead. `llama.cpp` serving a model, wired into the same Docker Compose stack as the workbench itself: Postgres, a collector, the workbench server, an alerter, the client, a load generator, and the `llama.cpp` container - seven services total, all open source. We pointed it at a Qwen3.8 model on a single consumer GPU and let it watch a live wholesale workload. It flagged a lower cache hit ratio from frequent forced checkpoints, and caught random_page_cost set too high based on sequential scans against tables with low row counts. Real findings from a real cluster, not a hypothetical. If your hardware allows, swap in something bigger: GLM-5.2, Kimi K3, DeepSeek-V4-Flash. No frontier-model bill, no external service to lose access to, and it keeps working the moment the network doesn't. 📚 The full PG Phriday walkthrough from Shaun Thomas, containers and all: hubs.la/Q04wMP470 #PostgreSQL #Postgres #AI #LLM #OpenSource #DevOps #Docker #DBA #DataEngineering #Programming #FOSS #OSS

PostgreSQL's own docs call numeric "especially recommended" for storing money, then in the same breath call it "very slow" compared to integer types. That contradiction is why plenty of developers just store cents as bigint and move on. So we checked what's actually required: the SQL standard, EU currency regulation, ISO 20022, FIX (the exchange trading protocol), and the TPC-C and TPC-H benchmarks. The answer isn't "always use numeric." Integer works fine when the scale is fixed from outside, like a currency code. It breaks down once the scale varies by domain and gets reconfigured in a live system, which is exactly what happens inside ERPs like SAP and 1C. There's also a requirement almost nobody talks about: serialization. A monetary value has to survive a boundary where a parser you don't control picks it apart. Only one construction guarantees that across languages: an exact integer with the scale defined outside the value. One more finding: PostgreSQL's numeric supports up to 131,072 digits of precision. Nearly everyone else building a fast decimal type - Snowflake, Redshift, SQL Server, DuckDB - caps out around 38. 👉 Andrei Lepikhov's full breakdown: hubs.la/Q04wF20k0 #PostgreSQL #Postgres #Database #SQL #OpenSource #DataEngineering #SoftwareEngineering #FinTech #DBA #DevOps

In 2002, Shaun Thomas defended Oracle on a public mailing list, complained about how much VACUUM sucked, and pushed to rip Postgres out of his company's stack for MySQL. There was a celebratory lunch and everything. Twenty years later he's an avid PostgreSQL advocate and engineer. This week's PG Phriday is what happened in between. A few things from it: the reindexdb utility he contributed to Postgres 7.3 started as a hacked-up copy of vacuumdb, run from cron every two hours, because a VACUUM bug back then left indexes growing forever. On his first day at a Postgres shop in 2005 he found max_fsm_pages at its default of 200,000, producing a sliding window of infinite bloat, days from filling every drive tray the server had. In 2010 he inherited a 1TB database doing 15k TPS through trading hours that crashed constantly, and nobody knew why. What connects all of it is that none of the tooling existed yet. No pg_upgrade, no Patroni, no pgBackRest. So he built replacements out of duct tape and bailing wire, then wrote up what he'd learned for the dev teams who had to live with it. That's how PG Phridays first started in 2015. Ever inherited a database that genuinely scared you? This one will read familiar. You can find it on our blog ✨ hubs.la/Q04vL99c0 #PostgreSQL #Postgres #DBA #Databases #OpenSource #DatabaseAdministration #HighAvailability #DevOps #SRE #DataEngineering #pgEdge #Programming #Coding #PGPhriday

Prototype to production is where compliance catches up with you. You've built your healthcare app on Postgres. It works. Then someone asks: is your database layer HIPAA-ready? That question used to mean choosing purpose-built healthcare databases or accepting the limits of managed services. pgEdge - enterprise Postgres, no forks - is now HIPAA-ready. Coverage includes pgEdge Cloud BYOC and the self-hosted pgEdge Enterprise Platform, building on existing SOC 2 Type II compliance. Relevant for teams building healthcare SaaS, patient-facing platforms, and AI workloads that handle PHI. One thing Mahsa Dornajafi makes clear: HIPAA-ready infrastructure doesn't make your application compliant. Architecture, access controls, data handling, and organizational processes all matter. The database layer is one piece of a shared responsibility model - and knowing where that boundary is matters before you're in a compliance conversation, not after. Read the post: 📖 hubs.la/Q04vCv8h0 #postgres #postgresql #hipaa #healthcare #healthtech #dataengineering #database #dba #compliance #opensource #pgedge #cybersecurity #devops

Set work_mem too low and Postgres writes sort and hash operations to disk instead of keeping them in memory - which can slow a query by an order of magnitude. Set it too high and you're one busy Friday away from an OOM crash, because work_mem applies per operation, not per query. One connection can multiply that allocation several times over. "The recipe I usually use is to use the database statistics. I find out the average size of the temp files Postgres is producing and then I add that to whatever the work_mem setting is. If it starts out at the default 4 megs and Postgres is producing on average 8 megabyte temporary files, I'll add some padding... that reduces all your disk spills by 90 plus percent." That's Shaun Thomas - pgEdge engineer and longtime Postgres blogger - on the latest Postgres FM with Nik Samokhvalov and Michael Christofides. work_mem is one of those settings that is consistently miscalibrated. The classic formula (total RAM / 4 / max_connections) breaks down fast on RDS, where max_connections defaults to 5,000 even on small instances. Shaun's approach: pull actual temp file sizes from pg_stat_database, add padding, move on. The episode also covers hash_mem_multiplier, why extension security is harder to ignore after Postgres 18.6's 28-CVE release, and when to set work_mem per role instead of globally. 🎙️ hubs.la/Q04vqfZn0 #PostgreSQL #postgres #database #dba #cloudDatabase #pgEdge #openSource #backend #engineering #infrastructure #distributed #postgresfm #devops #dataengineering #programming #techpodcast #tech

UUID v4 has been quietly wrecking B-tree indexes for decades - most shops just chalk it up to Postgres being Postgres. What's actually happening: Every v4 insert lands at a random leaf page. Almost never the one just touched, so Postgres pulls it from cache - or worse, disk. Page splits happen in random spots. Pages end up half-empty. One million rows: 38 MB, 49.9% leaf fragmentation, 71.5% leaf density. UUID v7 (RFC 9562) fixes this. High-order 48 bits: Unix timestamp, MSB first. New keys always land at the right edge of the B-tree - same locality as a plain BIGINT sequence. One million rows: 30 MB, zero fragmentation, 90% leaf density. Postgres 18 ships uuidv7() natively. Bonus: uuid_extract_timestamp() pulls creation time straight out of any v7 key. The primary key doubles as created_at at no extra cost. It should be noted the timestamp leaks to anyone observing the values, adjacent keys share nearly identical prefixes (insertion rate becomes measurable from outside), and in heavy write topologies the rightmost page becomes a contention point. The post also covers pgEdge's snowflake extension - a BIGINT-based alternative with different index tradeoffs. Read Shaun Thomas's breakdown: 📖 hubs.la/Q04tV_Vx0 #postgres #postgresql #postgresql18 #database #dba #distributedsystems #opensource #pgedge #pgphridays #unix #programming

Jimmy Angelakos just shipped pg_statviz 1.2, and the PostgreSQL 19 support is the headline - but the blocking locks module is the one to dig into first. pg_statviz is a lightweight extension + utility pair for time series analysis and visualization of PostgreSQL internal statistics. No agents, no external connections, zero external dependencies by default. Version 1.2 picks up: - PostgreSQL 19 support (tested against beta3, covering PG 13-19) - A new blocking locks analysis module - records blocked/blocking sessions by lock type using pg_blocking_pids(), soft blocks included - OpenAI provider support alongside the existing Anthropic and Google options, all opt-in The AI analysis stays exactly that - fully optional, no external calls unless explicitly requested. Read more on Jimmy's blog: 📖 hubs.la/Q04tTssv0 #PostgreSQL #Postgres #OpenSource #DatabaseEngineering #SQL #pgEdge #pgstatviz #DataVisualization #extension #pg_statviz #database #stats #statistics #visualization

A 2025 PVLDB paper claims shared hash tables can beat partitioned GROUP BY aggregation. Andrei Lepikhov built the prototype in PostgreSQL and measured whether that holds. It does - under specific conditions. Up to 4.82x speedup with uniform data, 80-20 distribution is about the edge of positive territory, and 95% heavy-hitter concentration lands at 0.04x. The deeper finding: PostgreSQL's process model pays fundamentally more for shared mutable state than a thread-based engine does. The paper was testing a different architecture. There's also a candid note about AI agents helping build the prototype fast enough to run real benchmarks on GCP. Read it on the pgEdge blog: 📖 hubs.la/Q04tNlmg0 #PostgreSQL #Postgres #DatabaseEngineering #SQL #OpenSource #ParallelQuery #DataEngineering #PerformanceTuning #pgEdge #DatabasePerformance

Jimmy Angelakos built ColdFront because he couldn't find an open platform that did tiered Postgres-to-lakehouse storage at the complexity level he was willing to run. The design is deliberately minimal: hot rows stay in ordinary Postgres tables, older rows move to Apache Iceberg on object storage, one view across both - and the cold tier is writable. There's also a Decoupled mode where a table lives entirely in Iceberg and Postgres nodes become stateless compute. Stock PostgreSQL, with open formats and pen catalog. Tomorrow Jimmy walks through the engineering decisions behind it - including using TLA+ to formally verify the distributed write protocol - and Paul Rothrock runs a live demo: setup, dual-mode tables, Iceberg-only tables, and querying and writing across tiers. If you're paying SSD prices for data nobody's touched in months, this is a good use of an hour. Register here 👇 us02web.zoom.us/webinar/regi… 🔗 github.com/pgEdge/ColdFront #PostgreSQL #Postgres #ApacheIceberg #DataEngineering #OpenSource #DatabaseEngineering #SQL #DataArchitecture #CloudStorage #pgEdge #ColdFront #DataTiering

work_mem isn't a per-query limit. It's per operation - and that distinction matters more than most DBAs realize. Postgres allocates work_mem independently to every memory-hungry plan node: sorts, hash joins, hash aggregations. A query with four of those nodes has a worst-case ceiling of 4× work_mem before any node spills to disk. hash_mem_multiplier compounds it. At the default of 2.0, hash nodes count double. A plan with two hash joins and a sort isn't 3× work_mem. It's 5×. That's 320MB from a 64MB setting, on a query that looks routine in EXPLAIN. @BonesMoses built an extension to walk the full plan tree and compute this before execution. Almost none of what he needed lives in the Postgres manual - it's in the source. So he wrote about it this PG Phriday: hubs.la/Q04t6ZZ30 #PostgreSQL #DatabaseEngineering #Postgres #DBA

Most tiering solutions ask you to choose: keep data in Postgres and pay SSD prices, or move it somewhere cheaper and give up writability, transparency, or your existing SQL. ColdFront doesn't make that trade. Jimmy Angelakos, our Staff Software Engineer who built ColdFront, will explain why on Wednesday, August 19 at 8 AM Pacific. He designed it around one constraint: as few moving parts as possible, each doing what it does best. Postgres stays the system of record. pg_duckdb handles Iceberg I/O in-process. Lakekeeper is the catalog. ColdFront is the orchestration between them - the part that makes it all invisible at the query layer. He'll also cover the distributed correctness problem most tiering discussions skip: how do you serialize Iceberg commits across multiple nodes without application-level retries? Jimmy used TLA+ to formally verify the safety properties of ColdFront's write protocol rather than reason about it by inspection alone. Paul Rothrock follows with a live demo covering setup, dual-mode tables, Iceberg-only tables, and reads, writes, and deletes against cold data - including a GDPR deletion case that most archival systems require a full restore cycle to handle. Live Q&A at the end. Try it now: hubs.la/Q04t6GCF0 Register: hubs.la/Q04t6HS40 #PostgreSQL #ApacheIceberg #OpenSource #DatabaseEngineering #PostgresExtensions #Hacking #Programming #DataEngineer #DBA #Tech #Technology #GitHub #Dev #DevCommunity #DatabaseCommunity

The RETURNING clause on ON CONFLICT DO NOTHING has always been lying to you. Ask it to get-or-create a row and return whatever's there? Zero rows. Technically correct. Completely useless. The workaround is equally bad: `DO UPDATE SET col = excluded.col` just to trick RETURNING into having something to return. That's a pointless write, table bloat, and a burned tuple every single time. Postgres 19 fixes this with ON CONFLICT DO SELECT. Conflict? Returns the existing row. No conflict? Returns the new one. One statement, two possible outcomes, exactly one returned row. That's just one of three syntax changes covered in this post. GROUP BY ALL infers every non-aggregate column automatically, so you stop hand-listing columns in GROUP BY that already appear in SELECT. And native COPY ... FORMAT JSON means you can export proper JSON documents directly from Postgres without any application code. None of these will headline the Postgres 19 release notes. But they're the kind of fix you start using once and can't go back from. Read the full piece from @BonesMoses 📖 hubs.la/Q04sjwl00 #postgres #postgresql #postgres19 #sql #database #dba #dataengineering #softwareengineering #developers #opensource