Hi On Tue, 13 Oct 2026 at 19:35, Darren Duncan <[email protected]> wrote:
> So, then, given that the PgAdmin 4 lineage just by itself is now 13 years > old > and a lot has changed since then in the technology landscape... > > Hypothetically, would you consider starting a PgAdmin 5 written in Java or > some > other stack, or would you still choose the same stack you have now to make > a > major new version today? > > For me personally, by coincidence, Java is my top preferred and > recommended > application language, when the problem domain does not specifically favor > something else, and I feel Java continues to receive vast useful > improvements > each year. Key factors include it having strong compile-time checking and > typing > while still heavily supporting generics, and having multiple major vendors > supporting the core product. I have no plans to do so - pgAdmin is so big now it would be a huge task, really only viable if it were entirely vibe coded (though, modern versions of Opus and Fable are more than capable of producing far better code than most of us these days, *when properly guided*, so that’s not the end of the world I suppose). If I did, I would not use Java though. Most of my recent projects have been Go on the backend, and Typescript/React on the front end. Though, Typescript throughout would probably make more sense for pgAdmin, given we would need to use Electron to host the desktop version. > > Despite that, I do not currently feel that PgAdmin 4 is not "modern" or > needing > a rewrite for technology sake. > > And I agree with the core design decision of a common code base for both a > desktop application and a web application, this helps with the longevity > of the > current version, although at the same time also making it more > structurally > adaptable to piecewise rewrite, such as replacing the Python layer with > Java > while keeping the Javascript layer as that, not that there are really any > alternatives to running in a web browser that aren't involving Javascript. Many of the early problems with pgAdmin were down to the use of Python on the backend, and then figuring out how to make that work in NWjs and later Electron when our custom desktop host didn’t work out as we hoped. Sticking entirely to Typescript makes the most sense for Electron, which would mean running under Node in server mode. > > On 2026-10-13 6:48 a.m., Dave Page wrote: > > You're not wrong, but at this point I wouldn't use the word "new" for > pgAdmin 4 :-) > > > > Screenshot 2026-10-13 at 14.45.49.png > > > > pgAdmin 1 (well, just pgAdmin back then), actually started in 1998/1999. > I'm not > > sure of the exact date - the predecessor, pgManager was never released > and that > > only lived for a brief while in 1998 or so. For those that remember it, > it was a > > Visual Basic 4 clone of the original PostgreSQL GUI, pgAccess, written > in TCL/TK. > > > > On Tue, 13 Oct 2026 at 14:31, Darren Duncan wrote: > > > > In the scheme of things, PgAdmin 4 is already an ongoing rewrite in > a new > > language, Python, compared to PgAdmin 3 that was written in C++. > > > > It seems like the team already made their language choice for the > "modern" > > version of the tool. > > > > I would be surprised if they turn around and rewrite it again in > Java any time > > soon, since the Python one is relatively new. > > > > Granted, with the new LLM tools we have now, choosing to rewrite a > codebase > > from > > one language to another isn't necessarily as onerous or time > consuming as it > > once was. > > > > What is the business case to do it now though? > > > > On 2026-10-12 2:19 p.m., Rick Yost NC Data Team wrote: > > > Are there any plans to convert PGAdmin to Java? I deal with very > large > > databases > > > and some of the queries I run produce millions of records, I've > been > > forced to > > > use other products to extract the data and run my queries, but I > always like > > > pgAdmin4 for the smaller stuff. I wish it would do it for the > bigger > > stuff. But > > > since it's based on chromium, apparently there's a problem with > > downloading that > > > many records after I run the query. > > >
