PgNative

PgNative

A fast, lightweight PostgreSQL client for Mac & Windows.

19 followers

Stop renting your DB tools. PgNative is a high-performance PostgreSQL client built with Rust and Tauri. It’s ultra-lightweight (under 10MB), memory-efficient, and runs natively on Apple Silicon, Intel, and Windows. No subscriptions, just speed.
PgNative gallery image
PgNative gallery image
PgNative gallery image
PgNative gallery image
PgNative gallery image
Free
Launch Team / Built With
Intercom
Intercom
Startups get 90% off Intercom + 1 year of Fin AI Agent free
Promoted

What do you think? …

Alan Lee
Maker
📌
Hi Product Hunt! 👋 I’m the developer of PgNative. I was tired of heavy database clients that felt like they were running a whole browser just to execute a SQL query. I built PgNative using Tauri and Rust to create the lightest, fastest experience possible. By moving away from Electron, I managed to get the app size under 10MB and memory usage down to a fraction of other tools. Why we built this: Cross-Platform: Full support for macOS (Apple Silicon/Intel) and Windows. Rust Backend: High-performance, memory-safe database connections. Privacy First: Your data stays local. No telemetry, no cloud middleman. Pay Once: I believe in the 'Indie' way. Buy it once, use it forever. We’re just getting started and would love to hear what features the PH community wants to see next!
Amit Sharma

Under 10MB for a Postgres GUI is kinda wild… how’re you handling the usual heavy stuff like schema browsing + query history without it turning into a memory hog?

Alan Lee

@amitpsharma 

Good question. The small size mostly comes from being very intentional about scope and architecture.

PgNative doesn’t try to be a “do everything” database client. It focuses on the workflows people hit most often: querying, browsing tables, and inspecting schemas. Anything that would require a lot of background state or long-running caches is either loaded on demand or kept minimal.

For schema browsing, metadata is fetched lazily instead of preloading entire schemas. Query history is stored locally in a lightweight way and only loaded when you actually open it, not kept resident in memory all the time.

The other big factor is avoiding Electron and heavy embedded runtimes. Being native keeps memory usage predictable and low by default, instead of fighting a browser engine.

So it’s less about magic optimization and more about deliberate constraints: smaller scope, lazy loading, and native foundations.