PostgreSQL

PostgreSQL is the engine AddisDB supports most completely. Every feature in the app — the schema diagram, in-grid editing, the Live Monitor, migrations, throwaway test clones, mock data, AI — works against Postgres with nothing extra to install.

Who it is for

Postgres is the default answer for an application database. It is strict about correctness, handles JSON as well as it handles tables, and extends into whole other categories — geospatial with PostGIS, vector search with pgvector, time-series with TimescaleDB — without leaving the database you already run.

Underneath that reputation is a specific set of engineering decisions: real transactional DDL, so a failed migration rolls back instead of leaving you half-migrated; MVCC, so readers never block writers; genuinely enforced constraints, including check constraints and deferrable foreign keys; and an extension system that lets the database grow new types and index methods without a fork.

Reach for it when you want one database to be the system of record for a product: transactions, constraints, foreign keys, and the freedom to add an extension later instead of adding a second datastore.

Where it is the wrong tool: caching and ephemeral counters belong in Redis, petabyte-scale column scans belong in a warehouse, and a single Postgres primary will eventually cap out on write throughput — that is the point at which distributed SQL like CockroachDB or YugabyteDB starts to earn its complexity.

Set up the server

If you already have a Postgres URL from your host — Neon, Supabase, Amazon RDS, Google Cloud SQL, Azure Database, Railway, Render, Heroku — skip ahead; you have everything you need.

1. Managed: create the instance in your provider’s console, then open its Connection details / Connect panel and copy the connection string.
2. Add your machine’s IP to the instance’s firewall or security group — this is the single most common reason a fresh cloud database refuses to connect.
3. Note whether SSL is required. Most managed Postgres requires it; some providers also hand you a CA certificate to download.
4. Check which database the URL actually points at. Providers differ: some default to postgres, some to a database named after your project.
5. Local: install with Homebrew (brew install postgresql@16), the Postgres.app bundle on macOS, apt on Debian/Ubuntu, or Docker.

# A local server in one line
docker run --name pg -e POSTGRES_PASSWORD=secret -p 5432:5432 -d postgres:16

Give AddisDB its own role rather than reusing the one your application connects with. A separate role means an exploratory session can never exhaust the app’s connection pool, and you can start read-only and widen later.

CREATE ROLE addisdb LOGIN PASSWORD 'a-strong-password';
GRANT CONNECT ON DATABASE app TO addisdb;
GRANT USAGE ON SCHEMA public TO addisdb;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO addisdb;

-- so new tables are readable too
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO addisdb;

Connect from AddisDB

1. Click New Connection and pick PostgreSQL under Relational / SQL.
2. Paste your connection string into the Connection URL box and click Fill fields — host, port, database, username and password are split out for you to review. Or leave the URL blank and type the fields yourself.
3. Set SSL mode to require for a managed database, or disable for a local one.
4. Tag the Environment. Marking a connection prod color-codes it everywhere and adds a confirmation before risky writes.
5. Click Test, then Save.

If the database is not exposed to the internet, open Tunnel (optional) and add your bastion host — AddisDB opens the SSH tunnel when you connect and closes it when you disconnect.

When the connection is refused

Postgres error messages are unusually precise. Read the one you get rather than changing settings at random.

• "no pg_hba.conf entry for host …" — the server is reachable but your address is not authorized. On a managed database, add your IP to the allowlist; self-hosted, add a line to pg_hba.conf and reload.
• "SSL connection is required" — set SSL mode to require.
• "password authentication failed for user …" — the role or password is wrong; a URL pasted from a provider sometimes carries a percent-encoded password that needs decoding before it goes in the field by hand.
• "database … does not exist" — you are connecting to a database name the server does not have. Connect to postgres first and look around.
• A timeout with no error at all is almost always a firewall or security group, not Postgres.

Running a local server from the app

On macOS and Linux, AddisDB detects Postgres servers installed through Homebrew and shows them in the Local server field, so you can start and stop the server from inside the app instead of remembering the brew services incantation.

What AddisDB gives you

• Schema as a diagram — the Schema tab lays your tables out by foreign-key relationships, with named views you can save per project.
• Edit without SQL — flip the Edit toggle in the results grid to change cells, add rows, duplicate or delete rows, and set true SQL NULLs.
• Live Monitor — real active queries, the blocking tree, waiting locks and connection stats, with an always-on flight recorder you can scrub back through.
• Test clones — dry-run a whole migration file against a disposable copy of the database, data and all, without touching the real one.
• Mock data — generate realistic rows from your actual schema, tinted amber in the grid, removable in one click.
• Migrations & diff — drive Drizzle Kit or Prisma from the Migrations tab, and compare two databases (or your ORM schema against a live one) in the Diff tab.
• AI — ask questions in plain English against your real schema, and hand a failing query to the AI for a corrected version.
• The safety model — read-only connections, prod tagging, and destructive-statement detection before anything runs.

Watching a database under load

The Live Monitor reads pg_stat_activity for what is running, pg_locks for what is waiting on what, and the per-relation size functions for how big things have grown. Cancelling a query calls pg_cancel_backend; terminating a session calls pg_terminate_backend.

One permission note worth knowing: an ordinary role sees its own query text but not other roles’. Grant pg_monitor (or pg_read_all_stats) to the role AddisDB connects as and the monitor fills in properly instead of showing rows with the query column blanked.

Trying a migration without touching production

Test clones use PostgreSQL’s CREATE DATABASE … TEMPLATE to copy the database — schema and data — into a disposable one, run your statements there, and report what happened. This is the fastest way to find out that a migration takes an ACCESS EXCLUSIVE lock, or that a NOT NULL backfill rewrites a table you thought was small.