DEV Community: Varun Krishnan

Supabase Auth Schema Explained: Users, Identities, Sessions

Varun Krishnan — Tue, 25 Aug 2026 15:00:00 +0000

The short version

Supabase stores auth in a separate auth schema not your public schema. Every user has exactly one row in auth.users, one or more rows in auth.identities (one per login provider), and can hold multiple active auth.sessions, each backed by a refresh_tokens row. If you've ever poked at a Supabase database and seen a cluster of tables you didn't create, these are the ones, and this is what they do.

auth.users 1───* auth.identities
auth.users 1───* auth.sessions
auth.sessions 1───* auth.refresh_tokens

Why an `auth` schema at all

Supabase deliberately keeps auth separate from your app's tables. Your public schema is where your own models live; auth is locked down and managed by the auth service (GoTrue). You read from it, you don't write to it. That separation is why your migrations never touch these tables and why introspecting a Supabase database shows you a schema you didn't write.

The four tables that matter

auth.users one row per user.

Column	What it holds
`id`	UUID primary key; the user's stable identifier
`email` / `phone`	Contact + login identity
`encrypted_password`	Bcrypt hash (only for email/password auth)
`raw_app_meta_data`	Provider claims: `provider`, `providers`, `email`
`raw_user_meta_data`	Custom metadata you set on the user
`is_sso_user`	True when sign-in came through SSO
`confirmed_at`	When the primary identity was confirmed

auth.identities - one row per login method.

A user signing in with email and GitHub gets two rows here. provider_id is the provider's identifier for that user; identity_data is the raw claim payload (name, avatar, email) the provider returned. The FK user_id → users.id is what joins them.

auth.sessions - a browser/token session.

One session per logged-in device roughly. aal (assurance level), user_agent, ip, and not_after all live here. factor_id links to MFA factors when you have TOTP enabled.

auth.refresh_tokens - the long-lived token backing a session.

Access tokens are short (JWT, ~1h). Refresh tokens are long and stored here, revoked flag included, with parent used to detect token reuse and rotate.

How they relate (the joins you'll actually write)

select u.email, i.provider, s.id as session_id
from auth.users u
join auth.identities i on i.user_id = u.id
join auth.sessions  s on s.user_id = u.id;

That query is the 80% case: "who is signed in, through which provider, on which sessions." Every relationship is a plain foreign key identities.user_id, sessions.user_id, refresh_tokens.session_id which is exactly what a schema diagram turns into readable arrows. If you'd rather trace them visually, paste a read-only connection string into dbdiagramr and it will pull and render the same tables.

What's usually NOT your business

auth.instances, auth.audit_log_entries, and auth.schema_migrations are Supabase's own bookkeeping. audit_log_entries records admin actions inside the auth service; instances is leftover multi-tenancy plumbing. If a diagram shows them, ignore them your reads live in the other four.

Practical tips

Never write to auth tables directly. Use the Supabase client / Admin API. Direct inserts create inconsistent state (orphaned identities, unhashed passwords).
Foreign-key joins work across schemas. auth.users.id is the same UUID you'd use in public join public.profiles.user_id → auth.users.id for your own profile data.
A user with no identity row is a sign of trouble. Every normal user has at least one. Orphaned identities without a users row point at a cleanup/import bug.
Sessions accumulate. Old sessions linger; your diagram showing many sessions per user isn't a leak, it's devices and tabs.

This whole picture is easier to keep straight when you can see it. The Supabase auth schema diagram was generated by introspecting a live Supabase database users, identities, sessions, and refresh_tokens with their foreign keys rendered as relationships. Open it next time you're debugging a sign-in flow.

FAQ

Where is the Supabase auth schema?
In the auth schema, separate from your public schema auth.users, auth.identities, auth.sessions, auth.refresh_tokens, plus internal tables.

What is auth.users used for?
It's the single source of truth for who can sign in. One row per user, with email/phone, password hash, metadata, and provider flags.

Why does one user have multiple identities?
Each login method is a separate auth.identities row. Email + GitHub + Google = three rows, all pointing at the same users.id.

What's the difference between a session and a refresh token?
A session is the device/token context; the refresh token is the long-lived credential that renews the short-lived JWT. One session maps to one refresh token chain.

Can I join auth tables to my public tables?
Yes the auth schema isn't isolated for queries. Use auth.users.id as the join key with your public.* tables.

Try It

Live: https://dbdiagramr.space

GitHub: https://github.com/VarunKvK/dbdiagramr

If this is useful to you, a GitHub star helps a solo dev keep building in public. I started this tool because I kept needing to visualize exactly these tables after reading migrations.

PostgreSQL Connection String: Supabase, Neon, Railway

Varun Krishnan — Thu, 20 Aug 2026 14:30:00 +0000

The short version

A PostgreSQL connection string is a single URL that tells a client how to reach your database. It looks like this:

postgresql://postgres:[YOUR-PASSWORD]@db.abcdefghij.supabase.co:5432/postgres

Every provider builds on the same format, and the differences that trip people up are almost never the syntax. They're the port and host your provider hands you. Supabase alone has three different strings for the same database, and two of them won't work from serverless apps.

Anatomy of a connection string

postgresql://  user  :  password   @     host        :  port  /  database
     |          |         |              |              |          |
  protocol    username  secret         server        port       db name

Part	Example	Notes
Protocol	`postgresql://`	`postgres://` also works in most clients
User	`postgres`	In Supabase: `postgres.[project-ref]` on pooler URLs
Password	`[your-password]`	URL-encode special characters (`@` → `%40`)
Host	`db.xxxx.supabase.co`	The server; provider-specific
Port	`5432`	6543 = transaction pooler (Supabase/Neon)
Database	`postgres`	Default database name

You can append query parameters after the database. The two you'll actually meet are ?sslmode=require (force TLS) and ?channel_binding=require.

Supabase: three strings for one database

Supabase is where most people hit the connection-string wall, because the right string depends entirely on where your code runs:

Mode	Host	Port	Best for
Direct	`db.[project-ref].supabase.co`	`5432`	Migrations, `pg_dump`, long-lived backend
Shared pooler (session)	`aws-[region].pooler.supabase.com`	`5432`	Persistent backend on IPv4-only networks
Shared pooler (transaction)	`aws-[region].pooler.supabase.com`	`6543`	Serverless / edge / short-lived connections

# Direct
postgresql://postgres:[YOUR-PASSWORD]@db.[project-ref].supabase.co:5432/postgres

# Shared pooler session mode
postgres://postgres.[project-ref]:[YOUR-PASSWORD]@aws-[REGION].pooler.supabase.com:5432/postgres

# Shared pooler transaction mode (the one most apps want)
postgres://postgres.[project-ref]:[YOUR-PASSWORD]@aws-[REGION].pooler.supabase.com:6543/postgres

The gotcha: direct connections run on IPv6. On an IPv4-only network you get an ENOTFOUND, not a friendly error, just a silent failure to connect. The shared pooler is IPv4-only and fixes it. And if your app is serverless (Vercel functions, edge runtimes, Lambda), use transaction mode (port 6543). It's built for the many-short-connections pattern serverless forces.

This exact confusion is why tools that accept a connection string usually ask you to grab the transaction pooler URL. dbdiagramr, for instance, has a step in its how-it-works guide telling you to select the Transaction pooler in the Supabase dashboard before pasting. Otherwise the connection silently fails from IPv4-only hosts.

Neon: pooled vs direct

Neon makes the two variants explicit in the hostname:

# Pooled (through PgBouncer, use by default)
postgresql://user:pass@ep-cool-rain-123456-pooler.us-east-2.aws.neon.tech/neondb?sslmode=require

# Direct
postgresql://user:pass@ep-cool-rain-123456.us-east-2.aws.neon.tech/neondb?sslmode=require

Rule of thumb: use the -pooler host unless you have a specific reason not to. It handles thousands of concurrent clients and is the right call for serverless. Grab both from the Connect button in the Neon dashboard.

Railway: the plain standard

Railway gives you a no-frills connection string with no pooler decision to make:

postgresql://postgres:[YOUR-PASSWORD]@[host].railway.app:5432/railway

It's the textbook format, which makes it the easiest one to read and the easiest to misplace a password in. Store it in Railway's Variables tab as DATABASE_URL, never in code.

All the formats in one table

Provider	Connection string shape
Standard / Railway	`postgresql://user:pass@host:5432/db`
Supabase (direct)	`postgresql://postgres:pass@db.[ref].supabase.co:5432/postgres`
Supabase (session pooler)	`postgres://postgres.[ref]:pass@aws-[region].pooler.supabase.com:5432/postgres`
Supabase (transaction pooler)	`postgres://postgres.[ref]:pass@aws-[region].pooler.supabase.com:6543/postgres`
Neon (pooled)	`postgresql://user:pass@ep-xxx-pooler.region.aws.neon.tech/db?sslmode=require`
Neon (direct)	`postgresql://user:pass@ep-xxx.region.aws.neon.tech/db?sslmode=require`

Gotchas that will actually bite you

IPv4 vs IPv6. Supabase direct connections are IPv6. If you're on an IPv4-only network or using a tool on an IPv4-only host, you'll get ENOTFOUND and no obvious reason why. The pooler strings are IPv4 and sidestep it.
Serverless wants the transaction pooler. Long-lived backends can hold a connection. Serverless functions can't. Each invocation opens a new one. Session-pooling chokes on that pattern; transaction pooling (port 6543) exists for exactly it.
A connection string is a secret. It contains your password in plain text. Never commit it, never paste it into a shared doc, and use a pooler/proxy string when a third-party tool needs it. Most good tools never store it beyond the one request. (dbdiagramr introspects your schema and discards the string immediately.)
URL-encode passwords. A password containing @, :, or / breaks the URL. Encode those characters (@ → %40) before pasting.

Curious what that pooler URL actually contains after it connects? The Supabase auth schema diagram was created by introspecting a live Supabase database through a transaction pooler string. Users, identities, sessions, and refresh_tokens rendered as relationships.

FAQ

What is a PostgreSQL connection string?
It's a single URL containing everything needed to reach a Postgres database: protocol, username, password, host, port, and database name (e.g. postgresql://user:pass@host:5432/db).

Should I use a direct connection or a pooler?
For a persistent backend that can hold a connection open, direct is fine. For serverless or edge functions that open a connection per invocation, use a pooler, either Supabase transaction mode (port 6543) or a Neon -pooler host.

Why does my Supabase connection fail with ENOTFOUND?
You're probably using the direct connection string over IPv4, and Supabase's direct endpoint is IPv6. Switch to a shared pooler string (aws-[region].pooler.supabase.com) or add the IPv4 add-on.

Is my connection string a secret?
Yes, it's your password in plain text. Keep it in environment variables, rotate it if it leaks, and only hand it to tools that won't store it.

Try It

Live: https://dbdiagramr.space

GitHub: https://github.com/VarunKvK/dbdiagramr

If this is useful to you, a GitHub star helps a solo dev keep building in public. I hit the IPv6 wall the first time I tried to visualize a Supabase database from a serverless app. Figured others would save the hour.

How to Visualize a PostgreSQL Schema: 5 Ways Compared

Varun Krishnan — Tue, 18 Aug 2026 14:30:00 +0000

The short version

Your Postgres schema is perfectly readable to the database and almost unreadable to a human. The tables, columns, and foreign keys you need are spread across pg_catalog, information_schema, and a few hundred lines of migration SQL. Visualization means collapsing all of that into a picture you can actually reason about.

There are five practical ways to get there. They are not equivalent. Each makes a different trade between speed, depth, and how current the diagram stays.

The five ways at a glance

Method	Setup	Interactive	Stays current	Best for
`psql` + `pg_catalog`	Zero	No	Always (it's live)	Quick inspection
IDE built-ins (pgAdmin, DBeaver)	Already installed	Partly	Snapshot, manual re-run	One-off look
Manual diagramming (draw.io, dbdiagram.io)	Short	Yes	Drifts (you maintain it)	Designing a new schema
Migrations → DDL (Prisma, Rails)	Medium	No	Re-run on change	Documenting from code
Live connection string (dbdiagramr)	None (paste URL)	Yes	Regenerate in 10 seconds	Understanding a real DB

1. psql and pg_catalog: the baseline

The fastest text-only view is psql. \dt lists all tables, \d table_name shows one table's structure including its foreign keys. To see every relationship in one shot, query information_schema directly:

SELECT tc.table_name,
       kcu.column_name,
       ccu.table_name AS foreign_table_name,
       ccu.column_name AS foreign_column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
  ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
  AND tc.table_schema = 'public';

Precise and always available. But it's a list, not a picture. Past a dozen tables you're reconstructing the graph in your head, which is exactly what visualization is supposed to remove.

2. IDE built-ins: pgAdmin, DBeaver, DataGrip

If you already have a GUI client, it probably ships with an ER diagram generator:

pgAdmin 4: right-click the database → ERD For Database. Free, already installed. Auto-layout struggles past a few dozen tables, and it regenerates by hand.
DBeaver (Community is enough): open the ER Diagram tab. Genuinely free, cross-platform, exports PNG/SVG.
DataGrip: Diagrams → Show Visualization. The best-feeling interactive diagram of the three; paid, single-user.

The honest limitation they all share: any IDE-based diagram is a snapshot. Nothing to share but an exported image, and it drifts the moment someone runs a migration.

3. Manual diagramming: draw.io, dbdiagram.io, DrawSQL

The classic approach, and great for designing a schema you haven't built yet. dbdiagram.io and DrawSQL are excellent editors. You write DBML or drag tables, and get a clean diagram you can export, share, and version.

The catch is drift. The diagram is a hand-made copy of the schema at one moment in time. The day someone adds a column or a foreign key, the diagram is wrong. A wrong diagram is worse than none, because people trust it. Building it from scratch takes 30 minutes to an hour, and it's stale the moment a migration lands.

Use these when you're designing. They struggle to document a real schema over time.

4. Generate from your migrations

If your schema lives in migration files (Prisma, Drizzle, Rails, Flyway), you can derive the structure from code instead of a live connection:

# Dump structure only, never row data
pg_dump --schema-only mydb > schema.sql

Then feed the DDL to any SQL-to-diagram tool. This is the right path when you can't or don't want to expose credentials. The trade-off: it documents the migrations, not necessarily what's actually deployed. Regenerating on every change is automation you have to build and maintain.

5. Paste a live connection string: the "always current in 10 seconds" option

The approach that solves both accuracy and effort: point a tool at the real database and let it introspect the schema itself. No schema code, no hand-arranging, nothing to keep in sync. The diagram is what's in your database right now.

That's exactly what dbdiagramr does. You paste a PostgreSQL connection string into it and it:

Connects and reads the schema, structure only, never your row data
Queries information_schema for tables, columns, primary keys, and foreign keys
Renders an interactive ER diagram you can pan, zoom, drag tables around, and hover over to trace relationships
Exports as SVG or PNG

Because it introspects the live database, there's no drift to manage. Change a migration, paste the same string again, and you have an up-to-date diagram in under 10 seconds. Your connection string is never stored. It's introspected and discarded immediately.

Not sure what an ER diagram even looks like yet? The schema library has live diagrams of the Supabase auth, NextAuth.js, Laravel, and Django schemas you can pan and zoom before you connect your own database.

Why you should care about "stays current"

Every method above the last one shares the same failure mode: the diagram is a snapshot, and keeping it current is your problem. Walk into any team that's been around a while and you'll find a "schema diagram" in a wiki from eight months ago. A wrong diagram is worse than none. It's confidently wrong.

The test that settles it: how much work does it take to make this picture true again? If the answer is "re-export from my IDE" or "drag the boxes by hand one more time," the humans will stop doing it and the diagram will lie to you.

FAQ

What's the easiest way to generate an ER diagram from a Postgres database?
If you have a GUI client open, it's a built-in feature. pgAdmin's ERD For Database, DBeaver's ER Diagram tab, or DataGrip's visualization all generate one in a couple of clicks. For a shareable diagram that matches your database as it is right now, a live-introspection tool is fastest because there's nothing to maintain.

Can I create a Postgres ERD without connecting to the live database?
Yes. Run pg_dump --schema-only and feed the DDL to a SQL-to-diagram tool, or parse your migration files. That's the safer path when you can't or don't want to expose production credentials.

How do I keep a schema diagram up to date?
Manual tools require manual regeneration, so in practice they drift. The reliable fix is introspection: regenerate straight from the live database (a paste of the connection string) or wire documentation generation into CI.

Does pgAdmin make ER diagrams?
Yes. pgAdmin 4 includes an ERD tool. Right-click the database → ERD For Database, or Tools → ERD Tool. Free and built in, though the auto-layout is best on small-to-medium schemas.

How to choose

Just want a quick look? psql or your IDE's built-in diagram. Fast, local, gone tomorrow, which is fine.
Designing a new schema? draw.io, dbdiagram.io, or DrawSQL are the right tools for the job.
Need to understand a database that already exists, or document one that keeps changing? Introspect the live schema. That's the perspective that actually survives contact with real databases.

Try It

Live: https://dbdiagramr.space

GitHub: https://github.com/VarunKvK/dbdiagramr

If this is useful to you, a GitHub star helps a solo dev keep building in public. I got tired of hand-drawing diagrams that went stale. Figured others did too.

I Swapped My Hand-Rolled SVG ER Diagram for React Flow + dagre . Here's What It Cost and What It Won

Varun Krishnan — Thu, 13 Aug 2026 12:00:00 +0000

Where the story starts

I built dbdiagramr paste a PostgreSQL connection string, get an interactive ER diagram in under 10 seconds. The first version rendered everything as pure SVG I generated by hand. No canvas, no diagram library. That was a deliberate choice, and it worked.

But as I pushed it from "a demo" to "a product" with a schema library and homepage previews, the hand-rolled renderer started fighting me. So I swapped the rendering engine for React Flow v12 + dagre. This is that migration what broke, what I chose, and what the trade-offs actually look like in production.

The goal

Interactive diagrams on the homepage demo and every /schema/[slug] detail page
Hover a table → unrelated tables dim to 15% opacity so you can trace foreign-key relationships
The same diagram engine for static (SSG) pages and the client-side interactive canvas
PNG + SVG export that matches what's on screen
Keep pages fully static-server-rendered with a client hydration layer on top

What the first version did (and where it strained)

The MVP rendered a static grid with straight-line connectors. It was:

Exportable for free - SVG is the document, serialize and you're done
Zero dependencies - one pure function, schema in → SVG string out
Easy to reason about - four TypeScript types underpin the whole app

The first pain was foreign-key routing. A clean diagram won't draw a line from table A to table B if it slices through three unrelated tables. My first pass was a four-way conditional that picked which edge to exit from based on relative position (above/below/left/right). It worked for small schemas and got fiddly as schemas grew. I already knew I'd revisit it.

The real push, though, was interactivity and maintainability. To get hover-to-trace, drag, pan, zoom, and the relationship tracing, I was going to bolt a lot of custom logic onto raw SVG. React Flow already solves that nodes, edges, viewport, minimap, controls and it's MIT licensed.

Why dagre (and not the obvious alternative)

When you need a layout engine inside a diagram tool, the first name everyone mentions is ELK (via elkjs). I seriously considered it:

Great hierarchical layouts out of the box
Nice output

But there's one hard blocker for dbdiagramr: it's MIT-only. ELK is licensed under EPL-2.0 (and GPL-3.0 in places). Mixing that into an MIT product means taking on a license I don't want to reason about for a small open-source tool.

So: dagre. It's:

MIT - same license as the project
Synchronous - runs in static-generation with zero async plumbing (all four schema pages are built at build time, so dagre's sync API keeps things simple)
Ships its own TypeScript types - no @types/dagre needed

That combination was worth far more than a slightly better layout. The constraint turned an easy pick into the right pick.

import dagre from "@dagrejs/dagre";

export function layoutSchema(schema: Schema): Record<string, Rect> {
  const g = new dagre.graphlib.Graph();
  g.setGraph({ nodesep: 60, ranksep: 90, marginx: 40, marginy: 40, rankdir: "LR" });

  // add each table node, sized from its columns
  for (const table of schema.tables) {
    const { width, height } = tableSize(table);
    g.setNode(table.name, { width, height });
  }

  // foreign keys → edges
  for (const table of schema.tables) {
    for (const fk of table.foreignKeys) {
      g.setEdge(table.name, fk.referencesTable);
    }
  }

  dagre.layout(g);

  const layout: Record<string, Rect> = {};
  for (const table of schema.tables) {
    const node = g.node(table.name);
    layout[table.name] = { x: node.x, y: node.y, w: node.width, h: node.height };
  }
  return layout;
}

One renderer, two outputs

The key architectural move was keeping a single layout source of truth and letting two layers read from it:

renderDiagramSVG(schema, layout) - produces the static SVG that SSG pages and the PNG export use
<SchemaDiagram schema={...} /> - a React Flow canvas that consumes the same dagre layout, so the interactive diagram matches the static one pixel-for-pixel

That one function is what guarantees the homepage, the schema library thumbnails, and the detail-page interactive canvas all agree. No drift between "what you see" and "what you export".

The interactive layer

On top of dagre's layout, the React Flow layer gives:

Hover-to-trace - on hover, unrelated tables drop to 15% opacity (related stay at 100%); edges animate so you can follow the foreign key through the diagram
Custom nodes - a TableNode with row-anchored handles: FK columns get a source handle on the right, referenced columns a target handle on the left, with PK/FK badges
Cardinality on edges - 1 and * badges rendered via an edge label layer
Viewport extras - background zoom, minimap, and a download panel exporting SVG or PNG (PNG is rasterized at 2× for crisp export)

All of it sits on dagre's layout rankdir: LR, 60px node spacing, 90px rank separation so related tables end up grouped left-to-right instead of scattered.

What a real schema looks like when you do it

The site ships a free schema library rendered this way real public schemas introspected into the exact Schema type:

Supabase auth - 7 tables, 3 foreign keys
NextAuth.js / Auth.js - 4 tables, 2 relationships
Laravel 11 default - 7 tables
Django auth - 9 tables, 9 relationships

The big one, Django (9 tables, 9 relationships), is nearly a star topology most tables reference the auth user table. dagre handles it fine; the lesson is to let a real layout engine deal with that instead of my hand-rolled routing conditional.

Honestly, what did it cost?

A static model is simpler. The pure-SVG version truly was dependency-free. React Flow pulls in more code for edge routing, viewports, and type plumbing. That's a real trade, and I don't regret making it.
License is a design constraint. The MIT-only requirement is what made dagre the right call over ELK and it was worth reasoning at the outset rather than mid-refactor.

But what it bought:

Interactive relationship tracing the pure-SVG version never had the kind of thing I'd have spent weeks hand-building on raw SVG
One layout, two outputs an identical static renderer and canvas that never drift
Export that always matches the screen SVG or 2× PNG, straight from the live view

Honest limitations (still)

PostgreSQL only - no MySQL, SQLite, or MongoDB yet
Public schema only - custom schemas aren't supported yet
Real-time sync is still not a thing - you generate, you export, you're done
dagre handles the schema sizes here fine; at hundreds of tables I'd look at force layouts (and re-graph sync)

The takeaway

If you're drawing relationships, don't hand-roll the canvas/network code when a purpose-built, MIT-licensed library exists. Let the library own the viewport and interaction; you keep the part that matters a small, typed data model and a single renderer that powers both static and interactive output. My first instinct was "I can just draw this myself." It took a week of wiring to realize the library was doing me a favor the payoff is interactivity I'd have hand-built for far longer.

Tech Stack

Next.js 14 (App Router)
TypeScript
Tailwind CSS
pg for PostgreSQL
@xyflow/react (React Flow v12) for the canvas
@dagrejs/dagre for layout (MIT)
MIT licensed, fully self-hostable

I Built a PostgreSQL Schema Visualizer With Pure TypeScript SVG - No Diagramming Library

Varun Krishnan — Sat, 01 Aug 2026 18:04:13 +0000

The Problem

I manage a few side projects with PostgreSQL databases. Every time I add a table, change a column, or refactor a relationship, I have to update my ER diagram.

I was using draw.io. It works. But it's manual. And it's tedious.

Open the file. Drag a new box. Connect the lines. Repeat for every schema change. It takes 30 minutes to an hour, it gets stale the moment someone commits a migration, and then you're back to answering "wait, what does the schema actually look like?"

A coworker asks you that question. You open pgAdmin. You click through tables. You mentally assemble the picture. It's slow and it's only in your head.

There had to be a better way.

The Solution

dbdiagramr.

Paste your PostgreSQL connection string. Get an interactive ER diagram in under 10 seconds. Pan, zoom, hover over tables to trace relationships, drag tables around. Export as SVG or PNG.

How It Works

The whole flow is four steps:

You paste your connection string
A server API introspects information_schema for tables, columns, keys
A pure TypeScript function generates an SVG diagram
You pan, zoom, and explore

No Canvas. No heavy libraries. Just SVG.

The data model is deliberately small - four types:

type Column = {
  name: string;
  type: string;
  nullable: string;
  default: string | null;
  isPrimaryKey: boolean;
};

type ForeignKey = {
  column: string;
  referencesTable: string;
  referencesColumn: string;
};

type Table = {
  name: string;
  columns: Column[];
  foreignKeys: ForeignKey[];
};

type Schema = {
  tables: Table[];
};

Every diagram is just a Schema object. Everything else is rendering.

The Introspection

The server connects to your database and reads only the structure — never your data. For each table it runs three queries in parallel against information_schema:

-- Columns
SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'public' AND table_name = $1
ORDER BY ordinal_position;

-- Primary keys
SELECT kcu.column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
WHERE tc.constraint_type = 'PRIMARY KEY'
  AND tc.table_schema = 'public'
  AND tc.table_name = $1;

-- Foreign keys
SELECT kcu.column_name,
       ccu.table_name AS foreign_table_name,
       ccu.column_name AS foreign_column_name
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
  ON ccu.constraint_name = tc.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
  AND tc.table_schema = 'public'
  AND tc.table_name = $1;

These run server-side in a single API route, get assembled into a typed Schema object, and get sent back as JSON. The client never touches the database directly.

Why SVG (and not Canvas)

I chose pure SVG for three reasons:

Accessible by default - text is text, colors are colors. No rasterization needed.
Exportable for free - SVG is the document. Serialize it and you're done.
No dependencies - the diagram generator is a pure function: schema in, SVG string out.

function generateDiagramSVG(schema: Schema): string {
  // grid layout
  // table cards → <g> elements
  // foreign keys → <line> with arrow markers
  return parts.join("\n");
}

That single function produces the whole diagram server-side or client-side. The interactive React component sits on top and layers on pan, zoom, drag, and hover highlighting roughly 400 lines.

For PNG export, I serialize the current SVG (with tight viewBox and inlined styles), draw it to a canvas, and let the browser encode it:

const svgString = serializeSvg(svgElement, positions);
const blob = new Blob([svgString], { type: "image/svg+xml;charset=utf-8" });
const img = new Image();
img.src = URL.createObjectURL(blob);
// draw to canvas, canvas.toBlob → PNG download

The Hard Part: Foreign Key Routing

The most interesting problem wasn't drawing the boxes - it was deciding where the connection lines exit each table.

A foreign key connects column A in table 1 to column B in table 2. But which edge of table 1 should the line leave from? If table 1 is above table 2, the line exits the bottom. If they're side by side, it exits the right side. If one is much taller, it gets complicated.

The naive version produced lines that crossed through unrelated tables and made the diagram unreadable.

The fix was a four-way conditional that decides based on relative position:

if (bottom <= tgt.y) {
  // source sits above target → line exits bottom, enters top
  x1 = cx; y1 = bottom;
  x2 = tCx; y2 = tTop;
} else if (pos.y >= tgt.y + tgt.h) {
  // source sits below target → line exits top, enters bottom
  x1 = cx; y1 = pos.y;
  x2 = tCx; y2 = tgt.y + tgt.h;
} else if (pos.x + pos.w <= tgt.x) {
  // source sits left of target → line exits right edge
  x1 = right; y1 = cy;
  x2 = tLeft; y2 = tCy;
} else if (pos.x >= tgt.x + tgt.w) {
  // source sits right of target → line exits left edge
  x1 = pos.x; y1 = cy;
  x2 = tRight; y2 = tCy;
}

Simple on paper. It still took a while to get right because the cases interact - and the fallback (overlapping boxes) matters more than you'd think.

Lessons Learned

A tiny data model wins. Four types. The whole app is built on them, and it keeps the mental overhead near zero.
The grid layout breaks at - 50 tables. A static grid is fine for most schemas but gets cluttered on big ones. Next step would be a force-directed layout or at least smarter clustering.
Shipping beats perfecting. I could have kept polishing the routing algorithm forever. Shipping it and getting real feedback taught me more than any extra week of tweaking.

Honest Limitations

I'll say the same thing I'd tell a friend:

PostgreSQL only. No MySQL, SQLite, or MongoDB yet.
Public schema only - custom schemas aren't supported yet.
No real-time sync. You generate, you export, you're done.
Static grid layout struggles past ~50 tables.

Tech Stack

Next.js 14 (App Router)
TypeScript
Tailwind CSS
pg for PostgreSQL
Pure SVG for diagrams
MIT licensed, fully self-hostable

The contract clause that almost cost me my entire codebase

Varun Krishnan — Sat, 06 Jun 2026 02:30:00 +0000

I almost signed it.

The project looked good. The client seemed reasonable. The money was fair. I'd been freelancing long enough to know the drill get the contract, skim it, sign it, start working.

This time, for no particular reason, I actually read it.
Buried in section 4 or maybe section 6, I don't remember exactly was a line that stopped me cold. Something about "pre-existing materials." Standard boilerplate, right? Except it wasn't.
The clause said that anything I brought into the project including tools, libraries, and code I'd written before the engagement would become the exclusive property of the client upon completion.

Let that sink in.

Every utility function I'd spent years refining. Every internal library I reused across client projects. Every tool I'd built for my own workflow. All of it. Theirs. The moment I delivered the project.

What "pre-existing materials" actually means

Most freelance contracts have an IP assignment clause. That's normal the client pays you to build something, they own what you built. Fair enough.

But "pre-existing materials" is different. It's the stuff you owned before you ever heard of this client. Your code. Your tools. Your background IP.

A well-written contract carves this out explicitly. Something like: "Contractor retains ownership of all pre-existing materials. Client receives a license to use them as incorporated into the deliverables."

A badly written or deliberately predatory contract does the opposite. It lumps everything together under one broad assignment clause and hopes you don't notice.
I noticed.

What I did

I pushed back. Told the client the clause needed to be amended before I could sign.

The response surprised me. They got defensive. Not "oh that's just boilerplate, of course we'll fix it" defensive. Like I'd caught them doing something they knew was wrong.

That told me everything I needed to know. I walked away from the project.

What to look for in any freelance contract

If you take nothing else from this, scan every contract you sign for these:

1. Pre-existing materials / background IP

Any clause that assigns ownership of things you brought to the project, not just what you built for it. Red flag if there's no
explicit carve-out retaining your ownership.

2. Perpetual non-competes

"During and after the term of this agreement" with no time limit. This means forever. A reasonable non-compete has a duration — 6 or 12 months. No duration means no end.

3. Unlimited liability

If something goes wrong — a bug, a security issue, anything — are you personally on the hook with no cap? Some contracts make you liable for damages that could exceed what you were even paid.

4. Payment at sole discretion

"Client may withhold payment for deliverables deemed unsatisfactory at Client's sole discretion." Translation: they can refuse to pay for any reason and you have no recourse.

5. Work for hire with no exceptions

Everything you create during the engagement becomes theirs. Fine for the deliverables. Not fine if it includes general tools, open source contributions, or personal projects you worked on simultaneously.

What a safe version looks like

Here's the rewrite I proposed for the pre-existing materials clause:

"Contractor retains all ownership of pre-existing materials, tools, and background technology used in the project. Client receives a perpetual, non-exclusive, royalty-free license to use such materials solely as incorporated into the deliverables. All intellectual property developed specifically for this project shall be owned by Client upon receipt of full payment."

That's it. Both parties are protected. Client gets what they paid for. You keep what you built before they ever hired you.
Most reasonable clients will accept this without argument. The ones who don't are telling you something important about how the rest of the engagement will go.

Why I built Clause

After this happened I started paying more attention to contracts. Talked to other freelancers. Turns out this isn't rare it's common.

Clients use broad boilerplate and count on developers being too busy, too eager, or too intimidated to read it carefully.

So I built a tool that does the reading for you.
Paste any contract into Clause and it flags the dangerous clauses explains what each one means in plain English, why it's risky, and suggests a fairer rewrite you can send back to the client.
It's free to use and doesn't require an account to try.

Clauseapp.space

If you've ever been burned by a contract clause or nearly missed on I'd genuinely like to hear about it in the comments.

How to Create Product GIFs for Your Landing Page (No Video Editing Required)

Varun Krishnan — Fri, 02 Jan 2026 18:24:08 +0000

The Brochure vs. The Demo

Imagine walking into an electronics store.
You see a sleek new laptop.
Do you just stare at the turned-off screen? No. You touch the trackpad. You open a window. You want to see it work.

Your landing page is that store.
But most SaaS landing pages are just... brochures.

They have beautiful, high-res, completely static screenshots. They force the user to read about the features instead of seeing the features.

And reading is hard work.

The 3-Second Rule
You have roughly 3 seconds to convince a visitor to stay on your site.

Static Image: The brain has to process the text, look at the UI, map the text to the UI, and simulate the interaction mentally. Cognitive load: High.
GIF/Video: The brain sees movement. It instantly understands "Clicking X does Y." Cognitive load: Low.
Motion is a cheat code for attention.

Why Not Just Use Video?
"Okay," you say. "I'll just embed a YouTube video."

You could. But videos are heavy. They require a click to play. They have sound (risky). They take over the experience.

GIFs are the sweet spot.

Autoplay: No click needed.
Silent: Safe for work.
Looping: Reinforces the core value proposition.
Lightweight: Loads faster than a 4K video embed.

The Problem with GIF Creation
Creating a polished product GIF used to be painful.

Record screen (OBS/Loom).
Import to Premiere/After Effects.
Add a device frame overlay.
Mask the video to fit the screen.
Add a background.
Export and pray the file size isn't 50MB.
Most developers (and even designers) don't have time for this. So they settle for static screenshots.

The Shotframe Solution: GIFs in the Browser
We added GIF support to Shotframe to solve exactly this problem. We wanted the polish of After Effects with the speed of a screenshot tool.

How it works:

Record Your Screen: Use any tool to grab a short clip of your key feature. (Keep it under 5 seconds for best results).
Drop into Shotframe: Upload your video file just like an image.

Frame It: Choose a premium device frame (iPhone, MacBook, Browser). Shotframe handles the masking automatically.

Style It: Add a custom gradient background (use BlendIt to match your brand colors!).
Export: Download a highly optimized GIF ready for your landing page.

Best Practices for Product GIFs
If you're going to use GIFs, do it right:

Keep it Short: 3-5 seconds max. Focus on ONE interaction.
Start with Action: Don't have 2 seconds of a stillness at the start. Movement should happen immediately.
High Contrast: Make sure the cursor and the button clicks are visible.
Optimization: Don't upload a 20MB GIF to your hero section. Use Shotframe’s export settings to balance quality and size.
Conclusion
Your product is dynamic. Your marketing should be too.
Stop letting your hard work sit still. Make it move.

[Try the Shotframe GIF Maker →]

How to Make Product Mockups That Don't Look Like Templates

Varun Krishnan — Thu, 01 Jan 2026 15:59:59 +0000

Stop using generic mockup backgrounds. Learn how to create custom, brand-aligned mockups (and GIFs) directly from your browser. No Figma required.

The Problem With Modern Mockups
Scroll through Dribbble, Product Hunt, or any SaaS landing page. You’ll see the same thing:

A generic MacBook or iPhone frame.
A "mesh gradient" background (usually purple or blue).
A shadow that looks slightly fake.
It’s the "Startup Starter Pack." And because everyone uses the same templates, no one stands out.

If you’ve spent weeks building a unique product, wrapping it in a generic mockup kills the vibe instantly.

Your product deserves better.

Why Context Matters (And Why Templates Fail)
A mockup's job isn't just to frame your screenshot. Its job is to extend your brand.

When you use a random gradient template, you are clashing with your product's actual design.

The Pro Move: Your background colors should be extracted from the product screenshot itself.
The Result: Perfect color harmony. The background feels like an extension of the UI, not a wrapper.

Method 1: The "Figma Workflow" (The Hard Way)
You can do this manually, of course.

Take a screenshot.
Open Figma.
Import screenshot.
Use the Eyedropper tool to pick 3-4 dominant colors.
Create a rectangle layer behind the image.
Apply a linear or radial gradient using those colors.
Add a device frame (search community files for a mockup).
Add drop shadows manually.
Export.
Time: ~15-20 minutes per image.
Result: Good, but slow.

Method 2: The Shotframe Workflow (The Fast Way)
We built Shotframe to automate the "Pro Move."

Step 1: Upload Your Screenshot
Drop your image into the browser. No login needed.

Step 2: Auto-Match the Background
Instead of picking a random color, use a tool like BlendIt to generate a gradient directly from your screenshot. Upload that gradient as your background in Shotframe.

Now your background matches your UI perfectly.

Step 3: Choose Your Device
Select from premium device frames (Safari Dark, iPhone 15, Chrome Light). It wraps your screenshot automatically with perfect shadows.

Step 4: Go Beyond Static (New Feature)
Static images are fine. Motion is better.

Shotframe now lets you export as GIF.

Show a scrolling capture.
Show a UI interaction.
Show a workflow.
This turns a "picture of an app" into a "demo of an app."

Why GIFs Convert Better Than Images
On a landing page, you have about 3 seconds to explain what your tool does.

Screenshot: The user has to read the UI to understand it.
GIF: The user sees the UI working.
It builds trust. It proves the software is real. It catches the eye.

Creating Your First Custom Mockup
Go to Shotframe.xyz.
Drop your image.
Tweak the background (or upload your custom BlendIt gradient).
Hit Export.
Stop letting generic mockups lower your product's value. Make it look as premium as the code behind it.

[Create a Free Mockup Now →]

How to Create a Gradient from Any Photo (Step-by-Step)

Varun Krishnan — Wed, 31 Dec 2025 19:40:58 +0000

Learn how to extract colors from any photo and turn them into beautiful gradients. Stop guessing hex codes—let your photos pick the perfect palette.

Stop Guessing Hex Codes. Let Your Photos Decide.
Every designer has been here:

Open a gradient generator. Pick random colors. Hate it. Repeat 47 times. Settle for something "fine."

There's a better way.

Instead of inventing colors from scratch, extract them from photos you already love. Sunsets, coffee cups, product shots—they all contain palettes that already work together.

Why? Because nature figured out color harmony millions of years ago. We're just borrowing it.

This guide shows you how to turn any photo into a usable gradient in under 60 seconds.

Why Photos Make Better Palettes
Most gradient generators give you "trending" palettes. The problem? Everyone uses the same ones.

That's why every SaaS landing page has the same purple-blue mesh gradient.

Photos solve this:

Colors Already Harmonize

Colors in a photo exist together naturally. A sunset has warm oranges, soft pinks, and deep purples—all in perfect balance. You didn't pick them. Light did.

"Nature Is Never Wrong"

An old design principle. Flowers, landscapes, street scenes—colors that appear together in real life just work. No color theory degree required.

Unique to Your Brand

If you pull colors from YOUR product shot or YOUR office photo, the gradient is instantly tied to your brand. Not a trending palette. Yours.

Step-by-Step: Photo to Gradient
Here's the simple workflow:

Step 1: Choose Your Photo

Pick something with colors you like:

Product screenshot (brand-aligned)
Landscape (natural, calming)
Street photography (urban, moody)
Even a coffee cup on your desk
The best photos have a clear color mood. Avoid images with too many competing colors.

Step 2: Upload to a Color Extraction Tool

Drop your image into BlendIt (or similar tool).

It automatically detects the dominant colors and arranges them into a gradient.

No eyedropper. No manual picking. Done in seconds.

Step 3: Adjust If Needed

Sometimes the auto-pick isn't perfect. Most tools let you:

Swap colors
Adjust positions
Change gradient style (mesh, linear, radial)
Tweak until it feels right.

Step 4: Add Texture (Optional)

Flat gradients can look sterile. Adding subtle grain or noise gives depth and a premium feel.

This is popular in modern SaaS and Web3 design.

Step 5: Export

Download as PNG for landing pages and social media.

Or copy the CSS for direct use in code.

Done. 60 seconds. No guessing.

Use Cases
Where can you use photo-extracted gradients?

Landing Page Backgrounds

Hero sections need something more interesting than solid color but less busy than photos. Gradients from your product colors = perfect middle ground.

Social Media Graphics

Instagram posts, LinkedIn carousels, Twitter headers. Matching gradients make your content look cohesive.

Presentation Slides

Pitch decks and internal presentations. Stand out from the default PowerPoint templates.

Device Wallpapers

Personal touch for your phone or desktop.

Mockup Backgrounds

When showcasing your product in mockups, use a gradient from the product itself. Everything matches automatically.

Tips for Best Results
Use Photos with Clear Color Themes

A photo of a sunset works great. A photo of a busy street market? Too many colors competing.

Product Shots = Brand Alignment

Pull colors from your actual product screenshot. Your gradient will match your brand without any extra effort.

Landscapes = Natural Vibes

Mountains, oceans, forests. These give calm, organic palettes.

Experiment with Unexpected Sources

Coffee. Book covers. Album art. Some of the best gradients come from random everyday photos.

The Lazy Designer's Secret
Here's the truth:

Great color choices aren't about talent. They're about sources.

Designers who seem to have "good taste" often just steal from better sources—nature, photography, real life.

Now you can too.

Stop staring at color pickers. Stop cycling through trending palettes.

Take a photo. Extract the colors. Move on with your life.

Try It Yourself
BlendIt makes this workflow instant:

Drop any photo
Colors extracted automatically
Gradient generated with grain texture
Export PNG or copy CSS
Free to use. No account needed.

[Try BlendIt →]

The 48-Hour Button: Fighting Supabase, Google Auth, and "Scope Creep"

Varun Krishnan — Fri, 28 Nov 2025 20:19:28 +0000

I just spent 48 hours building a feature the user will never notice.
It wasn't a complex algorithm. It wasn't a 3D animation.

It was a "Sign in with Google" button.

For the past two days, the Direct Google Sheets integration—my most requested feature—was dead on arrival.

Here is the technical breakdown of why "simple" integrations are rarely simple, and how I solved the Supabase Scope conflict.

The Invisible Villain:

Supabase vs. Google Scopes
The goal was simple:

User logs into SpeakSheet.
User clicks "Export to Google Sheets."
My app writes the data to their Drive.

I am using Supabase for authentication. It handles the login flow perfectly. But when I tried to push data to the Google Sheets API, I got the same error loop:
403: Insufficient Permission

I debugged for hours. I checked the Google Cloud Console. I checked the API keys. Everything looked green.

The Realization
The issue wasn't the API; it was the Auth Token.
By default, Supabase Auth requests basic scopes: email and profile. It does not request spreadsheets (write access).

The token I held verified who the user was, but it didn't have permission to touch their files.

The Fix: Decoupling the Auth
I tried to force the scope into the initial login, but it created a messy user experience (asking for full Drive access just to sign up?).

I realized I had to change the workflow.

The New Flow:

Login: User signs in via Supabase (Standard Email/Profile scope).
App Access: User builds their prompt and generates the schema.
Integration: When they click "Export to Google Sheets," I trigger a secondary re-authentication.
This specific step asks only for the Sheets permission. It separates "Identity" from "Capability." It’s cleaner, safer, and it finally works.

From "Text" to "Logic"
Once the gate was open, I had to ensure the payload was correct.

This is the difference between ChatGPT and SpeakSheet.
If you ask a standard LLM for a "Budget Tracker," it gives you a text explanation.
I need to give you working cells.

My system prompt enforces a strict JSON schema. It flags specific fields as Formula:

{"formulaLabel":"Sum", "formula":"("=SUM(C:C))"}

Before: The API treated formulas as text strings.
Now: The API recognizes the = operator and parses logic, including complex IF statements.

What’s Next? (The boring part)
The engine is running. The integration is live.
Now, I have to build the toll booth.

I am implementing the Pricing page next.
I have chosen LemonSqueezy as my merchant of record.

Why? Because Stripe is currently not onboarding new businesses in India.
The Upside: LemonSqueezy handles the tax compliance, which lets me focus on the code.

The MVP is 90% complete.
Next update: The Mobile Responsiveness fix.

"Is this just a wrapper?" (How a Reddit Comment Changed My Roadmap)

Varun Krishnan — Sun, 23 Nov 2025 10:46:13 +0000

I launched the MVP of SpeakSheet on Reddit this week.

The concept is simple: You type a prompt, and my app generates a structured Excel file using Gemini.

The post got 2,400 views. Most feedback was standard. But one comment stopped me cold.

Is it not just a system prompt for Gemini? It is not a product... users still have to prompt. You could chat with Gemini on Google Sheets all day long and it is free.

My initial reaction was defensive.
I wrote the NextJS frontend. I set up the Supabase backend. I wrote the complex system prompts that enforce schema validation so the JSON doesn't break. Of course it's a product!

But after the sting faded, I realized he was right.
And he was also wrong.

The "Wrapper" Fallacy
Developers (including me) obsess over the tech stack. We think "value" means proprietary algorithms.

But to a user who doesn't know what an API key is, raw technology is useless.

They don't know how to write a system prompt to enforce column structures.
They don't know how to parse a file upload to extract context.
They don't want to "chat" with a spreadsheet; they want the spreadsheet to exist.
My value isn't the AI model. My value is the packaging.

SpeakSheet wraps the chaos of an LLM into a predictable, one-click interface. That is the product.

The Pivot: Listening to the Haters
The most interesting part of the comment was this line:

"You could chat with Gemini on Google Sheets all day long."

I realized I had missed a massive use case.
Right now, SpeakSheet generates a downloadable .xlsx file. But many users live in the browser. They don't want to download, open, and upload.

Because of that "hater," I am shifting my roadmap.

I am now researching Google Sheets Integration via OAuth 2.0.
The goal: A user types a prompt in SpeakSheet, and it pushes the data directly into their live Google Sheet. No downloads. No file management.

Building the Integration (The Plan)
I haven't built this yet. I am currently studying the Google Workspace API documentation.
The plan is:

Authenticate the user via OAuth 2.0.
Generate the schema via Gemini (as I do now).
Push the structured data into a new Sheet via the API.

Conclusion
If you are building a Micro-SaaS, do not fear the "Wrapper" accusation.
Power users will always say they can do it themselves. They are not your customers.

Your customers are the people who gladly pay to skip the learning curve.

And sometimes, your harshest critics give you your best feature ideas.

My Code Worked. Excel’s "Protected View" Killed It.

Varun Krishnan — Sat, 22 Nov 2025 12:07:46 +0000

I am building a Micro-SaaS called SpeakSheet. The premise is simple: You speak (or type) a prompt, and it generates a structured Excel file.

The stack is solid: NextJS, Tailwind, Supabase, and Gemini on the backend.

This week, I tackled the hardest part of the MVP: Formulas.

Teaching an LLM to understand "Profit Margin" is tricky. It knows the math, but it doesn't know the context. After hours of tweaking the JSON schema and refining the prompt, I finally got a green light in the console.

The logic was perfect. The schema was validated. I downloaded the generated file to test it.

Profit Margin: 0.

I stared at the screen. I felt that specific mix of confusion and anger that only developers know. I checked the backend logs—the calculation was correct. I checked the cell data—the formula was there.

But the cell displayed 0.

I spent an hour debugging a bug that didn't exist.

The Invisible Villain
Then, I looked at the top of the Excel window. A thin yellow bar:

Protected View: Be careful—files from the Internet can contain viruses.

Because my software generated the file programmatically, Excel didn't trust it.

It blocked the execution.
It suppressed the formula results.
It made my product look broken.
This is the reality of building Micro-SaaS. You spend 20% of your time writing logic in NextJS, and 80% of your time fighting edge cases in the tools your customers actually use.

I realized that for a user with low Excel literacy (my target audience), this is a dealbreaker. They won't click "Enable Editing." They will just churn.

I had to refactor the user journey to account for a security feature I have no control over.

The Design Pivot (feat. Gemini 3.0)
Once the logic was fixed, I looked at the UI. It was functional, but it looked like a Bootstrap template from 2015.

I am a developer, not a designer. Usually, this is where I stall.

I decided to test Gemini 3.0 Flash. I gave it a simple instruction: Design a modern, clean landing page for a SaaS that converts text to Excel.

I expected the usual generic AI slop.
Instead, it one-shot a layout that actually looked... premium. It understood whitespace. It utilized the ShadCN components correctly.

It saved me two days of CSS wrestling.

The Lesson
Building SpeakSheet has taught me that code is only half the product.

Your logic can be perfect, but if Excel's UI hides it, you failed.
Your backend can be robust, but if the frontend looks cheap, you failed.
I am building this in public to show the messy reality of shipping a product.

Follow me here for the next update.
@NotVarunKV

Watch Demo of the working here:
Demo Working

DEV Community: Varun Krishnan

Supabase Auth Schema Explained: Users, Identities, Sessions

The short version

Why an auth schema at all

The four tables that matter

How they relate (the joins you'll actually write)

What's usually NOT your business

Practical tips

FAQ

Try It

PostgreSQL Connection String: Supabase, Neon, Railway

The short version

Anatomy of a connection string

Supabase: three strings for one database

Neon: pooled vs direct

Railway: the plain standard

All the formats in one table

Gotchas that will actually bite you

FAQ

Try It

How to Visualize a PostgreSQL Schema: 5 Ways Compared

The short version

The five ways at a glance

1. psql and pg_catalog: the baseline

2. IDE built-ins: pgAdmin, DBeaver, DataGrip

3. Manual diagramming: draw.io, dbdiagram.io, DrawSQL

4. Generate from your migrations

5. Paste a live connection string: the "always current in 10 seconds" option

Why you should care about "stays current"

FAQ

How to choose

Try It

I Swapped My Hand-Rolled SVG ER Diagram for React Flow + dagre . Here's What It Cost and What It Won

Where the story starts

The goal

What the first version did (and where it strained)

Why dagre (and not the obvious alternative)

One renderer, two outputs

The interactive layer

What a real schema looks like when you do it

Honestly, what did it cost?

Honest limitations (still)

The takeaway

Tech Stack

I Built a PostgreSQL Schema Visualizer With Pure TypeScript SVG - No Diagramming Library

The Problem

The Solution

How It Works

The Introspection

Why SVG (and not Canvas)

The Hard Part: Foreign Key Routing

Lessons Learned

Honest Limitations

Tech Stack

The contract clause that almost cost me my entire codebase

What "pre-existing materials" actually means

What I did

What to look for in any freelance contract

What a safe version looks like

Why I built Clause

How to Create Product GIFs for Your Landing Page (No Video Editing Required)

How to Make Product Mockups That Don't Look Like Templates

How to Create a Gradient from Any Photo (Step-by-Step)

The 48-Hour Button: Fighting Supabase, Google Auth, and "Scope Creep"

"Is this just a wrapper?" (How a Reddit Comment Changed My Roadmap)

My Code Worked. Excel’s "Protected View" Killed It.

Why an `auth` schema at all