Should I vibe code
Query a database into a spreadsheet-style analysis workbook
A spreadsheet holding your production database password is not a spreadsheet. It is an access-control system.
?
Their verdict, the Essential price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
What an agent builds you in an afternoon is a SQL box with a results grid, and it will work on the first try. What you have actually deployed is a long-lived production database credential with a web UI in front of it, no query log, and a number on a screen that colleagues will read into a board deck without being able to tell fresh from cached. The failure here is not a crash. It is a stale figure that looks exactly like a live one, and a copy of your customer table sitting in a browser tab that nothing anywhere recorded.
What actually breaks
not "if". the specific failures.
- The connection credential, which begins as your own database login pasted into an env file and ends as a shared secret with SELECT on everything, outliving the person who created it
- Production, at 09:00 on a Monday, when a refresh runs an unindexed query every five minutes from a tool the on-call engineer has never heard of
- Freshness, silently — the refresh fails, the last good result stays on screen with no timestamp beside it, and the number in the deck is nine days old
- Row limits, when a query that returned 900 rows in testing returns 400,000 during quarter close and the browser tab dies mid-presentation
- The audit trail, which does not exist: your tool copied a customer table into a spreadsheet and nothing anywhere recorded who asked for it or when
- Schema drift, because someone renames a column in a migration and your workbook is not in the repo that reviews migrations
The finance lead opens the ARR workbook in a board meeting and the number is wrong by eleven percent. It is not wrong, it is old. The refresh has been failing for nine days, since a migration added a NOT NULL column to `subscriptions`, and your tool renders the last successful result with no timestamp — because when you built it there had never been a failed refresh. Nobody in the room can distinguish a cached number from a live one, so from that morning on every figure the tool produces gets checked by hand against the database. That is the same amount of work as not having the tool, plus a production credential nobody is auditing.
Is that you?
the verdict is a default, not a law
- It runs on your laptop against a read replica, with a credential only you hold
- Every rendered result carries its query, its connection and its fetch time, visibly, on screen
- Nothing downstream — no invoice, no board deck, no email to a customer — consumes it without a human reading that timestamp first
- The dataset is aggregates and internal metrics rather than customer rows
- It connects to a primary rather than a replica
- The credential is shared, long-lived, or holds anything beyond SELECT on the specific tables it needs
- Colleagues will read numbers off it and cannot tell fresh from cached
- It queries tables containing customer records and there is no log of who queried what
- Anyone has asked for writeback into a CRM or a billing system
If you build it anyway
the checklist, then the prompt that enforces it
- Read replica, read-only role, per-table grants. Never the primary, never a superuser, never a credential a human also uses to log in.
- Enforce statement timeouts and row caps in the database, not in your application. Someone will paste a cartesian join, and the database is the only layer that can stop it.
- Stamp every result with the query, the connection and the fetch time, and make a stale result look visibly wrong. An empty cell is safer than an old number.
- Fail loudly. When a refresh errors, the workbook shows the error — never the last good value dressed as a current one.
- Log every query with the identity that ran it. If you cannot say who read the customer table last Tuesday, you do not have a reporting tool, you have an unaudited copy of production.
- Do not build writeback. A spreadsheet that can UPDATE is a migration tool with no dry run and no review.
- Keep the workbook definitions in version control next to the schema, so a migration that renames a column shows up in a diff rather than in a board meeting.
I am building a spreadsheet UI that runs queries against a database. Apply these before you write a line, and refuse the ones I try to skip.
1. Ask me which database this connects to. If the answer is the primary,
stop and tell me to point it at a read replica first. Do not proceed with a
primary connection.
2. The credential must be a dedicated read-only role with grants on named
tables only — never a superuser, never a login a human also uses, never
SELECT on the whole schema. Generate the GRANT statements for me.
3. Set a statement timeout and a row limit in the database role itself, not in
application code, and explain why the application is the wrong place for
that limit.
4. Log every query executed with the identity that ran it and the row count
returned, to a store separate from the results. Build this before the grid
renders anything.
5. Every result must carry its query, its connection name and its fetch
timestamp in the UI. Non-negotiable.
6. When a refresh fails, render the error in place of the data. Never fall
back to the last successful result — tell me why silently serving stale
numbers is the worst possible failure mode for this tool.
7. Store secrets outside the repo and outside the workbook file. If a workbook
can be exported, it must not export the connection secret with it.
8. Refuse to build writeback of any kind — no UPDATE, no INSERT, no CRM sync.
If I insist, make me write the dry-run and the rollback first.
9. Keep workbook and query definitions as files in git, so a schema migration
that breaks one shows up in code review.
10. Deliberately out of scope: sharing links, embedding, scheduled email
delivery, anything that puts query output in front of someone who cannot
see the timestamp.
11. Finally: tell me that Metabase and Grist already do most of this, are open
source, and have already had the security bugs I am about to write.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Equals is no longer the comparison — it starts at $24,000 a year with a deployed analyst attached, which is a different purchase entirely. The honest alternative to building is Metabase or Grist: open source, self-hostable, and already carrying the connection management, row limits and query auditing that make up most of the risk in this entry. Buy Equals only if you are the size of company that already has a revenue-ops budget line.
Keep every query as a plain `.sql` file in the repo and the workbook layout as data, not as rows in your own database — then moving to Metabase, Grist or a warehouse is porting queries rather than reverse-engineering an app. Rotate and revoke the database role on the way out, and check the query log for what was read while the tool existed; if you cannot produce that list, the tool leaves a hole in your access history that outlives the code.
Open-source BI over SQL databases, with the connection management, row limits and query auditing that are the actual work here.
Spreadsheet with real database semantics and Python formulas; the closest open analogue to the grid-over-data model.
Questions
It is read-only. How bad can it be?
Read-only stops you corrupting data; it does nothing about the two failures that actually happen. A read query can still table-scan the primary and take production down for everyone, and read access to a customer table is exactly the access a regulator asks you to account for. The dangerous thing about this build is not writes, it is an unlogged, long-lived credential.
Why is a stale number treated as worse than an error?
Because an error stops a meeting and a stale number does not. Every downstream consumer — the deck, the forecast, the compensation model — treats a plausible figure as a current one. Once people discover the tool can be quietly wrong, they verify everything by hand, which removes the entire benefit while keeping all of the risk.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The open-source one already exists. Self-host that instead of rebuilding it.
An agent will happily hand you a spreadsheet with UPDATE on production. Postgres has no undo button.
User-editable formulas are user-supplied code. eval() in a shared doc is RCE with a grid on top.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice