Gripes about Datagripe
It has opinions about your schema. These are the ones it has about itself — 27 of them, rendered from roadmap.md in the repository, so this page cannot quietly disagree with the project. Nothing here is a promise, and the declined ones stay on the page because the reason something was refused is the useful part.
Gripes stop at the query text. Nothing yet complains about how a query actually turned out, only about how it was written.
Project class and attitude live in your browser's localStorage. Two machines, two personalities, and a per-project setting the server has never heard of.
The danger zone states real consequences and then does nothing. Truncate and drop are decoration until project class leaves the browser.
The app icon is a scowling cylinder drawn by hand. The mascot is real; the flat version that can animate in-app is not drawn.
Right-click anywhere it has nothing to say and the browser's own menu arrives, offering to reload the frame and save the image. Drag past the edge of a tree and the whole page selects, prose and all. Both are the moment it stops feeling like an application.
Inputs, selects and now buttons are one component, but only the sidebar goes through the button: the forms, the status bar and the object view still hand-roll theirs, and toggles and segmented controls have no component at all. Every variation is a fix that has to be made twice, and eventually is made once.
Eighteen rules, and seven of them are about grants. A rules page wants about thirty before it stops looking like a sample.
The website no longer states a count it cannot derive. The specs still do, in prose, and prose is not checked by anything.
Nothing reads an execution plan. The worst queries in the database still look completely fine in text.
Migrations are not linted. The most dangerous SQL anyone writes gets the least attention from the thing that exists to complain about SQL.
Two databases cannot be compared. You are diffing schemas in a text editor like it is 2009.
Four engines, and none of them is the one your employer makes you use.
SQLite cannot change a column's type, nullability or default here, because that needs the twelve-step table rebuild and nobody has written it.
Columns can be edited. Indexes, constraints and triggers cannot. The preview-then-apply shape is proven; the rest is just dialect SQL nobody has typed.
The domain export is a structure snapshot, not an ordered rebuild. It will not tell you how to get from the old schema to this one.
Results travel as JSON batches. Arrow would be faster and nobody has profiled the JSON to prove it is the problem.
No SSH tunnels, no cloud IAM auth, no network agent. If the database is not reachable from the server, it is not reachable.
It never comments on what came back. Four million rows dropped into a grid is a gripe, and it is silent about it.
There is no way to make it shut up entirely except switching it off, which is not the same thing and loses the dismissals.
Gripes only exist inside the app. They could exist in a pull request, which is where somebody else would have to read them.
The sidebar's pull is fast-forward only. On a server's clone holding an unpushed commit, a person in the browser is as stuck as the agent was before MCP learned to rebase, and "go to a terminal" means a machine they may not be able to reach.
Dark theme only. That is an open item, not a stylistic position, and saying so is cheaper than pretending.
No formatting rules, ever. Style filler is a formatter's job and the fastest way to get the whole thing switched off.
No telemetry, ever. It answers nothing but this machine, and that is the entire point of it.
It will not write your query. A tool whose thesis is that it reads SQL back to you critically cannot also be the thing that wrote it.
No grade, no "query health 62%". A number invites gaming and averages away the one blocker that mattered.
No ERD canvas, no DBA workflows. Drawing boxes is not the job and doing it badly is worse than not doing it.
Rules not built yet
Rule ids that are written down and not implemented. The build fails if one of these has quietly shipped and is still listed here, which is the only way a "planned" list stays true.
Nothing knows which indexes a relation has. The completion catalog does not carry them and the object describe result is not wired to the runner.
It cannot tell you that it stopped reading. Needs the server-side runner, which is being written.
A view created with `select *` is a finding the catalogue already has, and it fires in a query document but never on the view itself, which is the one place anyone would look.
Nothing reads an execution plan, so a sequential scan over forty million rows reads exactly like one over forty.
`select * from t limit 100` is the single most common legitimate query there is. Griping at it is precisely the style filler this catalogue exists to avoid.
The phase log — what shipped when, and what it cost — is the rest of that file. What has already shipped is in the release notes.