Open-source data modeling tool designed for PostgreSQL. No more typing DDL commands. Let pgModeler do the work for you!
Changes since: v1.1.1
This patch release for pgModeler 1.1.x brings the following improvements and fixes:
Changes since: v1.1.0
This patch release for pgModeler 1.1.x brings the following improvements and fixes:
Changes since: v1.0.6
Attention: Some configuration files were changed in pgModeler 1.1.0 causing a break in backward compatibility with pgModeler 1.0.x settings. This way, at the first start of the newer version, pgModeler will try to migrate the older settings to the newer ones automatically!
Summary After one year, 98 new features, 165 changes/improvements, and 88 bug fixes here we are, with great joy, bringing a new major release of pgModeler! The journey was long, with tons of challenges, but the results are satisfying because now we have an even more optimized tool with plenty of new features that will make your database modeling and management jobs more pleasant, accurate, and faster! Below, we have a compilation of new features, changes, and fixes that were implemented since pgModeler 1.0.0. Not everything is listed here and if you're curious about the full changelog of this version, please, take a look at the CHANGELOG.md for more details.
Infinite canvas support: pgModeler now supports infinite canvas. This feature allows objects to be moved to negative coordinates without forcing them to be locked at the origin point (0,0). This brings more flexibility when designing databases allowing the models to grow up in any direction.
Improved code completion: A long-awaited feature finally arrived on pgModeler, the code completion based on living database object names. From now on, in the SQL execution widget, will be possible to list column/table names in the middle of the INSERT, DELETE, TRUNCATE, UPDATE, ALTER, and DROP commands. This feature also considers table aliases and lists the correct columns. It is worth mentioning that this feature is still experimental despite the good results on different kinds of SQL commands, and will be constantly improved on future releases.
Improved UI theme management: In 1.0.x, pgModeler wasn't able to correctly follow the system's color set (dark/light). Now, in 1.1.0, selecting the "System default" UI theme in Appearance settings makes pgModeler properly configure the UI color theme as well as the source code highlight settings to follow the system's color schema.
Improved model loading, objects' searching, and validation speeds: One of the most annoying things on pgModeler was the speed of the operations like objects' search, model validation, and, mainly, database model file loading. During the development of this version, it was decided to improve these three operations. After searching for critical bottlenecks in the tool's core some mechanics were completely rewritten. The two main bottlenecks that degraded the speed of the mentioned operations were the objects' name validation/formatting as well as the retrieval of objects' dependencies and references. Those seemed simple operations that I even could imagine that they were making pgModeler struggle to handle big models. For the objects' name formatting and validation, an internal name cache to avoid calling those procedures repeatedly was created. That simple solution brought a surprisingly good result. For the objects' dependencies and reference handling, an infinitely simpler routine compared to the original one was created and instead of every time calling a procedure that runs countless loops and recursive calls, the objects now store internally which other objects are their references and dependencies. Those changes made models that were loading/validating in several minutes to be processed in a few seconds. After those patches, pgModeler gained an amazing performance increase.
Views creation is now way simpler: Instead of that clunky interface to configure views on previous versions, now it's possible to create this kind of object by using freely typing SQL commands with special placeholder variables enclosed by {} that we call references. Any reference in the typed SQL command that defines the view will be replaced by the referenced object, which can be columns, functions, procedures, tables, foreign tables, and views. Once the view is created, pgModeler will create relationships between the referenced tables (foreign tables, and views) and the new view. Unfortunately, there's one drawback, the feature is not backward compatible with models designed in the previous version, which means if you have models containing views you'll need to use the pgmodeler-cli fix process to make the proper corrections.
Extensions can now have multiple child data types: In previous releases, pgModeler had a special flag in the extension's editing form labeled "Handles data type". That flag served to inform pgModeler that the extension needed to be used as a data type, for example, creating an extension named "hstore" and checking the mentioned flag, would create the type "hstore" making it usable in the columns, function parameters, and so on. The problem with this approach is that if an extension installed more than one data type in the database, it was needed to make some workarounds to have a second type available to be used in the database modeling process. So, in pgModeler 1.1.0, the "Handles data type" flag was ditched and now the user can specify a free number of data types that the extension handles. pgModeler will handle the data types when adding or removing the extension. Models that use the old extension format can be fixed by using the pgmodeler-cli model fix process.
Improved tool's executables relocation: pgModeler already has some mechanisms to customize the paths associated with the assets and executables once installed in the system. One of them is the environment variables, but sometimes the user doesn't want or even has no privileges to change environment variables in the system. Thinking of that, this new version introduces a special configuration file called "pgmpaths.conf" whose goal is to configure the paths where the pgModeler main executable as well as the auxiliary tools can find all the needed folders, assets, and configuration files. This file must be created in the same folder as a pgModeler's executable and must be filled with lines in the format variable=path. The "variable" refers to one of the available environment variables understood by pgModeler (refer to the installation instructions, section "Environment variables" for details) and the "path" is a relative or absolute path to the resource associated with the environment variable.
pgModeler CLI plugins support: The command-line tool now can have extra features implemented through plugins like in GUI. This opens a wide range of possibilities making the CLI an even more powerful tool that can be integrated into your development/deployment pipeline. Refer to pgModeler docs to see how to create your own features for the command-line tool.
Split model file load plugin: This is the first plugin for CLI that is bundled in the paid version of pgModeler. It basically allows one to load split database models (.sdbm) in the CLI and perform any operations available like it was a common (single) database model file (.dbm). This plugin comes as a complementary feature for the split model plugin that allows the saving of database model files in separate files.
SQL session plugin: This version introduces the SQL session plugin, available in the paid version of the tool, which implements simple routines to save the current opened SQL command execution sessions in a specific configuration file which can be restored in the next pgModeler execution by clicking the action "Restore SQL session", close to the connections combo box, in the Manage view.
Backup utility plugin: This version introduces the backup utility plugin, also available in the paid version of the tool, which implements a user-friendly interface for the commands pg_dump, pg_dumpall, pg_restore and psql commands. This extra feature was developed mainly focused on attending to those users less comfortable with command-line tools, making it possible to dump and restore databases without leaving pgModeler's GUI. Of course, advanced users are welcome to use the plugin and help to improve it! In a nutshell, besides configuring backup tools' parameters with a simple form, the plugin allows the creation of presets per backup tool for different needs, it also has some facilities that automate the backup file name generation by using a default backup folder and name patterns.
Other changes and improvements
Bug fixes
Changes since: v1.1.0-beta
Attention: Some configuration files were changed in pgModeler 1.1.0-beta1 causing a break in backward compatibility with pgModeler 1.0.x settings. This way, at the first start of the newer version, pgModeler will try to migrate the older settings to the newer ones automatically!
Summary This version was supposed to be released earlier this month, but after discovering a critical problem on macOS that almost made pgModeler unusable, there was the need to perform lots of refactoring on all portions of the UI, which consumed more time than expected. Fortunately, most problems were solved and now the macOS version runs normally after a long routine of adjustments and tests. Of course, one or another corner case may not be covered and eventually will be quickly patched once reported.
Changes/improvements
Bug fixes
Finally, for more details about this version's changelog, please, refer to CHANGELOG.md.
Changes since: v1.1.0-alpha1
Attention: Some configuration files were changed in pgModeler 1.1.0-beta causing a break in backward compatibility with pgModeler 1.0.x settings. This way, at the first start of the newer version, pgModeler will try to migrate the older settings to the newer ones automatically!
Almost two months after launching 1.1.0-alpha1, I'm pleased to announce 1.1.0-beta! This version is the last of this development cycle to receive new features, and from now on, until the release of the stable 1.1.0 only bug fixes will be done. My main focus on this release was to work on two things that always bothered me since the early days of pgModeler: the view creation process and the extension data types handling. Since the codebase was mature enough, I thought it was time to change those two aspects of the tool, and this was done as described below:
Views creation is now way simpler: Instead of that clunky interface to configure views on previous versions, now the user can create this kind of object by using freely typed SQL commands with special placeholder variables enclosed by {} that we call references. Any reference in the typed SQL command that defines the view will be replaced by the referenced object, which can be columns, functions, procedures, tables, foreign tables, and views (yeah, views!). Once the view is created, pgModeler will create relationships between the referenced tables (foreign tables, and views) and the new view. Of course, not everything is roses, the feature is not backward compatible with models designed in the previous version, which means if you have models containing views you'll need to use the pgmodeler-cli fix process to make the proper corrections.
Extensions can now have multiple child data types: In previous releases, pgModeler had a special flag in the extension's editing form labeled "Handles data type". That flag served to inform pgModeler that the extension needed to be used as a data type, for example, creating an extension named "hstore" and checking the mentioned flag, would create the type "hstore" making it usable in the columns, function parameters, and so on. The problem with this approach is that if an extension installed more than one data type in the database, it was needed to make some workarounds to have a second type available to be used in the database modeling process. So, in pgModeler 1.1.0-beta, the "Handles data type" flag was ditched and now the user can specify a free number of data types that the extension handles. pgModeler will handle the data types when adding or removing the extension. Models that use the old extension format can be fixed by using the pgmodeler-cli model fix process.
Improved tool's executables relocation: pgModeler already has some mechanisms to customize the paths associated with the assets and executables once installed in the system. One of them is the environment variables, but sometimes the user doesn't want or even has no privileges to change environment variables in the system. Thinking of that, this new version introduces a special configuration file called "pgmpaths.conf" which goal is to configure the paths where the pgModeler main executable as well as the auxiliary tools can find all the needed folders, assets, and configuration files. This file must be created in the same folder as a pgModeler's executable and must be filled with lines in the format variable=path. The "variable" refers to one of the available environment variables understood by pgModeler (refer to the installation instructions, section "Environment variables" for details) and the "path" is a relative or absolute path to the resource associated with the environment variable.
Several other improvements: General improvements were made all over the tool and some of them are described below.
Bug fixes: Also, as part of the constant search for the overall tool's stability and reliability, almost twenty bugs were fixed, and below we highlight some key ones:
Finally, for more details about the version's changelog, please, take a look at the file CHANGELOG.md.
Changes since: v1.0.5
This patch release for pgModeler 1.0.x brings the following changes and fixes:
Changes since: v1.1.0-alpha
Attention: Some configuration files were changed in pgModeler 1.1.0-alpha1 causing a break in backward compatibility with pgModeler 1.0.x settings. This way, at the first start of the newer version, pgModeler will try to migrate the older settings to the newer ones automatically!
Here we are, after working for 4 months, bringing you the last alpha release of pgModeler 1.1.0. This version was mainly focused on improving performance on several parts of the tool. So I put a huge effort into refactoring lots of code to reach an amazing (almost unbelievable) result. Let's see below:
Improved model loading, objects' searching, and validation speeds: One of the most annoying things on pgModeler for me was the speed of the operations like objects' search, model validation, and, mainly, database model file loading. During the development of this version, I decided to face the challenge of improving these three operations, so I delved into the internals of the tool looking for the major bottlenecks. After selecting the problematic ones, I took the path of rewriting some mechanics instead of trying to fix them. The two main bottlenecks that degraded the speed of the mentioned operations were the objects' name validation/formatting as well as the retrieval of objects' dependencies and references. Those seemed simple operations that I could even imagine that they were making pgModeler struggle to handle big models. For the objects' name formatting and validation, I decided to create an internal name cache to avoid calling those procedures repeatedly. A simple solution that brought a surprisingly good result. For the objects' dependencies and reference handling, I completely ditched the methods written for that purpose and created something infinitely simpler. Instead of calling every time a procedure that runs countless loops and recursive calls, I just made the objects store internally which other objects are their references and dependencies. Those changes made models that were loading/validating in several minutes to be processed in a few seconds. I still have some other bottlenecks to solve, but those two already removed, gave pgModeler an amazing performance.
Several other improvements: General improvements were made all over the tool and some of them are described below.
Bug fixes: Also, as part of the constant search for the overall tool's stability and reliability, almost twenty bugs were fixed, and below we highlight some key ones:
SQL session plugin: This version introduces the SQL session plugin, available in the paid version of the tool, which implements simple routines to save the current opened SQL command execution sessions in a specific configuration file which can be restored in the next pgModeler execution by clicking the action "Restore SQL session", close to the connections combo box, in the Manage view.
Finally, for more detailed information about this release's changelog, please, refer to the CHANGELOG.md file.
Changes since: v1.0.4
This patch release for pgModeler 1.0.x brings the following changes and fixes:
Changes since: v1.0.x
Attention: Some configuration files were changed in pgModeler 1.1.0-alpha causing a break in backward compatibility with pgModeler 1.0.x settings. This way, at the first start of the newer version, pgModeler will try to migrate the older settings to the newer ones automatically!
After five months of development, the first alpha release for pgModeler 1.1.0 is finally ready and brings some important improvements compared to 1.0.x. Below, the key changes are briefly detailed:
Improved code completion: A long-awaited feature is finally arriving pgModeler, the code completion based on living database object names. From now on, in the SQL execution widget, will be possible to list column/table names in the middle of the INSERT/DELETE/TRUNCATE/UPDATE commands. This feature also considers table aliases and lists the correct columns. It is worth mentioning that this feature is still experimental despite the good results on different kinds of SQL commands.
Improved UI theme management: In 1.0.x, pgModeler wasn't able to correctly follow the system's color set (dark/light). Now, in 1.1.0-alpha, selecting "System default" UI theme in Appearance settings makes pgModeler properly configure the UI color theme as well as the source code highlight settings to follow the system's color schema.
Several UI improvements: As always, general UI improvements are made attending to the users' requests. This time pgModeler brought a long list of enhancements, but the following ones are worth mentioning:
Bug fixes: Also, as part of the constant search for the overall tool's stability and reliability, almost twenty bugs were fixed, and below we highlight some key ones:
Backup utility plugin: This version introduces the backup utility plugin, available in the paid version of the tool, which implements a user-friendly interface for the commands pg_dump, pg_dumpall, pg_restore and psql commands. This extra feature was developed mainly focused on attending to those users less comfortable with command-line tools, being possible to dump and restore databases without leaving pgModeler's GUI. Of course, advanced users are welcome to use the plugin and help to improve it! In a nutshell, besides configuring the backup tools parameters with a simple form, it allows the creation of presets per backup tool for different needs, it also has some facilities that automate the backup file name generation by using a default backup folder and name patterns.
Finally, for more detailed information about this release's changelog, please, refer to the CHANGELOG.md file.
Changes since: v1.0.3
This patch release for pgModeler 1.0.x brings the following changes and fixes: