PgDeck

PostgreSQL query tool

Running SQL against PostgreSQL.

Most people searching for a PostgreSQL query tool mean one of two things: how to use pgAdmin's Query Tool, or what to use instead of it. This page covers both, because they are the same question asked from different ends.

Short answer: pgAdmin's Query Tool is the built-in answer: open it with a database selected, write SQL, and press F5 to run. psql is faster for scripting and remote work. If the browser interface is what you want to escape, any native desktop client gives you the same SQL execution with less overhead between typing and results.

PgDeck PostgreSQL desktop client with schema navigation, table filtering, row editing, and SQL tools

Why developers use PgDeck

PgDeck is shaped around PostgreSQL tasks that happen every day: connect, inspect, filter, edit, query, manage structure, copy, and export.

F5 runs the query; selecting text runs only the selection
EXPLAIN ANALYZE reports the real plan, not the estimated one
Wrapping destructive statements in BEGIN is the cheapest safety habit there is
\copy in psql writes files client-side, avoiding server permissions
Query history is what saves you when you forget what you ran yesterday

Secure connections

Save PostgreSQL connection details with encrypted passwords, SSL settings, URL import, testing, search, edit, and delete actions.

Schema and data grid

Browse schemas and tables, search the table list, pin favorites, filter rows, sort columns, resize columns, and paginate results.

SQL workspace

Run SELECT and non-SELECT statements from multi-tab SQL editors with syntax highlighting and interactive query results.

Staged editing

Edit cells, add rows, duplicate rows, set NULL, stage deletes, review pending changes, and commit everything in one transaction.

How to run a query in PostgreSQL

  1. In pgAdmin: open the Query Tool on the right database

    Select the database in the browser tree first, then open Tools, Query Tool, or use the toolbar icon. The Query Tool always runs against whatever was selected when you opened it — running a statement against the wrong database is almost always this step going wrong rather than the SQL being wrong.

  2. Run it, or run just the part you selected

    F5 executes. If you highlight a portion of the editor first, only the highlighted text runs, which is how you keep several queries in one tab and execute them individually. That behaviour is shared by most clients, PgDeck included.

    SELECT id, email, created_at
    FROM users
    WHERE created_at > now() - interval '7 days'
    ORDER BY created_at DESC
    LIMIT 100;
  3. Check what a slow query is actually doing

    EXPLAIN ANALYZE runs the query and reports the real plan and timings. Read it before adding an index: a sequential scan on a small table is fine, and an index that is never chosen costs write performance for nothing.

    EXPLAIN ANALYZE
    SELECT * FROM orders WHERE customer_id = 42;
  4. Wrap anything destructive in a transaction

    An UPDATE without a WHERE clause is the classic production incident, and a query tool will run it without complaint. Open a transaction, run the statement, check the row count, then commit or roll back. This is a habit worth having regardless of which tool you use.

    BEGIN;
    UPDATE orders SET status = 'refunded' WHERE id = 4821;
    -- check the reported row count is 1, not 40000
    COMMIT;   -- or ROLLBACK;
  5. Get the results out

    Most query tools export the result grid to CSV or JSON directly. pgAdmin offers download-as-CSV from the results panel; psql has \copy, which writes client-side and does not need server file permissions. PgDeck exports a result set or a filtered view to CSV, JSON, or SQL INSERT statements.

    \copy (SELECT * FROM users WHERE active) TO 'users.csv' WITH CSV HEADER

pgAdmin's Query Tool, and its one real annoyance

It is capable: syntax highlighting, execution plans, result grids, and CSV download are all there. The friction is that it lives in a browser, so tab state is fragile, a lost session can take an unsaved query with it, and a large result set feels heavier than the query that produced it. Everything else about it is fine, which is why the complaints are so consistently about the interface rather than the features.

When psql is the better answer

Scripting, running migration files, working over SSH on a server, piping output into another command, and anything you want reproducible. \copy, \dt, \d tablename, and \timing cover a lot of ground quickly once learned. A GUI query tool is better for exploring data you have not seen before; psql is better for work you intend to repeat.

What query history is worth

The single most useful feature in any query tool is the one nobody shortlists on: a record of what you ran. Recovering the query you wrote on Tuesday, checking exactly what you executed before something broke, or rebuilding a report from an ad-hoc statement all depend on it. PgDeck keeps query history and saved queries locally; pgAdmin and psql both keep history too, in less convenient forms.

Multi-tab is more useful than it sounds

Real query work means one tab holding the query you are refining, another with the schema lookup you keep rerunning, and a third with the count you check after each change. A tool that makes tabs cheap changes how you work; one that makes them fragile pushes you toward one long scratch buffer. It is the most common reason developers move from a browser query tool to a desktop one.

Do not run structure changes casually

ALTER TABLE and DROP COLUMN execute as readily as a SELECT in any query tool, and they are not covered by an UPDATE you can correct afterwards. Read the statement before running it, do it inside a transaction where the change permits, and take a backup first if the table matters. Clients that preview the generated SQL and ask for confirmation on structure actions exist because this is a common way to lose data.

What is the PostgreSQL Query Tool?

Query Tool is the name of pgAdmin's SQL editor. You open it from the Tools menu with a database selected, write SQL, and press F5 to execute. Other clients call the same thing a SQL editor or SQL tab.

How do I run a query in pgAdmin?

Select the database in the browser tree, open Tools then Query Tool, type your SQL, and press F5. If you highlight part of the editor first, only the highlighted text runs, which lets you keep several statements in one tab.

What is the shortcut to run a query in pgAdmin?

F5 executes the query. Selecting text before pressing it runs only the selection. Most desktop clients follow the same convention, so the habit carries across tools.

Is there a better PostgreSQL query tool than pgAdmin?

Better depends on the job. pgAdmin's Query Tool is capable and free; its weakness is running in a browser, which makes tabs fragile and large result sets heavy. A native desktop client gives you the same SQL execution with less interface overhead. psql remains the better tool for scripting and remote work.

How do I export query results to CSV?

In pgAdmin, use the download option on the results panel. In psql, use \copy, which writes the file client-side and so does not need server file permissions. In PgDeck, export a result set or a filtered view to CSV, JSON, or SQL INSERT statements.