How it is built, and why
20 specifications, rendered from docs/spec in the repository. Each one records what a subsystem does, what it deliberately does not, and which alternatives were rejected and for what reason — that last part is usually the useful bit and it is almost never in the code.
This is an engineering document. Specs are written for people building DataGripe: they record what a subsystem does and why the alternatives were rejected, and some of them describe things that are not built yet. If you are using DataGripe, the documentation is the place to be — it is maintained for you and this is not.
Current
Access report
Answer one question for a whole datasource at once: what can each role actually do? Not what was granted — what is reachable, once PUBLIC, role inheritance, ownership, schema USAGE, SECURITY DEFINER and view ownership have all been resolved.
Database adapters
MySQL, SQLite, and Redis sit beside PostgreSQL behind the adapter boundary.
Authentication, authorization, and hardening
Every request is authenticated and workspace-authorized; credentials and targets are protected by session, CSRF, SSRF, and rate-limit controls that match the self-hosted deployment model.
Connection sources
Connections are managed like DataGrip data sources: first-class, named, testable objects the user adds and organizes — not a deployment detail.
Connections and schema explorer
A user can save a PostgreSQL connection with an encrypted password, test it, and lazily browse schemas, tables, views, and columns — without the password ever leaving server memory or appearing in any client payload.
Datasource paths
A database does not arrive out of nowhere.
Domains
A schema is a flat pile of objects; a database is not.
Editor workspace
An IDE-grade editor shell in the browser: many SQL documents open at once, tabs that move between groups, horizontal/vertical splits, and no lost changes across tab switches, splits, reloads, or browser crashes.
Git datasources
docs/spec/datasource-paths.md got DataGripe as far as seeing the checkout: you name a directory, it becomes a sidebar section, files open and save back.
Markdown documents
docs/spec/datasource-paths.md shipped with a wart it named out loud: a .md opened out of a datasource path gets SQL highlighting, "and the fix is a language field on the document rather than anything here".
MCP server
Every project speaks MCP, so an agent working on the project's code can ask the project's own database questions — and read the project's own explanation of it.
Multiplayer
DataGripe is multiplayer.
Object view
The ⊞ affordance, or any structure entry in the tree's context menu, opens one object's structure as an editor tab.
Roles and permissions
Three ranks answered one question — can this person edit — and the questions people actually have are narrower and do not nest.
Query execution
Run SQL from the editor — a selection, the statement at the cursor, or a whole document — with server-enforced limits, reliable cancellation, live result streaming into a data grid, and an auditable history record for every execution.
Repository commands
A datasource that comes from a repository can bring its own directories, its own domains and its own sync target.
Table view
Double-clicking a table or view in the tree opens its rows as an editor tab and lets you work with them: browse, sort, filter, page, export, inspect and edit a large value, edit a cell, insert a row, delete a row.
Versions, updates and the account menu
Somebody running DataGripe should be able to answer three questions without leaving it: what am I running, is there anything newer, and what do I do about it.
Workspaces
The workspace IS the project: a named container with its own members, connections, shared files, history, and default target connection.
Draft
Gripes engine
DataGripe notices things about your query and your schema, and says so — accurately, specifically, and rudely.
Architecture decisions live in docs/adr, and the phase log is roadmap.md — whose second half is the roadmap page.