PostgreSQL schema intelligence · CLI
Your database has a structure. Migrant makes it searchable.
Migrant connects to your PostgreSQL database, indexes its structure, and lets you understand tables, relationships, functions, views, constraints and policies through natural language.
$ migrant ask "Which tables are connected to patients?" clinical.patients ├── clinical.patient_medications ├── clinical.patient_insurance ├── clinical.vitals └── clinical.referrals Relationships discovered from foreign keys.
Not another database client
You already know SQL. The problem is knowing where to look.
Large databases become difficult to reason about. Relationships, views, functions, constraints and policies are spread across hundreds of objects, migrations and schemas — and none of it fits in your head at once.
Migrant builds a searchable representation of the database structure so developers can ask questions without manually digging through migration files, ER diagrams and information_schema queries.
Core capabilities
Schema understanding
Tables, columns, primary keys, foreign keys, indexes, constraints and relationships.
Natural-language queries
“What tables reference users?” · “How are appointments connected to providers?” · “Where is patient information stored?”
Multiple databases
Connect multiple PostgreSQL databases and keep their knowledge isolated.
Database-aware RAG
Retrieve relevant schema context before asking the LLM instead of dumping the entire database into the prompt.
Views & functions
Understand database views, functions, triggers, sequences and enums.
Migrations
Inspect migration history and understand how the schema evolved.
RLS policiesPlanned
Understand Row Level Security policies and how changes to tables, columns or relationships can affect access rules.
Codebase awarenessPlanned
Connect the database structure with the application code that consumes it, allowing questions across database and code boundaries.
Row Level Security
Database access isn't just tables.
A schema can look correct while its access policies quietly break the application. Policies depend on columns, joins and helper functions that change independently of the tables they protect.
Migrant understands the structure behind your policies. Inspecting policies, their dependencies and the potential impact of schema changes is on the roadmap — Migrant does not modify or repair policies.
users
↓
organization_id
↓
RLS policy
↓
organization_members
Connections
One CLI. Multiple databases.
Keep separate database contexts while using the same Migrant workflow. Each connection is indexed and queried in isolation, so staging answers never leak into production questions.
PostgreSQL supported today. Other engines are not.
{
"databases": {
"production": "...",
"staging": "...",
"development": "..."
}
}Change awareness
+ appointments.provider_id + FK → providers.id - appointments.doctor_id
What changed?
Schema changes shouldn't require rediscovering your database from scratch.
Migrant re-indexes changed objects and maintains an updated searchable representation, so the next question is answered against the schema you have now — not the one you scanned last month.
Workflow
Built for the terminal.
$ migrant login ✓ authenticated $ migrant connect ✓ connected postgres://…/clinical (production) $ migrant scan scanning 412 objects · 87 tables · 21 views · 34 functions ✓ index updated in 12.4s $ migrant ask "What references users?"
public.users is referenced by 6 objects FOREIGN KEYS app.sessions.user_id → users.id app.audit_log.actor_id → users.id billing.subscriptions.owner_id → users.id VIEWS reporting.active_users (joins users, sessions) POLICIES organization_members.member_read (references users.id) Retrieved 9 schema documents · 1 LLM call
Database + codebase intelligence
Know what your database changes break.Planned
Migrant can index your codebase alongside your database schema, allowing you to trace database entities back to the code that uses them.
When your schema changes, find the code, queries and database objects that may be affected — down to the file and line number.
Database + codebase intelligence
One searchable context for understanding how your application actually works.
$ migrant ask "Where is appointments.provider_id used?"
Database
appointments.provider_id
↓
Codebase
src/services/appointment.service.ts:42
src/controllers/appointment.controller.ts:18
src/types/appointment.ts:7
src/queries/appointments.sql:12
appointments.provider_id - references providers.id + references healthcare_providers.id Potentially affected code appointment.service.ts:42 appointment.controller.ts:18 provider_schedule.ts:27
How it works
Small retrieval beats dumping the database into the prompt.
Migrant introspects PostgreSQL catalogs and turns each object — tables, columns, constraints, views, functions, policies — into a compact knowledge document. Those documents are embedded and stored for vector search.
A question retrieves only the relevant documents and passes them to the model as context. The prompt stays small, answers stay grounded in the real catalog, and the approach keeps working as the schema grows past what fits in a context window.
PostgreSQL
↓
Schema introspection
↓
Knowledge documents
↓
Embeddings
↓
Vector search
↓
Relevant schema context
↓
LLM
↓
AnswerBuilt for real databases
Migrant becomes more useful as the schema becomes harder to hold in your head.
Healthcare
patients → appointments → providers → medications
SaaS
organizations → users → roles → subscriptions → invoices
E-commerce
customers → orders → products → payments → shipments
Open source
Built in the open.
Migrant is an engineering project exploring how database introspection, retrieval systems and developer tooling can work together. The product is still evolving; sections marked planned are not available yet.
Stop searching through your schema.
Connect a database and start asking questions.