pgpad: a small cross-platform database client built on Tauri

What pgpad claims to be, and what it refuses to be

pgpad is described in the README header as a straightforward cross-platform database client, and the tagline in the project description calls it a small, fast cross-platform database client. The badge in the README marks it as work in progress, and the closing section repeats the point.

The What is it section lists the design goals. A lightweight, snappy tool for everyday queries, with quick startup, and the README says it loads up in less than a second on the author's machine. Small memory footprint. Small bundle size. And then the part that sets the project's tone: most importantly, pgpad is free and will always be, which the README spells out as including not ever having a Community Edition, pop-ups asking for an upgrade, or anything of the sort.

The What is it not section is a single line, and it is the most important scoping statement in the README. pgpad is not a fully-fledged professional DB management system like DBeaver.

That single sentence defines both the use case and the limit. The audience is someone who opens a database to run a query, look at a schema or check a row count, and closes it again. It is not the audience for someone who lives in a schema designer.

The licence is GPL-3.0, the licence file sits at the repository root, and the package manifest lists Vinicius R. Miguel as the author. The repository is not archived and the last push was on 2026-10-04, though the package version is 0.0.1 and the project has no GitHub releases at all, so there is no release stream to pin against.

The database support table, read as a roadmap

The support table is the most informative part of the README, and it is worth reading in full because it separates what works from what is planned with unusual clarity.

PostgreSQL is marked implemented and primary, with the note that it is the one most used by the authors and that it is unit-tested, using tokio-postgres as the driver. SQLite is implemented and unit-tested using rusqlite. CockroachDB is implemented, and the note explains why it needs no dedicated work: it is implemented due to the Postgres Wire Protocol, with the caveat that there are no CockroachDB-specific tests currently.

Everything else is planned or out of scope. MySQL, Microsoft SQL Server, Oracle, Clickhouse, SQLCipher and DuckDB are all listed as planned, each with a driver crate named in the table. MongoDB is marked as not currently planned, with the reason that it would require some refactors to accommodate a NoSQL DBMS. MariaDB has a blank status and a note that Rust lacks a dedicated MariaDB driver, so the project could support it only through MySQL compatibility.

Two things stand out. The CockroachDB entry is the interesting engineering point, since speaking the Postgres wire protocol gets you compatibility for free as long as the server behaves. The MariaDB entry is the honest one, since it names a language ecosystem gap rather than a scheduling problem, and a project that says that is telling you something about its scope discipline.

The MySQL driver cell is a placeholder, so do not take the table as a precise dependency map for the engines that are not built yet.

A Rust workspace with a Svelte webview on top

The repository layout describes the architecture more clearly than the README does. The Cargo.toml declares a workspace with three members, pgpad-core, pgpad-web and src-tauri, on resolver version 2, and the release profile is tuned hard: panic abort, one codegen unit, link time optimisation on, opt-level 3 and symbols stripped.

Those release settings are a performance decision rather than a default, and they line up with the README's claim about startup time and small bundle size. Link time optimisation across the whole graph and a single codegen unit make builds slower and binaries smaller and faster, which is exactly the trade a native client makes against a runtime-dependent application.

The frontend side is Svelte 5 with Vite 6, and the package.json shows the toolchain in full. The UI framework is Svelte with the bits-ui component library, tailwind-variants and tw-animate-css for styling, and Tailwind CSS 4 through the Vite plugin. Icons come from unplugin-icons with Iconify packages for Lucide, Simple Icons and the CoreUI Bootstrap icon set. The query editor is CodeMirror 6, with the SQL language package, plus the lint, autocomplete, search and command modules and the one-dark theme, which tells you the editor is a real code editor with diagnostics rather than a plain textarea.

The script names also describe the workflow. dev runs Vite, build runs vite build, preview runs vite preview, check runs svelte-check against the app tsconfig plus tsc on the node config, test runs vitest with a test:run variant, format runs prettier and lint runs a prettier check plus eslint.

The split between pgpad-web and src-tauri is the Tauri arrangement, where the Svelte app is the frontend and the Rust side is the desktop host that owns the database connections.

Building it from source with npm and the Tauri CLI

The build instructions are short because the toolchain is conventional for a Tauri project. The requirements are a relatively recent build of npm and the Rust toolchain with a minimum version of 1.85.

Install the dependencies first:

npm install

Then build the executable:

npm run tauri build

And to start the dev server during development:

npm run tauri dev

The tauri script in package.json is just the Tauri CLI, and the devDependencies include the CLI package itself, so the tauri commands come from the local dependency rather than a global install. The package manifest also has pnpm-lock.yaml at the repository root alongside package-lock.json, so the project has been worked on with more than one package manager.

The platform requirements are stated in the same section as the support table. pgpad supports Windows 7 and later, macOS 10.15 and later, and Linux, which must have libwebkit2gtk 4.1 or higher. That last constraint is the Tauri webview requirement rather than a pgpad choice, but it is the one that trips people up, because an older distribution's webkit package will not satisfy it and the error usually surfaces as a build failure in the system webview.

Other repository entries worth noting for a contributor: there is an e2e/ directory, a vitest.config.ts, a components.json for the bits-ui library, a svelte.config.js, a download-certs.py script with a certs/ directory, and separate tsconfig files for the app, the node side and the base configuration.

The GPL-3.0 licence, and what it means for a desktop tool

pgpad is GPL-3.0, which is the strongest copyleft in common use and a deliberate choice for a tool whose author is explicit about never shipping a paid tier.

For a user who runs the application, the licence is unremarkable. You can install it and use it for anything, commercial work included, and the copyleft obligation is triggered when you distribute the program, not when you run it.

For someone who wants to modify and redistribute it, GPL-3.0 requires that the source of your modified version is offered under the same terms, and it adds the usual patent grant and anti-tivoisation clauses. This is the case where a company would need to think, particularly if the plan is to ship pgpad inside a larger product or a managed service. This review does not give legal advice, and the licence text is the thing to read.

What the licence does not do is settle the question of whether a hosted deployment counts as distribution, and that is exactly the boundary that matters for a project whose selling point is that it will always be free. A company running pgpad as a service to its own users is not distributing the binary, but the analysis is fact specific and belongs with whoever handles licence questions in the organisation.

One more practical point. The author is a single developer working on this in his own time, and the project has no releases, so the version string in package.json is 0.0.1. There is no support commitment, no stability guarantee and no patch process. For a tool you use to poke at a production database during an incident, that is a real consideration rather than a paperwork one.

Where pgpad is the wrong tool

The first case is data modelling. pgpad states plainly that it is not a fully-fledged professional database management system like DBeaver, and the feature list is honest about the scope. There is no schema designer, no migration runner, no ER diagram view, no data import tooling and no role or permission management. If your work involves changing a schema and then applying it to several environments, you want the other tool.

The second case is multi-database work. Only PostgreSQL, SQLite and CockroachDB are implemented, with CockroachDB arriving as a side effect of the Postgres wire protocol rather than as tested support. MySQL, SQL Server, Oracle, Clickhouse and DuckDB are planned, MongoDB is explicitly out of scope, and MariaDB would come only through MySQL compatibility. A team that spans engines is not served here today, and the two planned engines with dedicated Rust drivers, Clickhouse and DuckDB, are the ones most likely to need real work rather than a protocol shortcut.

The third case is a team that needs stability. The project is marked work in progress in the README badge, the version is 0.0.1, there are no GitHub releases, and the maintenance statement is an invitation to open issues for bug reports and feature requests. There is no changelog to read and no release notes that say what broke.

The alternative worth comparing is not another Tauri client, it is the stack you already have. A query editor built on CodeMirror, a Postgres driver you already depend on, and a small script that writes results to a file is usually less work than adopting any client at all, and for a scripted workflow it is more reproducible. Where a GUI earns its place is interactive exploration, and there the honest comparison is with the heavyweight IDE clients: pgpad wins on startup time, memory footprint and price, and loses on feature coverage, on database breadth, and on anything that requires a vendor to call when something breaks.

Editorial conclusion

pgpad fits a developer who runs ad hoc queries against PostgreSQL or SQLite and wants a tool that opens in under a second without the weight of a full database IDE, provided you are willing to accept a project that still calls itself work in progress and ships no tagged releases. It is the wrong choice for a data engineer who needs schema modelling, migration tooling, ER diagrams or multi-database support, and for anyone who needs a maintained release stream. Before building it, confirm your platform is covered, since Linux needs libwebkit2gtk 4.1 or higher while Windows needs 7 or newer and macOS needs 10.15 or newer, and check that the drivers you need are in the implemented column rather than the planned one.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. vrmiguel/pgpad on GitHub