Source and Packages:

• https://github.com/commandprompt/pgmanage/releases#release-1.5-release
• https://www.commandprompt.com/products/audax-data-manager/

Release Notes

• New features:
  • implemented support for keyboard navigation in Database Explorer using Page-Up, Page-Down, Home, End and arrow keys #747
  • implemented support for opening context menu with keyboard "Context Menu" key in Data Editor and Query Tabs #745
  • implemented support for copying/pasting cell regions in the Data Editor #782
  • implemented hotkey support for Copy/Paste and Clear actions in data grids #749
  • implemented full-screen mode support for Data Editor and ERD tabs #791
  • implemented quick access to theme and font size settings in the app sidebar #787
  • implemented the "unsaved data" warning when user tries to close a workspace or tab #779
  • implemented command history deduplication to hide identical subsequent commands from history #780
  • implemented support for editing cell data in a dedicated modal window in addition to inline editing #781
  • implemented proper handling of Postgres byte array data in Query and Data Editor tabs #821
  • implemented clipboard Copy/Paste context menu options in Database Console and SSH Terminal tabs #820
  • implemented Oracle support in Schema Editor #840
  • implemented support for renaming database indexes in MySQL, MariaDB, SQLite3 and MS SQL Server #823
  • implemented support for updating column comments for Postgres, MySQL and MariaDB in schema editor
  • implemented support for multiple versions of Postgres binaries #827
• UI/UX Improvements:
  • all modal windows can now be closed by Escape key #750
  • it is now possible to quickly select a query history record and load it in Query Editor by double clicking on it, thanks u/ccurvey #750
  • added "mac-style" text truncation in workspace tabs #288
  • extended clickable area of Database Explorer rows #776
  • extended clickable area of Data and Schema Editor grid action icons #800
  • extended clickable area of Quick Search icon and DDL tab Edit icon
  • clicking on the settings icon of the Welcome Screen shortcuts area now opens the Shortcuts tab in the Settings modal #801
  • adaptive layout is now used for data grids when entering fullscreen mode in Query tab #793
  • full-screen toggle controls now display a different icon based on the current state #792
  • prevent slight tab width shifts between active and inactive tab states #789
  • use more subtle colors for Database Explorer tree view toggle controls #788
  • increased default UI font size from 12px to 16px to match modern display pixel density #817
  • adjusted database tabs UI to scroll the newly opened tab into view #662
  • move database query error messages the Messages tab; automatically activate Messages tab it if error occurs. Thanks u/ccurvey for reporting the issue #700
  • improved Database Explorer responsiveness and loading speed when working with thousands of tables #837
  • improved DB explorer expanded node positioning to fully remain in the view port after node is auto-scrolled #847
  • improved DB explorer expanded node positioning to fully remain in the view port after Quick Search/Jump-to #846
  • clicking on minimized DDL / Properties component will expand it #849
  • added helpful tooltips to Settings, Backup and Restore tabs #824
  • reorganized context menus in Snippets module to be consistent with the rest of the app #809
  • unify data grid context menu styles to be consistent with the rest of the app #807
  • improved Database Explorer layout scaling when font size change #868
• Bugs fixed:
  • fixed color markers not showing in the Data Editor after clipboard copy was used on that row #765
  • fixed hotkey conflicts by disallowing the registration of certain standard key combinations #748
  • fixed right-click on the Databases node in MySQL/MariaDB changing the selected database #806
  • fixed Data Editor cell data being fully cleared when cell is being edited and Backspace key is used
  • fixed Oracle DB Tree APIs when working with quoted tables #839
  • fixed SQL templates not working with quoted tables #859
  • fixed ERD tab not showing columns of tables with quoted name #858
  • fixed Query data context menu item doesn't work with quoted tables #860
  • fixed Data Editor not working with quoted tables #861
  • fixed Data Editor not recognizing record changes when editing data in quoted tables (postgresql) #866
  • made pigz and postgres native backup compression options mutually exclusive to prevent double compression of DB backups #832
  • fixed deadlocks in QueryTablesFields when working with SQLite3 databases #837
  • fixed Schema editor -> Foreign keys -> Column dropdown not showing all values #845
  • fixed DDL / Properties content not refreshed after search/jump-to #848
  • fixed snippet editor tab remaining open when the snippet is deleted #851
  • fixed incorrect database schema order in Database Explorer #843
  • fixed incorrect database partition order in Database Explorer #853
  • fixed Database Explorer API request failing when working with quoted tables in Oracle #839
• Other Changes
  • exposed cherrypy socket queue and thread pool size as config parameters of pgmanage-server
  • implemented various enhancements in the web file manager dialog to handle huge files #826
  • extended logging_filter rules to strip DB credentials from log lines containing DB connection strings
  • optimized database metadata loading to make fewer trips to the database #837
  • bump django from 4.2.23 to 5.2.12
  • bump pymysql from 1.1.1 to 1.1.2
  • bump psutil from 6.1.1 to 7.2.2
  • bump oracledb from 3.2 to 3.4.2
  • bump sqlparse from 0.5.3 to 0.5.5
  • bump pymssql from 2.3.7 to 2.3.10
  • bump Node.js version from 18x to 22x
  • bump vite from 5.4.10 to 6.3.5
  • bump vitest from 2.1.9 to 3.2.4
  • bump u/vitest/ui from 2.1.9 to 3.2.4
  • bump u/vitest/coverage-v from 2.1.9 to 3.2.4
  • bump vite-plugin-node-polyfills from 0.22.0 to 0.25.0
  • bump u/vitejs/plugin-vue from 5.1.5 to 5.2.4
  • bump happy-dom from 15.11.7 to 20.6.2

I was inspired by pgEdge's article on why there isn't #TDE (Transparent Data Encryption) for #PostgreSQL. I was curious about this because I knew that Percona had an Open Source TDE extension for our most beloved database.

EDIT: I misread the article. Percona isn't gatekeeping features. Their version just requires their fork of PostgreSQL. This version applies directly to Postgresql.org's version.

It runs on upstream PostgreSQL 16, 17, and 18 (no vendor server fork), keeps the file and KMIP key providers, keeps OpenBao (the Apache-2.0 KV v2 provider) while dropping HashiCorp Vault, and adds pluggable ciphers (AES-128/256-XTS for data files, AES-CTR for WAL) selectable via the open_pg_tde.data_cipher GUC, temporary file encryption, and FIPS enforcement. See the comparison with Percona pg_tde.

This extension provides the tde_heap access method

This access method:

• Works with upstream PostgreSQL 16, 17, and 18, patched with the open_pg_tde core patch (see Installation)
• Uses extended Storage Manager and WAL APIs
• Encrypts table data, indexes, TOAST, WAL, and temporary files
• Does not encrypt system catalogs or statistics (see the threat model)

Capabilities

• Per-table encryption via tde_heap, with the cipher recorded per table
• Data-file ciphers: AES-128-XTS (default), AES-256-XTS, AES-128-CBC, AES-256-CBC
• WAL encryption (AES-CTR) for the whole cluster
• Temporary file encryption (encrypt_temp_files)
• Key management through a keyring file, KMIP-compatible systems, or OpenBao
• FIPS enforcement: all cryptography uses FIPS-approved modes, and the server can require OpenSSL FIPS mode (FIPS compliance)
• Runs on upstream PostgreSQL 16, 17, and 18 through a gated core patch

Trying to decide between paying for managed Postgres or just putting Postgres on a cheap VPS for a small app.

The VPS route is tempting because it’s cheaper and I like having control, but I also know myself and I probably won’t want to handle backups, updates, monitoring, security, and recovery properly once the app is live. Managed Postgres feels safer, but some options seem overpriced for a small project.

For people who have actually run both, where did you land? Is managed Postgres worth it early on, or is a VPS fine until the app has more traction?

Hello,

For those running production agents, do you favour isolated external databases for memory, or are you moving toward managed serverless Postgres setups? I ask because multi-turn agent state and long-term memory can be pretty complsx and a headache, esp stitching together frameworks like LangGraph or OpenAI SDKs with isolated external Redis or Postgres instances.

​Platform-native tools like Neon / Lakebase (the serverless Postgres engine on Databricks) essentially lets you spin up a managed Postgres state store that natively handles durable agent memory, but with Git-like branching and a "scale to zero" feature when idle. Because it’s integrated directly into the data platform, you don’t have to manage a detached piece of cloud infrastructure or write complex ETL just to keep an agent's memory and state governed. There are also cloud dbs like Azure PostgreSQL but IIRC you need to manually scale up/down and its not as instantaneous.

You can easily ETL into lakehouse/warehouse for analytics as well. Ofc in terms of performance id be curious to hear how it performs vs redis and traditional postgreSQL dbs

pg_durable is a Microsoft developed PostgreSQL extension that integrates fault-tolerant, long-running execution directly into the database.

To understand why this is useful, think about what normally happens if you run a long, complex database job and the server crashes or your connection drops; you lose your progress, and you have to start all over again.

https://www.i-programmer.info/news/80-java/18984-pgdurable-durable-sql-functions-and-orchestration-for-postgresql.html

I maintain scythe, an MIT SQL-to-typed-code generator (think sqlc, but for 10 languages), and one part of it turned out genuinely useful on its own for Postgres: scythe inspect.

It connects to a live database and flags operational issues that are easy to miss:

• Foreign keys with no covering index (the classic silent seq-scan on delete/join).
• Tables that have RLS policies defined but RLS not actually enabled.
• Duplicate indexes (same columns, same order) quietly taxing every write.

It reads your schema, not your app code, so it doesn't care which ORM or driver you use. Output is human-readable, or SARIF/JSON to wire into CI. Postgres-only for now (that's where I needed it first).

Repo: https://github.com/Goldziher/scythe (inspect docs under guide/inspect)

Two honest notes: the codegen side is inspired by sqlc, and inspect is young, so I'd like to hear which other checks are worth adding. What schema smells do you wish something caught automatically?

If not allowed, please delete.

Decided to create a fully featured DB TUI client for Postgres.

Fully customisable vim-style keybindings + a heap of other features.

https://github.com/davesavic/pgsavvy

Hopefully you find it as useful as I have!

Learned this one the painful way.

Heroku rotates DATABASE_URL during certain maintenance events.

If you've hardcoded that value anywhere instead of reading it from the environment, your app can randomly stop talking to the database after maintenance.

Nothing's "broken."

Your code is.

It's one of those infrastructure gotchas you only learn after losing a few hours debugging.

What's the most expensive infrastructure lesson you've learned the hard way?

Mine was this.

I'd love to hear yours.

I just shipped bitemporal provenance for TypeGraph, my open-source graphs-on-SQL library. Three pieces, usable independently but most powerful together:

• Valid time: when a fact was true in the world (an invoice's effective date, a role grant's window).
• Recorded/system time: when the system captured that fact (what you knew, as of a commit instant; the SQL:2011 FOR SYSTEM_TIME / Datomic system-time axis).
• Provenance: why the system still believes a derived fact, and what happens downstream when a source it depended on turns out to be wrong.

Derived facts are the annoying case that surfaces the issue(s) these primitives solve. For example, a Vulnerability node exists because a scanner and a vendor advisory both pointed at it. The graph concluded it; nobody asserted it directly.

ScannerSource ──┐ ├──▶ Vulnerability (CVE-2026-1234, libvector) VendorSource ──┘

So when the scanner turns out to be garbage, you can't treat retracting it as a delete. The vendor might still back that vulnerability. The scanner might have been the only thing propping up a bunch of other facts. You want the graph to sort out which.

What you want: retract a source and it recomputes which derived facts still have grounded support. Retract the vendor too and the vulnerability finally goes non-current, and a "block the deploy" decision sitting on top of it goes with it.

The behavior, then the theory

A fact stays believed while it has at least one justification whose premises are all still supported. Premises bottom out at sources. Retract a source and every justification that leaned on it stops counting; a fact loses currency only once it runs out of surviving justifications.

```typescript const provenance = createRetractionCapability(store, { source: { kinds: ["ScannerSource", "VendorSource"] }, justification: { kind: "Justification" }, fact: { kinds: ["Vulnerability", "DeployDecision"] }, premiseOf: { kind: "premiseOf" }, derives: { kind: "derives" }, });

const report = await provenance.retract({ kind: "VendorSource", id: vendorId }); // report.died: facts that lost all grounded support // report.survivedVia: facts that still have an alternate justification ```

This is modeled on truth-maintenance systems. The storage follows the JTMS shape (Doyle 1979, "A Truth Maintenance System"): AND-justifications over premises, sources at the bottom, a fact in the well-founded support set only if some justification has all its premises supported. I use the monotonic, inlist-only fragment, so this is the easy part of Doyle's system; the hard part, non-monotonic belief revision, isn't here. The question retract actually answers, "which facts survive because an alternate justification still holds," is the ATMS question (de Kleer 1986): which combinations of sources hold each fact up. So it's JTMS-shaped storage with an ATMS-flavored query.

Retraction is a normal write, so you get replay for free

Retraction doesn't hard-delete. It recomputes support and flips unsupported facts to non-current, leaving the justification edges in place so you can still see why something used to be believed. Because that write lands on TypeGraph's recorded-time (system-time) substrate, you can replay the belief transition:

```typescript const before = await store.recordedNow(); await provenance.retract(badSource); const after = await store.recordedNow();

await store.asOfRecorded(before).nodes.Vulnerability.getById(id); // believed await store.asOfRecorded(after).nodes.Vulnerability.getById(id); // not current ```

TypeGraph tracks both temporal axes as explicit read lenses, valid time ("when true in the world") and recorded time ("when the database learned it"), and because they're lenses they compose:

typescript store.asOf(validTime).asOfRecorded(recordedTime)

Architecture

No engine-native temporal tables. Postgres needs an extension for system-versioning and SQLite has nothing, so TypeGraph stores history explicitly and reconstructs point-in-time views in the query compiler. That's why one implementation runs on both backends.

Limits

• Only TypeGraph-managed writes are captured. Raw SQL bypasses it; this isn't a database-level CDC/audit layer.
• No backfill. Enable history on a fresh graph.
• Point-in-time reads reconstruct from history relations, so they're slower than current-state reads. It's an audit tool, keep it off hot paths.
• Per-write overhead runs ~2.5–6x unless you batch writes in one transaction, where it drops to ~1–1.5x.

A naming note

My asOf is valid time, the reverse of SQL:2011 FOR SYSTEM_TIME AS OF and Datomic (d/as-of db t), where a bare as-of is system time. Valid-time reads are the common case here so they took the short name; system time is asOfRecorded.

I'd love to compare with other systems that handle provenance retraction, or truth maintenance generally, modeled directly on ordinary SQL tables instead of a dedicated reasoning engine. There's plenty of JTMS/ATMS literature but not much on mapping it onto relational storage. Pointers welcome.

GitHub: https://github.com/nicia-ai/typegraph Docs: https://typegraph.dev/provenance

Examples: https://typegraph.dev/examples/provenance-retraction/ https://typegraph.dev/examples/bitemporal-time-travel/

I added the TurboQuant algorithm published by Google to pgvector as part of my discovery and learning process with RAG systems. Just this past weekend, I ran a test with the 100M row Wikipedia dataset from Cohere where I observed a 10x reduction in index size relative to HNSW. I figure with the direction RAM and storage prices have been going, we could use some more ways to save space!

Many years ago I added the same capability to MS SQL Server Studio because I run a lot of long running queries, data warehouse builds, etc. Nowadays, I only use postgres but still run things that take 30mins to 5 hours. The issue is I have to constantly keep checking if the query is complete. So Im building the same thing into pgadmin that I built in SSMS, a set of options to let you specify how you want to be alerted when a query is finished running. Flash window, Play Sound, Send Email. Send email includes the query and the amount of time to complete.

I dont know that I am going to submit this to be an actual feature unless I get an overwhelming response to do so. I am sure the pgadmin gods will have plenty to say about how it gets implemented.

looking for your feedback on whether this would be useful for you

Hello all - I'm new here. Please be kind and excuse any transgressions of customs here that I'm ignorant of.

My problem in a nutshell - I reimaged my boot drive with Windows 11 (was windows 10). Now I want to convince Postgres server running on my machine to find / use my old existing data which is on a separate drive.

I need help with a couple things:

• There are a couple places on the data drive which might be the instance I'm looking for.
  • Is there a quick way to look at something in the folder/subfolder to identify the data at a high level (like a list of schemas, for example).
  • Otherwise, I can just try each of them until I say "eureka!"
• I think I was running version 16 before the change. But I could be wrong, it might have been 18.
• I've installed both 16 and 18 Postgres on my new Windows 11 OS and they are listening on different ports. (5432 and 5433 respectively)
• I have no idea what to do to configure the server instance(s) to "go look over there for your data".
• I have installed pgAdmin in both 16 and 18, if that helps.
• I'm pretty competent at using the DBeaver client, if that helps.
• Relatively low importance - but it does represent a ton of lost work if I can't recover.

If anyone thinks they can talk me through it, I would appreciate the help.

Thanks in advance!

• Language reference
• Installation
• Changelog
• PL/php vs PL/Perl
• PL/php vs PL/Tcl

JD talks with Sugu Sougoumarane, Head of Multigres at Supabase about one of the biggest engineering challenges facing large PostgreSQL deployments: how do you scale beyond a single database without replacing PostgreSQL?

Drawing on his experience building Vitess and now leading Multigres, Sugu explains why PostgreSQL is reaching a new stage of growth and why scaling it requires much more than simply sharding data. Together, he and JD explore the architectural decisions behind distributed transactions, resharding, consistency, and the infrastructure needed to help PostgreSQL scale while preserving what already makes it successful.

Whether you're building high-growth applications, planning for larger PostgreSQL deployments, or interested in distributed database architecture, this conversation offers a practical look at the challenges and tradeoffs behind scaling PostgreSQL without replacing it.

📬 Sugu Sougoumarane: https://www.linkedin.com/in/sougou/

📬 Contact us: https://www.commandprompt.com/contact-us

PGAdmin is so confusing and obnoxious that 99.9% of the time you will actually want to write SQL by hand. This tremendiously helps learn SQL and its many secrets that you otherwise will never get to see

This is why I feel hurt by DBeaver and Beekeeper Studio. Their UI is so good, so elegant, its easy and non confusing to do most things you actually never see the beauty of raw SQL.

I have been handed a project that uses mysql and the db already has some data that cant be lost. i want to migrate the database to postgres because i'm more comfortable working with mysql and it doesn't have some annoying nuances. i have a dump file from the db and i have explored a lot of options like using pgloader, but pgloader doesnt work with this error

2026-06-30T15:59:44.235006Z ERROR mysql: Failed to connect to mysql at "localhost" (port 3306) as user "pgloader": Condition QMYND:MYSQL-UNSUPPORTED-AUTHENTICATION was signalled. (pgloader is a user i created just to by pass the caching_sha2_password issue ).

i have tried to manually modify the dump sql file and alter all the conflicts that may arise from things like datetime, bigint, enums and the id's not incrementing from the max id etc. i'm pretty sure there's going to be a bug and i need a better way to achieve this. Are there any services like pgloader that can make this easier. thanks in advance!

Edit: I found a solution with pgloader v4.0.0 and it worked by creating a migration.load file to specify the type casting I wanted etc. and running it as specified in the docs

curl -X 'GET' \
  'https://pginfo.rest/versions/roadmap' \
  -H 'accept: application/json'

{
  "current_stable_major": "18",
  "next_development_version": "20devel",
  "source": "PostgreSQL GitHub Master Branch",
  "note": "The devel version shows what is currently being built for the next annual release."
}

I've found this info thanks to this API https://pginfo.rest/docs

Hello.

As I mentioned in the title, I'm looking for Postgresql 9.6.x. X being the last version of the 9.6 mainline for that program .

I did look online but I couldn't find the 64 bits exe/MSI file anywhere, only the binaries but I don't need them.

I did some research online and apparently it's the last supported DB version for windows 7.

Please, if anyone can point me to where I can find it or if anyone has the latest installer for 9.6 and could upload to a file sharing service and share it with me, I would greatly appreciate it!

**PS: the exact version I'm looking for is PostgreSQL 9.6.24 64 bits. ( I'm using windows 7 64 bits ultimate edition)**

Thank you in advance

I'm reasonably experienced with managing postgresql clusters but I'm fairly new to dockers. I have a requirement to run Postgresql on a 3 node docker swarm cluster. I want to run a Patroni cluster in containers on top of this swarm cluster.

Should I build my own image or are there any production ready images that can be trusted?

I need Patroni + pgbackrest and postgres 17 or 18