A Postgres Admin Panel Without Docker, Without a Server, Without the Headache

I've been working with PostgreSQL for the better part of a decade, and the admin tooling situation has always confused me. Postgres itself is one of the best-engineered pieces of software on the planet. It's fast, it's reliable, it gets a major release every year that actually ships meaningful features. And yet the tools we use to look at our Postgres databases feel like they're frozen in amber.

pgAdmin 4 is the "official" answer, and it hasn't meaningfully improved in years. DBeaver works, sure, but every time I open it I'm reminded that it's a Java app from 2010. TablePlus is nice and fast, but it's a query tool, not an admin panel. And the cloud options like Retool and NocoDB give you a real admin panel, but only if you're willing to route your database connection through their servers.

Everyone I talk to wants the same thing: a modern admin panel for Postgres that doesn't require Docker, doesn't require a server, and doesn't require handing my connection string to a third party. That shouldn't be a controversial ask in 2026. And yet, for a long time, it was.

This post is about how I actually solved that problem for myself, and the workflow I landed on. I'll be fair about the alternatives, because most of them are good tools that just have different tradeoffs. But I'll also show you what I ended up using and why.

The Current Postgres Admin Options (And Their Tradeoffs)

Let's walk through what's actually out there, because the landscape is more nuanced than "pgAdmin bad, everything else good." Each of these tools exists for a reason, and each one has a real audience. The question is which tradeoffs matter to you.

pgAdmin 4

pgAdmin is the official management tool for PostgreSQL, maintained alongside the database itself. That pedigree counts for something. It supports every Postgres feature, it understands the latest server versions on day one, and it has deep support for things like role management, server instrumentation, and the pgAgent job scheduler.

The problem is the architecture. pgAdmin 4 is a web application. To run it locally, you either install it as a desktop app (which bundles a Python runtime and spins up a local web server under the hood) or you run it in Docker. Either way, you're running a Python server to serve a browser UI to talk to a database that's already running on your machine. That's a lot of moving parts for something that should just be "open my database and look at it."

The UI itself is functional but dated. It's a web app pretending to be a desktop app, and you can feel it. Tree navigation, tabbed query windows, a properties panel that takes up half the screen. There are no kanban views, no gallery views, no dashboards. If you want to browse your data as anything other than a SQL result grid, you're out of luck.

For DBAs managing production clusters, pgAdmin is still a reasonable choice. For a developer who just wants a clean view of their local Postgres, it's overkill.

DBeaver

DBeaver is the cross-platform workhorse. It supports basically every database that exists, it's free (the Community Edition is, at least), and it has features for days. ER diagrams, data generation, SQL editing with autocomplete, session management, transaction isolation controls. If there's a database feature, DBeaver probably has a button for it.

But DBeaver is a Java app, and it feels like one. Startup takes a few seconds on a fast machine and noticeably longer on a slow one. The UI is dense, with toolbars inside toolbars inside panels. Every time I open it I spend the first thirty seconds remembering where the thing I need lives. It's powerful, but it's not pleasant.

And like pgAdmin, DBeaver is fundamentally a query tool. You write SQL, you get a grid. There's no kanban view of your tasks table. There's no gallery view of your images table. There's no dashboard that shows me a chart of signups per day next to a table of recent users. If you want those things, you build them yourself or you don't get them.

DBeaver is the right tool if you live in SQL and you want one app for every database you touch. It's the wrong tool if you want your database to feel like a modern application.

TablePlus / Postico

TablePlus (and its Mac-focused sibling Postico) is the category I personally used the longest. These are native, fast, and genuinely pleasant to use. TablePlus opens instantly, runs queries fast, and has a UI that looks like it was designed this decade. On macOS, Postico is even nicer, with a real attention to Mac conventions.

But here's the thing: TablePlus and Postico are query tools, not admin panels. They're great for writing SQL and browsing tables. They are not great for, say, turning your users table into a kanban board, or building a dashboard that your non-technical cofounder can look at, or giving a teammate a restricted view of one table without writing a custom app.

There's also the multi-database question. TablePlus supports a lot of databases, which is great, but each one is still just a query window. You don't get a unified admin panel that treats your SQLite side-project database and your production Postgres database the same way.

If you want a fast native SQL client, TablePlus is excellent. If you want an admin panel, it's not that product.

Cloud admin panels (Retool, NocoDB, Budibase)

This is the category that actually delivers on the "admin panel" promise. Retool, NocoDB, and Budibase all let you point them at a Postgres database and get a real admin panel: tables, forms, dashboards, kanban boards, the works. NocoDB in particular is open-source and can turn a Postgres database into what looks like Airtable in minutes.

The tradeoff is architecture. These are all cloud-hosted (or self-hosted-on-a-server) web applications. To use them, your Postgres connection, your credentials, and often your actual query results flow through their servers. For a production database with sensitive data, that's a real consideration. Even NocoDB, which you can self-host, requires you to run a server, which usually means Docker.

There's also the latency and offline question. If your Postgres is local, routing through a cloud admin panel means your queries go from your machine, up to a cloud server, back down to your local database, and the results reverse the trip. That's silly for a local dev database, and it means you can't work offline.

These tools are genuinely good for what they are. If you need a shared, web-based admin panel for a team, Retool is a serious product. But for a solo developer or a small team working with local or self-hosted Postgres, the cloud round-trip is a tradeoff you shouldn't have to make.

Build your own (Django admin, PostgREST + custom UI)

The final option is the one a lot of engineers default to: build it yourself. Django gives you an admin panel for free if you're already in Django. PostgREST turns your Postgres into a REST API and you build whatever UI you want on top. Hasura does the same thing with GraphQL.

The appeal is obvious: full control, no dependencies on a third-party tool, exactly the views you need. The cost is also obvious: you're maintaining it forever. The Django admin is great until you want a kanban view, at which point you're writing custom templates. PostgREST is great until you realize you now have to build an entire frontend.

I've built this kind of thing three times in my career, and every time it eventually becomes tech debt. The admin panel that was supposed to save time becomes the thing nobody wants to touch because it's coupled to a framework version from two years ago.

Build-your-own is the right answer if your admin panel needs are deeply specific and you have the engineering capacity to maintain them. For everyone else, it's a trap.

What "Without Docker" Actually Means

Here's something that's been bugging me. Go search for "postgres admin panel" and read the first ten tutorials. I'll bet you a coffee that at least eight of them start with docker run.

Something like this:

docker run -p 8080:80 \
  -e PGADMIN_DEFAULT_EMAIL=admin@example.com \
  -e PGADMIN_DEFAULT_PASSWORD=secret \
  dpage/pgadmin4

And look, I understand why. Docker is the lingua franca of deployment. If you're putting an admin panel on a server for a team to share, containerizing it is the right call. I'm not anti-Docker. I use Docker every day.

But think about what's actually happening when you run that command for a local database. You're starting a container. That container runs a Linux environment. Inside that environment, a Python web server starts up. That web server serves a browser UI. You open your browser, which talks to the web server, which talks to the database that's already running on your machine.

For a local developer workflow, that's a comically long chain of indirection. Your database is right there. It's a localhost socket away. You're introducing a container, a Linux userland, a Python runtime, and an HTTP layer just to render a table of rows.

There's also the maintenance angle. Docker images need updates. The pgAdmin image ships a new version and you need to pull it. Your volume mounts need to persist your server registrations. If you restart your machine, the container doesn't come back unless you set up a restart policy. None of this is hard, but it's all friction that exists purely because the tool chose a web architecture.

"Without Docker" doesn't mean "I hate containers." It means: for the common case of a developer who wants to look at their local Postgres, the container layer is unnecessary indirection. A native desktop app that talks to Postgres over a socket is simpler, faster, and more reliable. That's the whole argument.

It also means "without a server." A lot of admin panel tools, even the non-Dockerized ones, are web apps that need a server process running. You're either running it yourself or someone else is. A local-first desktop app doesn't need a server. You launch the app, it connects to your database, you're done. When you quit the app, nothing is running. There's no port to manage, no process to kill, no background service eating RAM while you're not using it.

This is the thing I kept running into. Every "modern" admin panel wanted me to run a server. Every native option was just a SQL client. There was nothing in the middle: native, fast, no server, but with actual admin panel views, not just a query grid.

The Local-First Alternative

This is where I tell you what I actually use. I'm going to be upfront: I'm involved with BaseVolt, so this isn't an unbiased recommendation. But I got involved with it precisely because I was frustrated enough to want something better, so the bias and the use case are the same thing.

BaseVolt is a local-first desktop app. It runs on macOS and Windows. There's no cloud account required, no server to run, no Docker container. You download it, you open it, you connect to your database. That's the whole setup.

The key idea is that it gives any database a full admin panel, not just a query window. So for Postgres specifically, you connect with a standard connection string, and BaseVolt reads your schema, your tables, your columns, your types, your foreign keys. Then it gives you:

A grid view for browsing rows, which is what you'd expect, but with proper foreign-key lookups so you see the related row's display name instead of just an integer ID.
A gallery view for tables that have images or files, which is genuinely useful for content tables.
A kanban view for any table with a status column, which is how I manage my own project tasks that live in Postgres.
A dashboard view where you can drop charts and tables onto a canvas and build something a non-technical person can actually read.

It also has a built-in MCP server. MCP is the protocol that lets AI coding tools like Claude, Cursor, and Windsurf connect to external systems. With BaseVolt's MCP server running, I can point Cursor at my Postgres database and say "add a last_login_at column to the users table and backfill it from the sessions table," and Cursor can actually introspect the schema, write the migration, and run it, because it can see the database through BaseVolt.

The local-first part matters to me. My connection string never leaves my machine. My query results never leave my machine. When I'm working with a local Postgres, everything stays local. There's no round-trip through a cloud server. I can work on a plane.

The free tier lets you connect up to two data sources, which is enough to try it against a local Postgres and maybe a SQLite side project. The Pro tier is $99 a year and adds cross-device sync, which is useful if you want your admin panel config to follow you between a laptop and a desktop.

I'm not going to pretend BaseVolt is the right tool for every situation. It's a desktop app, which means it's not a shared web admin panel for a 50-person team. But for the solo developer and small-team case, which is most of the people I know working with Postgres, it's the thing that finally felt right to me.

Step-by-Step: Postgres Admin Panel in Under a Minute

Let me actually walk you through it, because "under a minute" is a claim I should be able to back up. This assumes you already have Postgres running somewhere, locally or remotely, and you know your connection details.

Step 1: Install BaseVolt

Go to basevolt.app and download the app for your platform. There's macOS and Windows. No account creation, no email confirmation, no credit card. You download a .dmg or an installer, run it, and the app opens.

If you want to poke around before installing anything, there's a demo at demo.basevolt.app that runs in the browser against a sample database. It's not the full desktop experience, but it'll give you a sense of the views and the UI.

This step takes about 20 seconds, assuming your download speed cooperates.

Step 2: Add a PostgreSQL data source

Open the app and click "Add Data Source." You'll see options for SQLite, PostgreSQL, MySQL, and Cloudflare D1. Choose PostgreSQL.

You can connect either by filling in the individual fields or by pasting a standard connection string. I always use the connection string because it's what I already have in my .env files. It looks like this:

postgresql://user:password@localhost:5432/mydatabase

Paste that in, hit connect. BaseVolt connects to Postgres using the standard libpq-compatible protocol, so anything that works with psql works here. SSL mode, custom ports, Unix socket paths, all supported.

This step takes about 10 seconds.

Step 3: Let BaseVolt read your schema

Once you're connected, BaseVolt introspects your database. It reads your tables, your columns, your data types, your primary and foreign keys, your indexes. This is all done locally, over your existing connection.

You'll see your tables listed in the sidebar, grouped by schema. Click any table and you're in the grid view by default, showing the first page of rows. Foreign key columns show the related row's human-readable value instead of a raw ID, which is a small thing that saves me a lot of JOIN queries.

The schema read is cached, so navigating around is instant after the first load. If you change your schema outside BaseVolt, there's a refresh button to re-introspect.

This step takes about 5 seconds, depending on how many tables you have.

Step 4: Browse with grid, kanban, gallery, and dashboard views

This is where it stops being a query tool and starts being an admin panel.

Grid view is your standard table browser. Sortable columns, inline editing, filter rows by any column. You can edit a cell, hit enter, and it writes to Postgres. There's an undo for the current edit. For a users table, this is how I do quick data fixes without writing a UPDATE statement.

Kanban view works on any table that has a column BaseVolt can treat as a status. I have a tasks table in one of my Postgres databases with a status column that's an enum: todo, in_progress, done. BaseVolt automatically offers a kanban view for it, with the three columns, draggable cards, and a count per column. Dragging a card updates the status in Postgres. This is the thing I never had with TablePlus and always wanted.

Gallery view is for tables with image or file columns. I have a products table with a image_url column, and the gallery view shows me a grid of product photos with the product name underneath. It's how I QA a catalog without writing a single query.

Dashboard view is the one I use for reporting. You get a canvas, and you can drop in charts (bar, line, pie) backed by queries against your Postgres, plus tables and stat cards. I have a dashboard that shows signups per day, a table of the ten most recent users, and a stat card with total revenue. I share a read-only version of this with my cofounder, who does not want to write SQL.

Building a dashboard takes a few minutes the first time and then it's saved. You don't have to redeploy anything when you change it. It's just there.

This step takes as long as you want to spend playing with it, but you can get a useful view in well under a minute.

Step 5: Use the MCP server for AI-assisted schema work

This is the part that has actually changed how I work, and it's worth explaining because a lot of people haven't used MCP yet.

MCP, the Model Context Protocol, is a standard way for AI tools to talk to external systems. BaseVolt runs an MCP server locally. You point your AI coding tool, Cursor in my case, at that MCP server. Now Cursor can see your database schema through BaseVolt.

The practical workflow looks like this. I'm in Cursor, and I type: "Add a last_login_at timestamp column to the users table, and write a backfill that sets it to the most recent created_at from the sessions table for each user."

Because Cursor can see my schema through BaseVolt's MCP server, it knows the exact column names, types, and foreign key relationships. It writes a migration that's actually correct, not a guess. I review it, approve it, and it runs against my Postgres. The whole thing takes maybe 30 seconds and I don't have to context-switch over to a SQL client to look up column names.

This works with Claude, Cursor, and Windsurf, anything that speaks MCP. For schema management, schema refactoring, and even data exploration, it's a meaningful productivity bump. I used to spend a surprising amount of time jumping between my editor and a SQL client just to remember whether a column was called user_id or users_id. That friction is gone.

To enable it, there's a setting in BaseVolt that starts the MCP server and gives you the connection string to paste into your AI tool's config. It runs locally, so your schema and query results stay on your machine.

Comparison Table

Here's how the options stack up. I've tried to be fair, because these are all real tools with real users, including me.

Tool	Setup time	Docker required	Native app	Views & dashboards	AI integration	Data leaves machine	Cost
pgAdmin 4	5-10 min (or Docker pull)	Optional, but common	No, web-based	No, query grid only	No	No (if local)	Free
DBeaver	2-5 min	No	Yes (Java)	No, query grid only	No	No	Free (Community)
TablePlus / Postico	1-2 min	No	Yes (native)	No, query grid only	No	No	$59-89/year
Retool (cloud)	10-20 min	No (cloud-hosted)	No, web-based	Yes, full admin panel	Limited	Yes, through cloud servers	Free tier, then $10+/user/mo
NocoDB	5-10 min (self-host)	Yes, typically	No, web-based	Yes, full admin panel	No	Depends on hosting	Free (self-host)
BaseVolt	Under 1 min	No	Yes (native)	Yes, grid/kanban/gallery/dashboard	Yes, built-in MCP server	No	Free tier (2 sources), Pro $99/year

A few notes on the table, because tables flatten nuance:

pgAdmin's "no data leaves machine" is true only if you run it locally. If you use the cloud-hosted pgAdmin, obviously your data goes through their servers.
Retool's AI features exist but are cloud-side, meaning your schema and queries go to their AI provider. BaseVolt's MCP approach keeps the AI interaction in your local editor.
NocoDB is genuinely free and open-source, which is great. The cost is that you're running a server, which is a maintenance burden.
TablePlus is excellent at what it does. It's in this table as the "fast native SQL client" reference point. It's just not an admin panel.

The row that matters to me, and maybe to you, is the last one. Under a minute to set up, no Docker, native app, real views and dashboards, AI integration that runs locally, data stays on my machine, and a free tier that's actually usable. That's the combination I couldn't find anywhere else.

When This Approach Wins (and When It Doesn't)

I want to be honest about this, because no tool is right for every situation, and pretending otherwise is how you end up with marketing copy instead of a useful recommendation.

The local-first, desktop-app approach wins when:

You're an individual developer or a small team working with Postgres. This is the sweet spot. You want a fast, native admin panel, you don't want to run a server, and you don't need to share a web UI with 30 people.
Your Postgres is local or on a machine you can reach directly. If you're connecting to localhost:5432 or to a VPS over a private network, a desktop app is the natural fit.
You care about your data not leaving your machine. This matters for local dev databases with seed data that mirrors production, for databases with PII, and for anyone who's just privacy-conscious by default.
You want AI-assisted schema work without sending your schema to a cloud AI service. The MCP server approach keeps the AI in your local editor while giving it access to your real schema.
You want admin panel views, not just a SQL grid. If kanban, gallery, and dashboards would actually change how you interact with your data, a query tool won't cut it.

The local-first approach doesn't win when:

You need a web-based admin panel shared across a large, distributed team. If you've got 40 people across three time zones who all need to look at the same Postgres database through a browser, pgAdmin deployed on a server, or Retool, or NocoDB, is probably the right call. A desktop app isn't a shared web service, and pretending it is would be dishonest.
You need the admin panel to be accessible from a phone or a random machine without installing anything. Web tools win here by definition. BaseVolt requires installing a desktop app, which is a one-time cost but a real one.
You're on Linux. I'll just say it: BaseVolt is macOS and Windows right now. If you live on Linux, you're better off with DBeaver or a self-hosted NocoDB. I'm not going to pretend a tool that doesn't run on your OS is a good fit for you.
You need deep DBA features like pgAgent job scheduling, server instrumentation, or fine-grained replication slot management. pgAdmin still has the edge there because it's built by the Postgres team for Postgres DBAs. BaseVolt is built for developers and small teams who want an admin panel, not for DBAs running production clusters.

The honest summary is that BaseVolt is the right tool for the developer-and-small-team case, which is a large chunk of the people using Postgres. It's not the right tool for the DBA-managing-a-fleet case, and it's not the right tool for the large-team-shared-web-panel case. If you're in one of those, use pgAdmin or a cloud tool. If you're in the first case, the local-first desktop approach is, in my experience, meaningfully better than the alternatives.

Bottom Line

The Postgres admin tooling situation has been stagnant for a long time, and I think the reason is that most of the tools were built for a different audience than the one using them today. pgAdmin was built for DBAs. DBeaver was built for database-agnostic power users. TablePlus was built for people who want a fast SQL client. The cloud admin panels were built for teams that want a shared web UI.

What was missing, for a long time, was something built for the developer who has a Postgres database and wants a modern admin panel without the Docker, without the server, and without the cloud round-trip. That's the gap BaseVolt fills, and it's why I use it.

If you've been gritting your teeth through pgAdmin in a browser, or squinting at DBeaver's toolbar labyrinth, or paying for TablePlus and still not having a kanban view, give it a try. It installs in under a minute, the free tier lets you connect two data sources, and your data never leaves your machine. The MCP integration alone changed how I do schema work, and the views are the thing I didn't know I was missing until I had them.

Try it at basevolt.app — no signup, no credit card.

If you build something with it, or you have thoughts on how the Postgres tooling landscape could be better, I'd genuinely like to hear it. Find me on X.