It kinda always baffled me that MySQL always had better (free) GUIs (MySQL WorkBench) while what was in my opinion (and nowadays I think most others) didnt have any good ones
There were always some commercial GUIs for PGSQL, but the free or opensource ones were very bad
PgAdmin is very bad in my opinion, functional, but .. i guess i never really liked that it was web based, it felt slow and clunky and the aesthetics were off
Now Azure Data Studio have a PG Plugin, I didnt try it yet, but I used Azure Data Studio for MS SQL, and I am starting to like it a lot, I do hope Azure Data Studio continue to support many more DBMSes and hope that it get more adoption and support for PGSQL and from the PGSQL community
EDIT
One more thing I want to mention, Azure Data Stuido, have a feature that currently only support MS SQL, its the database project
In a DB Project on ADS (Azure Data Studio), you work on your DB declaratively , i.e. you work on a SQL script that describe your table or other objects (A Create Statement) and the Poject tooling auto generation to alt and deployment scripts by comparing changes vs target , you can deploy directly from ADS or generate a dakpac to be executed as part of your CI/CD
Also since all you code is simple .sql file you can easily use source control
All other tools mentioned below have nothing that come close, not even DataGrip from Jetbrain
I do hope that MS will add support for other DBs to their Database Project feature in ADS, its an amazing feature, and the only way one should work on a DB
postgres has some cool tools these days. postico if you are on macos or my personal fav lately has been https://www.beekeeperstudio.io/ which is also multi-db
sequel pro (which afaik has not been updated since 1928?) could be compared with postico2 as far as native look and feel go - https://eggerapps.at/postico2/
Sequel Pro have been abandoned and lacks support for some newer version of databases, and there is a maintained fork here: https://github.com/Sequel-Ace/Sequel-Ace
Agreed. I do recommend DBeaver to customers that want a GUI for PostgreSQL. It's better at almost everything and it handles ssh tunnels well. Even certificates.
I don't have any GUI client installed now. I ssh to servers and use psql there. I use psql locally and inside docker containers. I used pg-cli (?) years ago but I probably lost it during one of the various reinstalls (usually one for each Ubuntu LTS, I'm on Debian now) and I forgot about it.
DBeaver is powerful and better than anything else I found (except maybe datagrip), but honestly its UX is terrible. It takes a million clicks to do basic things, the "export results" functionality is a maze, "rename connection" is a different functionality from "edit connection", ctrl+tab doesn't work, it's generally very noisy visually...
I am using it on a daily basis and it's very powerful, but it shoves all the complexity at your face, it doesn't scale down. And it uses ~7% of my M1 CPU while sitting there unused, not even connected to any DB.
You are absolutely right. The current state of pgAdmin is enfuriating. I was forced to work with it recently, and I thought after all these years maybe something happened... oh dear, how wrong I was. That app is a full-rewrite away from production level.
I actually prefer a web-based tool. I've been using pgweb - and I add it to my Docker Compose for development work so it provides a great, simple, lightweight way to interact with the database while working on a project.
I'd definitely prefer something with a few more features, and have also been surprised there's not a lot of options. Desktop clients definitely have their use, but I like using a web-based tool that I can spin up alongside my project very easily with no config/setup.
I helped some hotshot developer (who is clearly better Python programmer) debug an app which serves vector tiles. He insisted he wants to use MongoDB, because "he doesn't need to learn SQL". The app worked mostly fine except for low zoom levels in which some country outlines got chopped. The issue was that MongoDB only has spherical geometry as a first-class citizen. If you make a query against a 4-vertex bounding box, then on low zoom there's a discrepancy between querying on a sphere vs querying on WGS84 or Mercator. The solution was to densify vertices of the square against which objects to be served were intersected.
> The solution was to densify vertices of the square against which objects to be served were intersected.
I remembered the easiest solution to query which lines with some width cross some bounding box (for putting them in quadtree). Just increase BB size by half a line width on each side and you have a very good approximation of a much harder and slower problem. A small percentage of lines will be returned and not drawn, but it's a good trade-off.
Love the episode and the guests, but let me point out just how good the hosted pages look at Transistor, the podcast hosting used here. I'm not affiliated, though I run my own shows there, too. The UI just vanishes into the background and puts the conversation right into the center. That's good SaaS :D
It depends on your needs. For example, with a write-heavy workload, MySQL will generally outperform Postgres, assuming you’re using it as intended (e.g. don’t use UUIDv4 or other random values as a PK).
That isn't my experience at all. MySQL wins at serving a large number of very simple SELECT queries and plain bulk INSERTs.
But Postgres wins hands down once the queries get slightly more complex, for larger numbers of concurrent UPDATEs, and kicks the pants off MySQL with a RETURNING clause where you don't have to perform a followup SELECT after each write, especially to get the new ID. (Necessary for writable CTEs and explains why MySQL doesn't support them.)
And don't get me started on MySQL's lack of range types and their associated indexes. Exclusion constraints can be a godsend to data validity.
MySQL has improved greatly since 8.x, but it's still very far behind the capabilities of Postgres, MS SQL Server, DB2, and Oracle.
MySQL does simple things fast though not as fast as SQLite. It's getting squeezed on the high end by all the other big SQL vendors and squeezed on the low end by SQLite. It lives in a functionality gap that keeps getting narrower and narrower.
Can’t speak to your experience or schema, but IME MySQL does just fine at high (100+K QPS) mixed workload, with complicated queries. It does require more tuning than Postgres, but OTOH there’s more to monitor to determine exactly what is bottlenecking. That’s certainly not to say Postgres can’t also handle volume, but its MVCC design and O2N tuple ordering doesn’t lend itself as easily to high write workloads.
No returning clause, you’re correct - no way around that if it matters for your use case.
Similarly, yes, functional indices are quite nice if you know how and when to use them.
I’d love to see benchmarks comparing the two RDBMS, properly tuned, with the same workload. I’m OOO this week but I might do that in the future to see for myself.
As to SQLite, I get the appeal, and I get why it maintains backwards-compatibility so fiercely, but good lord some of its quirks are bad. FKs don’t do anything by default, PKs can have NULLs, column types are mere suggestions unless you enable strict mode…
> Similarly, yes, functional indices are quite nice if you know how and when to use them.
In fairness to MySQL, you can simulate this surprisingly well by adding indexes to computed columns.
> I’d love to see benchmarks comparing the two RDBMS, properly tuned, with the same workload. I’m OOO this week but I might do that in the future to see for myself.
This is where I see most existing database benchmarks falling down.
tl;dr: testing database performance across engines is a lot harder than most folks realize.
Imagine you have a DB where you're tracking classroom assignments for all public schools in the state. Here are some requirements:
* A classroom must have at least one teacher and at least one student per class scheduled.
* A classroom must not allow more students than its capacity.
* No teacher or student may be assigned to more than one classroom at the same day/time.
To solve this in MySQL, you MUST use application code to check for conflicts and will always be subject to race conditions at your data layer.
The check for existing slots must always be a separate query from the insert, and MySQL cannot restrict overlapping timestamp ranges at the data layer. This requires data custodial work to resolve.
Postgres on the other hand both supports a timestamp range type but also allows exclusion constraints to prevent the same person from being assigned to more than one class when those ranges overlap—a data layer restriction that makes app support code unnecessary and race conditions logically impossible.
Testing "the same workload" is difficult because the data schemas do not match, the application code calling it will not match, and if you did implement it, folks would cry about "apples and oranges" and how they're not the same workload.
In MSSQL, you might write a .NET component that lives in the database and handles the potential race condition. You also might use temporal tables in that engine to track changes over time, something that (again) would involve non-trivial code changes for MySQL and Postgres to match requirements.
Overly basic benchmarks aside it’s the slightly more complex queries or starting in the hundreds of thousands or millions of records at the very start of the data was night and day.
Learning to do things well in Postgres while being fairly competent in MySQL for the better part of 15 years was still a gap.
When I saw the ability or availability of extensions - part of me did wish I spent more time with Postgres instead of MySQL/MS SQL/Oracle, etc alone.
I have used MySQL for far, far longer than Postgres. My brain still thinks in MySQL. I like it for pretty much everything first if I have my way.
MySQL is very capable until it isn’t.
I’m surprised how many of the hundreds of hours of tweaking that were needed in MySQL when reaching scaling issues aren’t.
I realize most people will try to pick the best, but there is none. MySQL is perfectly good to learn and use at the same time as Postgres.
Postgres can be more complex out of the box but some of the things it has are too hard to ignore.
While I can use the command line, I prefer to have something with good tooling to help create beginners. Postgres is behind here.
I decided to use Postgres for a project and it was too much of a headache compared to MySQL - it was new to me as well, until I reached a problem that it solved without issue and MySQL had tripped up at. In this case I was dealing with tens of millions of rows as a starting point.
Learning to do something the Postgres way compared to how my brain knows how to use MySQL has been helpful and slowly improving.
Postgres is the absolute best you will get for diverse relational data with strict consistency needs and not a huge amount of data of each type (AKA, what databases were created for).
It's second best (or third) for the stuff that historically made people abandon relational databases. But it's absolutely the best choice for its core functionality.
(But well, Python is the best system scripting language around. So the phrase was always an exaggeration.)
TablePlus (https://tableplus.com/) is my current goto - even has a nice iOS app for on the run queries. I have fond memories of Sequel Pro and this app scratches that itch.
$89 USD for a perpetual license for a GUI database management tool? That seems pretty cheap to me.
We used to use Sql Server Management Studio with Red Gate SQL Prompt. That auto-completion / sql refactoring tool cost $200 a year per seat, and even that was worth it.
PostGIS is awesome! I use it quite extensively for the backend of my hobby project: https://cubetrek.com
It's basically a Strava-like webapp to manage activity data for running, hiking, biking etc.
PostGIS makes it very easy to query tracks in a given bounding box, get matching activities to compare past performances on the same tracks etc. Also the GeoJSON conversion is very handy to integrate it with MapLibre GL JS on the front end.
41 comments
[ 4.7 ms ] story [ 79.4 ms ] threadThere were always some commercial GUIs for PGSQL, but the free or opensource ones were very bad
PgAdmin is very bad in my opinion, functional, but .. i guess i never really liked that it was web based, it felt slow and clunky and the aesthetics were off
Now Azure Data Studio have a PG Plugin, I didnt try it yet, but I used Azure Data Studio for MS SQL, and I am starting to like it a lot, I do hope Azure Data Studio continue to support many more DBMSes and hope that it get more adoption and support for PGSQL and from the PGSQL community
EDIT
One more thing I want to mention, Azure Data Stuido, have a feature that currently only support MS SQL, its the database project
In a DB Project on ADS (Azure Data Studio), you work on your DB declaratively , i.e. you work on a SQL script that describe your table or other objects (A Create Statement) and the Poject tooling auto generation to alt and deployment scripts by comparing changes vs target , you can deploy directly from ADS or generate a dakpac to be executed as part of your CI/CD
Also since all you code is simple .sql file you can easily use source control
All other tools mentioned below have nothing that come close, not even DataGrip from Jetbrain
I do hope that MS will add support for other DBs to their Database Project feature in ADS, its an amazing feature, and the only way one should work on a DB
Beekeper is nice but lacks some of the GUI Tools, there's no point in having a nice GUI but not any good amount of functionality.
At times I see folks new to Postgres using 2 or 3 different GUIs to do different things.
never realized sequel pro was open source: https://github.com/sequelpro/sequelpro
The note about sequel ace below is worth noting too for anyone wanting to try it out.
Datagrip is also fine if you're a Jetbrains user.
[1] https://dbeaver.io/
I hop into the native apps for more complex, database specific features (GIS etc) but generally it’s perfect.
I don't have any GUI client installed now. I ssh to servers and use psql there. I use psql locally and inside docker containers. I used pg-cli (?) years ago but I probably lost it during one of the various reinstalls (usually one for each Ubuntu LTS, I'm on Debian now) and I forgot about it.
Recently I discovered Jailer which makes it very easy to navigate complex relational structures: https://github.com/Wisser/Jailer
I am using it on a daily basis and it's very powerful, but it shoves all the complexity at your face, it doesn't scale down. And it uses ~7% of my M1 CPU while sitting there unused, not even connected to any DB.
MySQL WorkBench was always crashing on my Windows machine. That was some years ago so it may have improved.
I mainline DataGrip. It just works.
I'd definitely prefer something with a few more features, and have also been surprised there's not a lot of options. Desktop clients definitely have their use, but I like using a web-based tool that I can spin up alongside my project very easily with no config/setup.
I remembered the easiest solution to query which lines with some width cross some bounding box (for putting them in quadtree). Just increase BB size by half a line width on each side and you have a very good approximation of a much harder and slower problem. A small percentage of lines will be returned and not drawn, but it's a good trade-off.
I migrated to them in 2005 (from mysql) and was amazed by how much happier I was. And it never cost me a dollar.
I loved it so much I visited its authors in Victoria and bought consulting from them. They are amazing folks.
But Postgres wins hands down once the queries get slightly more complex, for larger numbers of concurrent UPDATEs, and kicks the pants off MySQL with a RETURNING clause where you don't have to perform a followup SELECT after each write, especially to get the new ID. (Necessary for writable CTEs and explains why MySQL doesn't support them.)
And don't get me started on MySQL's lack of range types and their associated indexes. Exclusion constraints can be a godsend to data validity.
MySQL has improved greatly since 8.x, but it's still very far behind the capabilities of Postgres, MS SQL Server, DB2, and Oracle.
MySQL does simple things fast though not as fast as SQLite. It's getting squeezed on the high end by all the other big SQL vendors and squeezed on the low end by SQLite. It lives in a functionality gap that keeps getting narrower and narrower.
No returning clause, you’re correct - no way around that if it matters for your use case.
Similarly, yes, functional indices are quite nice if you know how and when to use them.
I’d love to see benchmarks comparing the two RDBMS, properly tuned, with the same workload. I’m OOO this week but I might do that in the future to see for myself.
As to SQLite, I get the appeal, and I get why it maintains backwards-compatibility so fiercely, but good lord some of its quirks are bad. FKs don’t do anything by default, PKs can have NULLs, column types are mere suggestions unless you enable strict mode…
In fairness to MySQL, you can simulate this surprisingly well by adding indexes to computed columns.
> I’d love to see benchmarks comparing the two RDBMS, properly tuned, with the same workload. I’m OOO this week but I might do that in the future to see for myself.
This is where I see most existing database benchmarks falling down.
tl;dr: testing database performance across engines is a lot harder than most folks realize.
Imagine you have a DB where you're tracking classroom assignments for all public schools in the state. Here are some requirements:
* A classroom must have at least one teacher and at least one student per class scheduled.
* A classroom must not allow more students than its capacity.
* No teacher or student may be assigned to more than one classroom at the same day/time.
To solve this in MySQL, you MUST use application code to check for conflicts and will always be subject to race conditions at your data layer.
The check for existing slots must always be a separate query from the insert, and MySQL cannot restrict overlapping timestamp ranges at the data layer. This requires data custodial work to resolve.
Postgres on the other hand both supports a timestamp range type but also allows exclusion constraints to prevent the same person from being assigned to more than one class when those ranges overlap—a data layer restriction that makes app support code unnecessary and race conditions logically impossible.
Testing "the same workload" is difficult because the data schemas do not match, the application code calling it will not match, and if you did implement it, folks would cry about "apples and oranges" and how they're not the same workload.
In MSSQL, you might write a .NET component that lives in the database and handles the potential race condition. You also might use temporal tables in that engine to track changes over time, something that (again) would involve non-trivial code changes for MySQL and Postgres to match requirements.
Learning to do things well in Postgres while being fairly competent in MySQL for the better part of 15 years was still a gap.
When I saw the ability or availability of extensions - part of me did wish I spent more time with Postgres instead of MySQL/MS SQL/Oracle, etc alone.
MySQL is very capable until it isn’t.
I’m surprised how many of the hundreds of hours of tweaking that were needed in MySQL when reaching scaling issues aren’t.
I realize most people will try to pick the best, but there is none. MySQL is perfectly good to learn and use at the same time as Postgres.
Postgres can be more complex out of the box but some of the things it has are too hard to ignore.
While I can use the command line, I prefer to have something with good tooling to help create beginners. Postgres is behind here.
I decided to use Postgres for a project and it was too much of a headache compared to MySQL - it was new to me as well, until I reached a problem that it solved without issue and MySQL had tripped up at. In this case I was dealing with tens of millions of rows as a starting point.
Learning to do something the Postgres way compared to how my brain knows how to use MySQL has been helpful and slowly improving.
It's second best (or third) for the stuff that historically made people abandon relational databases. But it's absolutely the best choice for its core functionality.
(But well, Python is the best system scripting language around. So the phrase was always an exaggeration.)
We used to use Sql Server Management Studio with Red Gate SQL Prompt. That auto-completion / sql refactoring tool cost $200 a year per seat, and even that was worth it.
It's basically a Strava-like webapp to manage activity data for running, hiking, biking etc.
PostGIS makes it very easy to query tracks in a given bounding box, get matching activities to compare past performances on the same tracks etc. Also the GeoJSON conversion is very handy to integrate it with MapLibre GL JS on the front end.