PopSQL

PopSQL is a SQL editor built for teams rather than for one analyst at one desk. Queries live in a shared, searchable library instead of in files scattered across laptops, several people can edit the same query at once with live cursors showing who is where, and the result of any query can become a chart, a dashboard tile or a link pasted into a chat channel. The editor itself is familiar, with autocomplete, a schema browser and error highlighting. The difference is everything around it.

The desktop client connects to a long list of databases, including PostgreSQL, MySQL, SQL Server, SQLite, Snowflake, BigQuery, Redshift, ClickHouse, Athena, Presto and Trino, with MongoDB and Cassandra among the less usual entries.

It also reaches databases sitting behind a private network, which the browser version cannot, and that is the main reason to install it rather than working in a tab.

Note that PopSQL is in limited support, so only critical fixes arrive and no new features are planned.

Writing queries, and the schema browser beside them

PopSQL autocomplete suggests table and column names as you type and flags errors before you run anything. The schema browser on the side goes further than a plain tree.

It shows which tables and columns are actually used most, lets you pin the ones you return to, and filters the list when a warehouse has hundreds of tables. Descriptions can be added to tables and columns, so the next person knows that a column called status_2 is the one that matters.

That data catalog layer is quietly the most useful part for a team with a large schema. New analysts stop asking which of three similar tables is the real one, because the answer is written next to it. Browser admin panels such as phpMyAdmin show the structure but offer nowhere to explain it.

Live collaboration and a full edit history

Share a query and colleagues see it update as you type, with presence indicators showing who else is in it. That suits peer review, pairing on a tricky join, or walking someone through a query without a screen share. Queries sit in folders with permissions set per folder, and a global search finds them by name or content.

Every change is versioned. The history shows who edited what and when, with a diff view, and any previous version can be restored or copied out. Git sync pushes the whole query library to a repository, which gives you a proper backup and a way to review changes through pull requests, the same workflow Git handles for code.

Query variables, then charts and dashboards

Variables in PopSQL turn a query into a small report. Put a placeholder where a date range or user ID goes, and anyone running it fills in the value from a form rather than editing the SQL. That makes a query safe to hand to someone who reads SQL badly, since they never touch the text.

Results can be charted without leaving the editor, in the common chart types, and charts can be grouped into dashboards. It is a basic reporting layer rather than a full business intelligence tool, fine for a weekly metrics view and thin for anything with complex filtering or drill-down.

Scheduled queries run on a timer and deliver the results by email or to a chat channel, which covers the recurring report nobody wants to run by hand.

Connections, shared credentials and private networks

Connections can be personal or shared with the team, and shared ones carry permissions, so read access to production can go to engineering while analysts see only the warehouse. That also means credentials are set up once, by whoever manages the database, instead of pasted into every laptop.

For a database that is not reachable from the internet, the desktop client connects directly from inside the network, whether that is a local PostgreSQL server or a warehouse, and SSH tunnels and a bridge connector cover the other arrangements. dbt Core projects can also be worked on from the editor, which suits teams already modelling their data that way.

Where it sits against desktop SQL clients

Compared with DBeaver, which handles more databases and far more administration work, PopSQL is thinner as a database tool and far stronger as a shared workspace. DBeaver is where you design tables and migrate data. This is where a team keeps its queries and reuses them.

The limits are real. It needs an account and works through its own service even when the client is installed locally, it does not manage schemas or users the way an administration tool does, and the charts will not replace a dedicated reporting product.

With development frozen, gaps such as more advanced visualisation or deeper admin features will not be filled.

Conclusion

PopSQL suits data teams who write SQL together and lose time to queries pasted into chat, stale copies on laptops, and nobody knowing which table is the real one. Analysts, engineers who support them and the occasional manager who runs a report once a week will all find something here, and the shared library, the version history and the query variables are the features they will use daily.

It is not an administration tool and not a full reporting platform, and its limited-support status means you are choosing it for what it does today. If that set of features fits your team, keep Git sync running for peace of mind and it does the job well.