The consolidation is the interesting design decision: rather than a tool per operation, `crud_get` and `crud_delete` take a `mode`, which keeps the catalog small enough to stay in context without losing capability. The other half worth planning around is that this writes — `crud_delete` in drop mode destroys a table — so the database role you connect with is the real boundary. Pair `transaction_backup_table` with anything destructive.
A PostgreSQL server built around two jobs: working out what an unfamiliar database actually contains, and then operating on it. Schema extraction is deterministic; the explanation layer is optional and runs through a local Ollama model. It carries 27 tools spanning analysis, CRUD, schema modification, query optimisation, import and export, transactions and monitoring.
- Schema understanding first — `analyze_database` returns the full structure plus detected junction tables, implicit relationships, join suggestions, PlantUML ER, class and component diagrams and Markdown documentation; `get_table_details` does the same for one table; `render_database_diagrams` writes them out as SVG, PNG or PDF
- `explain_database` adds a business explanation and quality recommendations through a local LLM, and `get_database_info` folds table listing, service status and quick statistics into one call
- Reads that consolidate rather than multiply — `crud_query` for raw parameterised SQL, `crud_get` with a `mode` of records, count, distinct or paginate
- Writes with the same shape — `crud_insert` detects single versus batch from the payload, `crud_update` covers single, batch and column updates, `crud_delete` handles records, truncate and drop, `crud_rename` covers tables and columns
- Schema work — `crud_create_table`, `crud_create_view`, `crud_create_index`, plus `mod_column`, `mod_index`, `mod_constraint`, `mod_add_constraint` and `mod_view` for listing and dropping
- Performance tools — `query_explain` for estimated or actual plans, `query_analyze_indexes` to suggest missing indexes and find unused ones in the same call
- Data movement and search — `data_export` to CSV, JSON or SQL inserts, `data_import` with a conflict action, `data_search` with case-insensitive, case-sensitive or fuzzy matching
- `transaction_execute` runs several statements atomically with rollback, `transaction_backup_table` snapshots a table and returns the restore SQL, and `monitoring_database_stats` covers size, connections, cache hit ratio, slow queries and locks
Python 3.11 or higher, `uv`, and a PostgreSQL database. Connection settings go in a `.env` as `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER` and `DB_PASSWORD`. The AI explanation path is optional and needs an Ollama server, configured through `OLLAMA_BASE_URL` and `OLLAMA_MODEL`. Start it with `uv run postgresql_server.py`. Every operation uses parameterised queries with table and column name validation.
One command plus a key — uvx ide-memory-mcp, then supply credentials