The Reasons Why pgAdmin Chose ReactJS

March 10, 2021

pgAdmin 4 is a management tool for PostgreSQL and EDB Postgres Advanced Server. pgAdmin 4 was re-written from pgAdmin 3 (a native desktop application). The application is designed to work on both the desktop and a web server. It is written in Python using Flask with the user interface written in JS/jQuery/Backbone, and can be deployed on any network.

It is 2021, and one might argue about why pgAdmin chose jQuery/Backbone. The development work of pgAdmin 4 started in around 2014, and back then, Backbone.js was one of the most popular frameworks. Backbone.js was even more popular than React at the time. Below is the Google trend.

But as the time went on, fewer developers used Backbone.js, and due to decreasing popularity, it became a legacy library. It is difficult to find Backbone developers these days. But, why?


Why move away from Backbone?

It was then time to re-evaluate whether we should continue with Backbone or choose some other framework. Our analysis found the issues below in Backbone:

  • Backbone views are difficult to reuse and difficult to scale. The backbone code used in pgAdmin is repetitive and not easy to test in an automated way. It also attracts coding mistakes.
  • As the application grew, the complexity increased and performance was hit. Constant render calls caused many expensive DOM updates.
  • DOM updates are hard in Backbone. A developer needs to manually update the DOM using jQuery when certain events are triggered by Backbone.
  • There are very few Backbone developers today. pgAdmin is an open-source community project. With a fewer number of contributions, it makes the development speed slow. A developer needs to understand the backbone code first, which takes time.


The framework pgAdmin chose: ReactJS

The new libraries available today are much more advanced and have a lot of pros over Backbone. This blog by Sergey Krivov is a great article on choosing the right web framework. React has following advantages over Backbone:

  • React focusses on testable and reusable components. This makes the UI more robust and faster to develop.
  • React uses virtual DOM for DOM updates. This increases the UI performance considerably. A developer does not have to manually update DOM elements. React provides a fully managed rendering lifecycle and thus reduces coding errors.
  • React has a strong community of developers. There are a lot of ready to use advanced components. Porting to React may also attract community contributions to pgAdmin and increase the development speed.
  • React code is readable and easy to understand. Developers are willing to learn React.


Migrating to React.js

A POC certainly should be the first thing to do before actually starting such a huge task. At EDB, we started with a POC on ReactJS. My colleague Khushboo Vashi started by trying to port the browser tree to React using react-aspen. The POC was tested against 10,000 tree nodes. To our surprise, it was able to load all the nodes flawlessly within no time, with smooth scrolling. If we test the same with the current implementation, it takes significantly more time and affects the performance of the complete application.

Based on the results, the following strategy was chalked down:

  • React allows developers to run parts of the application using ReactDOM.render. Using which, developers can use React inside multiple containers along with the existing frameworks.
  • Follow 0/100. What that means is, all the new features/tools to be built in pgAdmin would be 100% ReactJS based. Old bugs have to be fixed as before. The ERD tool is a good example. It is completely developed with ReactJS and has good test coverage.
  • Reduce the usage of Backbone/jQuery library by porting form components to ReactJS. We have already started porting the Properties tab and Create/Edit dialog form for the database objects. The dialog container still remains non React but the form inside it would be React based.
  • As we move up the component hierarchy, the containers can be replaced with React replacements. Parallely, increase the test coverage of the components.
  • Housekeeping tasks are already logged to move in this direction, including migrating the browser tree.
  • pgAdmin has a lot of code written using Backbone/jQuery. Although it may take time, the fruits of patience are always sweet. We will say goodbye to Backbone/jQuery dependencies once everything is ported and de-linked. Till then, it will run alongside React.



ReactJS has a strong developer community and popularity. It has grown to a level where its performance is comparable to that of desktop applications. Migrating pgAdmin to use ReactJS will certainly boost pgAdmin performance and user experience. Developers can focus more on implementing features rather than wasting time on coding errors and managing DOM. We hope this also attracts React developers to contribute to pgAdmin making this amazing product even more pleasant.

If you want to get involved in pgAdmin development, check out the Development area on the pgAdmin website.

Share this

Relevant Blogs

The limitations of LLMs, or why are we doing RAG?

Despite powerful capabilities with many tasks, Large Language Models (LLMs) are not know-it-alls. If you've used ChatGPT or other models, you'll have experienced how they can’t reasonably answer questions about...
June 17, 2024

PGVector as Embedding Store in PrivateGPT

EDB has a long history of open source contributions, and while we’re best known for our contributions to Postgres, that’s not the only project we contribute to. e.g Barman, CloudNativePG...
June 05, 2024

More Blogs

Finding memory leaks in Postgres C code

I spent the last week looking for a memory leak in Postgres’s WAL Sender process. I spent a few days getting more acquainted with Valgrind and gcc/clang sanitizers, but ultimately...
March 27, 2024