Connecting to PostgreSQL lets you reverse engineer PostgreSQL to an ERD in seconds. Schemity reads your tables, columns, primary and foreign keys, unique constraints, indexes, and check constraints, then draws the whole schema.

How do I connect Schemity to PostgreSQL?

Click + above the diagram list, set DB type to PostgreSQL, click Connect to a database, and set Connect via to Direct connection (or SSH Tunnel to reach a database behind a bastion).

What do the PostgreSQL connection fields mean?

  • Host and Port - the server address and port. Port defaults to 5432.
  • Username - the role Schemity authenticates as. A read-only role is recommended for documentation.
  • Password - the role’s password. It is stored in your OS keychain, never in the JSON file. Leave it blank when editing to keep the existing one.
  • DB name - the database to introspect.
  • Schema - the schema to read. Defaults to public. The refresh button inside the field loads the database’s schemas to pick from; you can still type one.
  • Encryption - Disable (local dev only), Require, Verify CA, or Verify full (recommended); the two verify modes also check the server certificate. See encryption and certificates. Use Verify full for any managed or cloud-hosted Postgres.

If you chose SSH Tunnel, an extra block asks for the SSH host, port (default 22), username, password, and an optional SSH key file.

What does Schemity import from a PostgreSQL schema?

Once connected, Schemity imports every table in the target schema - there is no table-picking step. It reads tables and columns with their PostgreSQL types, primary keys and nullability, foreign keys (with their ON DELETE / ON UPDATE actions) drawn as crow’s foot relationships, unique constraints, indexes, and check constraints.

Does Schemity work with Supabase and managed Postgres?

Schemity works as a Supabase schema diagram tool and with any managed Postgres: use the host, port, and Require encryption your provider gives you. Everything renders locally, so you get a private picture of a cloud database without uploading anything.

Does Schemity work with CockroachDB?

Yes. From the release after Schemity 2.14.2, CockroachDB is its own DB type in the connection dialog, with its own logo; Schemity 2.14.1 and 2.14.2 connect to it with DB type set to PostgreSQL, and a diagram created that way keeps working. CockroachDB speaks the PostgreSQL protocol, so Schemity reads, diagrams and migrates it with its PostgreSQL code, and the CockroachDB type adds what differs: the column types and index methods it refuses are not offered, its lint rules run, and its migration warning shows. It was tested on CockroachDB 26.3 with a 17-table, 2-view schema: tables, columns, defaults, identity columns, CHECK constraints, unique constraints, indexes, foreign keys with their actions, views and materialized views all read the same as the same schema on PostgreSQL 18.3.

The fields differ from a PostgreSQL server in three places:

  • Port is 26257, not 5432; the CockroachDB type fills it in.
  • DB name is the database inside the cluster, defaultdb unless you created another, and the Schema refresh button lists its schemas without CockroachDB’s own crdb_internal.
  • Encryption should be Verify full for CockroachDB Cloud. If your cluster gives you a CA certificate, pick it as Root CA. The connection string from the Cloud console’s Connect dialog can be pasted with Paste connection URL.

A few things look different from PostgreSQL because CockroachDB stores them differently, not because Schemity read them wrong:

  • INTEGER columns made elsewhere often show as BIGINT. CockroachDB’s INT is 64-bit unless the session sets default_int_size to 4, so BIGINT is what the database holds. Schemity’s own migrations and exported scripts set it to 4 first, so a column the diagram calls INTEGER is created 32-bit, as on PostgreSQL.
  • CHECK constraints are named check_<column>. CockroachDB names an unnamed check itself; PostgreSQL would name it <table>_<column>_check.
  • The hidden rowid column is left out. CockroachDB adds it to a table or materialized view with no primary key; nobody declared it, so it is not drawn.
  • A hash-sharded index or primary key keeps its sharding. The hidden shard column is not drawn; the index dialog shows USING HASH WITH (bucket_count = n), and a save writes it back.
  • Row counts are estimates from CockroachDB’s automatic statistics. Impact analysis shows them as it does PostgreSQL’s, but they can lag a bulk load by a few minutes. Table sizes in bytes are not shown, because CockroachDB does not report them through the PostgreSQL catalog.

A migration is not all-or-nothing on CockroachDB. Schemity applies a migration in one transaction, which PostgreSQL rolls back whole if a statement fails. CockroachDB commits before each schema change (its autocommit_before_ddl setting, on by default), so if the third statement fails, the first two stay applied, as tested in which failed migrations roll back. The migration dialog warns about this before you apply, as it does for MySQL, and the diagram footer names the server as CockroachDB. Impact analysis does not report statements that hold back reads or writes there, because CockroachDB changes a schema online. Read the migration SQL and its impact before you apply, and apply to a staging cluster first.

Next

Save the diagram to Git (see Version Control in Git), or tidy the layout on The ERD Canvas.