Not sure why you're being downvoted, the lack of quality FOSS IDEs for Postgres is well known.
I do feel that Postgres administration mostly caters to command line fans (like myself); the people more used to visual tools like SQL Server Management Studio tend to find it difficult to transition because of this. Even if they might be absolute wizards at writing SQL otherwise.
Part of it is familiarity of course, but there's always something ever so slightly embarrassing about showing people psql when they're used to advanced IDEs.
I also found this when I switched from MySQL. After a while you discover the right tool for the job, and often some tolls that don’t exist for other databases (things like PostgREST come to mind). Sometime I wish it was a bit more idiomatic though.
We’re working on a lot of tooling at https://supabase.io. We’re open source too. If there is anything in particular you’re missing, let me know
Since you guys are doing something I highly agree with and I replied to your announcement post as well...
How about a UML/ERD diagram tool which can spit out schemas and, given a schema to start with, migrations?
There are a couple dozen of these being offered as SAAS with varying levels of usability and complexity. If you built one of those you'd soon have the attention of everyone who is bitching about paying 20 dollars a month to see their own database in a way that management can visualize for their charts and graphs.
ERD diagrams have existed for decades. Even Oracle gives such a tool away. But for Postgres, the easiest way to create a schema with migrations without a credit card is still to write a Django model by hand, afaik.
That's a great idea for the diagrams. I'm slowly working towards dumping schemas/types for the database in various formats over here: https://supabase.github.io/pg-api/
Once we've stabalized this we will start on git integrations - link up your repo for to keep everything in code - your types, schema, tables, functions, etc. We are also brainstorming ways that we can offer branching - since we give a full database server, we can possibly "branch" the default "postgres" database into various schemas which you can test with.
> ERD diagrams have existed for decades
If you know of a good open source tool which we should be supporting for this, let me know. Otherwise we don't mind building from scratch!
There is a Node migration library that seems well received but as I hinted above I have always trusted Django's migration system and still use it to bang out schemas if I know the schema will change, so I can't vouch for this lib personally...
If this is worth pitching in a meeting, I'd point out that the creator of GraphQL is also the creator of Airtable, which seems to be a thriving startup. The whole business model there is to give people visual tools to get into a database and out of a spreadsheet.
The story in all of this is that the only thing keeping Joe Q. Public from using a database instead of a spreadsheet is the very first step: designing a schema. Database design isn't really an impossible task for a non-developer to learn, if it can be visualized. If you start out at a command line and try to explain many-to-many relationships to them in code, you just lost them. People are visual creatures.
Since we're talking about giving people an API that takes care of CRUD and basic view logic at the database itself, and returns the data and the success/fail/delay messaging in a way that is standardized on the UI via javascript objects and async browser functions, the only hurdle that's left is that first one...
...designing a schema.
edit: on your topic of branching into test environments, I am in the process of evaluating low-code platforms for non-profits with limited development money but complex data needs at the moment, so I think we're thinking about the same things.
Everyone and their brother is working on a low-code platform at the moment. A big part of whether those platforms succeed or not is how they handle "last mile" complex logic. By last mile I mean, you can feasibly deliver basic CRUD and data analysis visualizations with drag and drop and query binding in generic javascript UI components. But there's still going to be the 10% complex business logic cases that don't fall within the 90% of an application that the generic components and boilerplate don't cover.
Off the top of my head, you could guide a user through some form logic that picks the first hundred or fifty or whatever rows from their existing tables that match a certain subset of shared keys, and tells them to flag columns which have sensitive data. Once the columns are flagged the tool could jumble the data in those columns and spit out a sandbox without any identifiable sensitive data that they could then safely hand to a contractor or freelancer to work on for custom development.
I misspoke, not a founder of the company but an engineering hire there after he left Facebook, and the creator of PostGraphile. The gist of what I was getting at is there is a lot of activity swirling around putting business logic back on databases, it seems.
We might look back at these days as the high water mark of "peak javascript."
I'm curious to the particulars (I have no opinion on the technical merits of Microsoft's offering as I've never tried it). What specifically does it do better?
I don't want to stir up a religious battle here, but the tooling around MSSQL is just that much better.
And the sql dialect is imo more to my taste.