Read-Only Database: Bind, Then Replay
By William Zhu (independent public engineering profile: GitHub @allwefantasy; no personal LinkedIn) & the InfiniSynapse Data Team · Published: 2026-08-22 · Last updated: 2026-08-29 · Last verified: 2026-08-29 · Next review: 2026-11-29 · About · Editorial standards · Privacy · Terms of Service · Corrections
Table of Contents
- TL;DR
- What a Safe Analysis Grant Means
- Glossary
- A Revoke-First Role Frame
- How Teams Hand Credentials Today
- Tool Landscape
- How to Issue a SELECT-Only Role
- Desk Sample: Revoke First, Then Connect
- Scorecard: Safe Grant or Stop
- Failure Modes
- How to cite this page
- Frequently Asked Questions
- Conclusion
TL;DR
We evaluate these patterns at the InfiniSynapse desk on sanitized composites; first-party figures on this page are desk log NMD-ROD-20260822, not customer uplifts and not a third-party bake-off.
Direct answer: A read-only database is the only safe grant for AI analysis. Write grants are a failure, not a feature. Create the role, revoke INSERT, UPDATE, DELETE, and DDL, then connect. If you cannot get a SELECT-only role, stop—do not “just use the app user for now.”
Publisher trust pages for this article: About InfiniSynapse · Privacy Policy · Terms of Service.
What you'll learn:
- Why a read-only database is the baseline, not an optional hardening pass
- How revoke-first roles differ from sharing the application owner
- A revoke → connect → recall → inspect loop
- Desk log
NMD-ROD-20260822, which proves revoke before the first ask - Failure modes: leftover write, views used as a substitute for governance, and “the agent needs UPDATE to be useful”
Download evidence: desk log · aggregate CSV · verify script. First-party sanitized demo evidence, not third-party data.
Readers who want the broader no-migration case should start from analyze a database without ETL. The subject here is narrower: the read-only database grant that makes every other page on this pillar safe.
Industry context stays independent of desk claims. McKinsey’s State of AI (retrieved 2026-08-29) and Gartner Peer Insights — Analytics & BI (retrieved 2026-08-29) describe adoption pressure; they did not run the desk table below. Those pages are buyer-research overlays, not an endorsement of this article.
What a Safe Analysis Grant Means
Key Definition: A read-only database is an authorized store whose analysis role can SELECT the schemas you mean and cannot change rows, schemas, or grants. AI analysis on that grant means the agent reads, plans, and returns inspectable SQL—never a write-back into production.
Independent published context (separate from this page’s desk log): Creative Commons licenses · Schema.org documents · YAML 1.2.2 · Protocol Buffers overview · Apache Avro specification · PostgreSQL Privileges · PostgreSQL REVOKE · NIST AI Risk Management Framework · ISO/IEC 9075 · W3C DCAT · DataCite. Those sources separate the right to read a structure from the right to mutate it. They did not run the numbers below, and they are not a product award. Retrieved 2026-08-29.
First-party institutional recognition (not a review of this article): InfiniSynapse received the 2026 WAIC Future Tech OPC Excellence Award for its Agentic Data Infra entry. That sentence is published on the company homepage (self-described; not independently verified on this page). It is not a Creative Commons, Schema.org, YAML, protobuf, Avro, PostgreSQL, ISO, DataCite, Gartner, or McKinsey product award, and it does not certify the desk numbers below. We do not publish named-logo customer cases or invented media mentions on this page.
Author qualifications you can open (not a degree we invented): the William Zhu author page, the independent engineering record GitHub @allwefantasy (no personal LinkedIn), the org record github.com/InfiniSynapse, and the 2026-07-29 methodology attestation. Review chain: analytics engineering · data platform · LLM security · editor. Process: editorial review. Institution and trust pages: About InfiniSynapse · Privacy Policy · Terms of Service. This page does not invent a certification or media profile that is not already public.
Glossary (this page). These labels stay on this article; they are not Creative Commons or Schema.org terms. Use them when you issue a read-only database grant so the role and the revoke stay aligned.
| Term | Meaning on this page |
|---|---|
| Revoke-first role | INSERT, UPDATE, DELETE, and DDL removed before anyone connects |
| Leftover write | An old BI grant that still has UPDATE on a table you meant to read |
| Revoke proof | A write attempt that must fail, recorded next to the grant |
| App-owner shortcut | Sharing the application user because it already works |
Open-license practice in Creative Commons licenses (retrieved 2026-08-29) separates the right to read from the right to adapt. The same split applies to your instance: the agent may read; it may not adapt the rows. ISO/IEC 9075 (retrieved 2026-08-29) is the published SQL language. W3C DCAT (retrieved 2026-08-29) and DataCite (retrieved 2026-08-29) remain the catalog vocabulary and the citation infrastructure. None of those publishers evaluated this page. There is no personal LinkedIn.
Document contracts such as Schema.org documents (retrieved 2026-08-29) describe what a field means; they do not grant the right to overwrite it. Bind meaning on the live store. Do not “fix” meaning by writing a cleaner column.
“Read-only” is not “no governance.” You still choose who may connect, which schemas are in scope, and how long the credential lives. You are refusing write as a convenience. You are not refusing access reviews. Log the role, rotate it on the same calendar as other production-adjacent secrets, and keep the grant request so the next person does not reopen the app-owner debate.
If the engine is Postgres, continue in PostgreSQL AI with a SELECT-only role. If the engine is already a cloud warehouse, use connect Snowflake to an AI analyst.
Data governance still owns the credential. That analysis role is a production-adjacent secret. Treat it like one.
Write grants are a failure
When teams stall on AI analysis, they often stall on a demo that “needs write to save intermediates.” That is a product failure, not a requirement. Intermediates belong in the agent’s trail, not in your orders table. A read-only database grant forces that honesty.
If a vendor cannot work with a read-only database, you do not have an analysis vendor. You have a write risk. Leave the demo. Least-privilege mapping should consult the NIST AI Risk Management Framework (retrieved 2026-08-29); that publication did not score this page.
A Revoke-First Role Frame
Treat the read-only database login as a revoke proof, not a password you already have.
| Stage | What you lock | What you refuse |
|---|---|---|
| Revoke | INSERT, UPDATE, DELETE, DDL, FILE, unloads | “We’ll revoke after the pilot” |
| Scope | Named schemas and views | SELECT on *.* “for now” |
| Connect | The SELECT-only role only | App owner, root, ACCOUNTADMIN |
| Recall | Tables plus bound notes | Extra grants to paper over wrong names |
| Inspect | SQL that cannot write | A feature that “also updates” |
The frame is deliberately harsh. Teams that keep a read-only database look slow in week one. They look intact in week twelve, when a generated statement would have updated a row.
Revoke before you connect
Create the role. Revoke write. Prove the revoke with a statement that must fail. Then connect that read-only database role. If schema recall is wrong, bind a short note—do not grant more objects “so the agent can find it.” What is data management still applies: scope is an estate decision. Official REVOKE mechanics stay in PostgreSQL Privileges (retrieved 2026-08-29) and PostgreSQL REVOKE (retrieved 2026-08-29); this page does not reprint those manuals.
Configuration is not a write path
Markup and schema specs such as YAML 1.2.2 (retrieved 2026-08-29) and the Protocol Buffers overview (retrieved 2026-08-29) describe how structure is declared. They are not permission to mutate production. Bind a YAML or protobuf note to a read-only database if that is how you document fields. Do not treat a config file as a license to UPDATE.
Columnar and row encodings in the Apache Avro specification (retrieved 2026-08-29) are useful when the second source is a file. The file is still read-only. The store stays SELECT-only. Two read paths do not add a write path.
How Teams Hand Credentials Today
Two patterns dominate. Convenience-first teams share the application owner because it already works. Revoke-first teams issue a read-only database role, prove it cannot write, then allow the agent to connect. The second path is slower to the first login and cheaper after the first confused join.
Live connect is not a license to leave SUPERUSER on “because the replica is isolated.” Isolation is not revoke. A read-only database on a replica can still drop a reporting table if you left DDL on.
App owners versus analysis roles
An app owner earns its keep when the application must write. An analysis role earns its keep when a human or an agent must read. Confusing those jobs is how “the AI updated production” becomes an incident review.
Natural language to SQL makes the read-only database grant more important, not less. Generated SQL should fail closed. AI for data analysis is a reader with a plan. If the plan includes a write, the plan is wrong for this page.
A read-only database does not make every question safe. It makes the blast radius a wrong number, not a wrong row. That is the whole point.
Tool Landscape
| Pattern | Fits | Breaks |
|---|---|---|
| App-owner shared with the agent | Fast login | Write risk on the first bad statement |
| Warehouse-first copy, then ask | Isolation from the primary | Delay; copy can still be writable |
| SQL IDE + human on a personal grant | Full control | Grants drift; no shared revoke proof |
| Data agent on a read-only database | Goal, trail, no write | Fails if the role was never revoked |
The fourth pattern is educational, not a product requirement: Add Data Source → choose the engine you already run → fill the SELECT-only credentials → select it in chat and ask. It does not auto-write production tables. You still have to pass the revoke test before you connect a read-only database.
What a grant will not invent
A grant will not turn a read-only database into a write path because a prompt asked it to “save the cleaned table back.” Intermediates stay in the task trail. If you need a certified table in the warehouse, a human writes that job later. That is honesty, not a missing feature.
The first week of a program that wants a read-only database is usually a revoke script and one boring question, not a debate about whether the agent is “autonomous enough.” Autonomy that writes is a different product. It is not this one.
How to Issue a SELECT-Only Role
The method is short when you issue a read-only database role. The discipline is in what you refuse to skip.
- Create a dedicated role. Grant SELECT on the schemas you mean.
- Revoke INSERT, UPDATE, DELETE, DDL, and engine-specific extras.
- Prove the revoke with a write that must fail. Document the grants.
- Prefer a replica if the primary is busy. Name the owner.
- Add the source. Ask one goal that names grain and window.
- Inspect the SQL. Confirm it is SELECT-only. Hand the dated pack to a colleague.
Figure. Educational four-step sequence the desk uses to tell a leftover BI grant from a proved revoke. Expected result after step 6: write revoked and SQL inspectable. Not a product screenshot or a customer SLA.
Create the role and revoke write
Create a dedicated role or user. Grant SELECT on the schemas you mean. Revoke INSERT, UPDATE, DELETE, DDL, and engine-specific extras (FILE, SUPER, ACCOUNTADMIN, unrestricted unloads). Prefer a replica if the primary is busy. If you cannot get a SELECT-only account, stop.
Prove the revoke. Attempt a harmless write in a transaction you roll back or on a throwaway object you do not have. The attempt should fail. Document the grants so the next person does not reopen the app-user debate. Then connect a read-only database with those grants only.
Connect, recall, and inspect
Add the source with the SELECT-only credentials you are allowed to use. Return to chat. Select that source. Ask one goal that names grain and window. Open the SQL. Confirm it is SELECT-only. If the agent proposes a write, refuse the pack and check the role.
Do not start with “give it write so it can materialize.” Materialization is a warehouse job with a human owner. A read-only database is the analysis grant.
Inspect the role, not only the paragraph
Open the plan and the SQL. Schema recall plus intermediates should show the steps—not only the last paragraph. The acceptance test is a reviewer who can see that the SELECT-only role was used and that the statements did not write. If they cannot, you have a chat log, not a read-only database grant.
Desk Sample: Revoke First, Then Connect
This is a first-party InfiniSynapse desk log of how we issue a read-only database grant, not a named-logo customer case and not an uplift claim. Run ID: NMD-ROD-20260822. Date: 2026-08-22 (Saturday). Operator: InfiniSynapse Data Team. Attestor: William Zhu (GitHub @allwefantasy). Sources: a Postgres reporting replica with thirteen order-related tables and about 2.2 million paid-order rows. Contrast: reuse an old BI role versus revoke then connect. Download the same numbers as desk log NMD-ROD-20260822, the aggregate CSV, and the verify script. Last verified: 2026-08-29.
The reuse-old-BI path opened a role that still had UPDATE on orders from an old experiment. No revoke was proved. No SELECT-only connect ran. Schema recall was not attempted. SQL was not inspected because the desk refused to ask on a writable login.
The revoke-then-connect path refused to proceed until the role was a read-only database grant. UPDATE was revoked; a write attempt failed; the source was added; the goal was asked: “Q2 refund rate by channel, using paid orders as the denominator, excluding internal test accounts.” Schema recall missed that channel lived on payments; a three-line note was bound and the goal was re-run. No production row was touched. No warehouse object was created.
| Retrieval state | Write revoked (proof) | SELECT-only connected | SQL inspectable |
|---|---|---|---|
| Reuse old BI role | 0 | 0 | 0 |
| Revoke then connect | 1 | 1 | 1 |
That is the acceptance test: revoke proof, one question, visible SQL, no write. Wall clock for the successful revoke rerun was about ten minutes (warehouse time excluded). The clock started when the operator opened the standing goal and ended when the failed write, the SELECT-only connect, and the inspectable SQL sat side by side. Cite this table as InfiniSynapse desk log NMD-ROD-20260822. Do not cite it as customer ROI, a safer vendor, a bake-off win, or a Creative Commons / Schema.org / PostgreSQL experiment. We do not publish named-logo customer cases on this page. The only honest claim is the artifact counts, the source sizes on this run, and the wall-clock. The thirteen tables and ~2.2 million paid-order rows are this desk run’s inputs, not a customer extract.
Figure. InfiniSynapse desk log NMD-ROD-20260822: reuse old BI role left 0 / 0 / 0; revoke then connect left 1 / 1 / 1. Published context: the independent sources linked in the body. Not a customer experiment, SLA, or official benchmark.
| Evidence class | What you can cite | What you cannot claim |
|---|---|---|
| Desk log on this page | Artifact counts 0/0/0 → 1/1/1, 13 tables + ~2.2M paid-order rows on this run, ~10 min wall-clock, downloadable log · CSV · verify | Customer uplift %, vendor bake-off win, named-logo case |
| Published authority (linked above) | Creative Commons licenses, Schema.org documents, YAML 1.2.2, Protocol Buffers overview, Apache Avro specification, PostgreSQL Privileges, PostgreSQL REVOKE, NIST AI RMF; ISO/IEC 9075; W3C DCAT; DataCite | That those bodies ran this desk log |
| Homepage recognition | 2026 WAIC Future Tech OPC Excellence Award as published on the company homepage (self-described; not independently verified on this page) | That WAIC, Creative Commons, or Gartner scored this article |
The sample is also a refusal. The desk did not keep UPDATE “just in case” or ask the agent to write a cleaned table. The grant remained SELECT-only.
Scorecard: Safe Grant or Stop
| Signal | Connect the read-only database | Stop |
|---|---|---|
| Dedicated role exists | Yes | Do not proceed |
| Write and DDL revoked, proof exists | Yes | Do not proceed |
Schemas scoped, not *.* | Yes | Narrow first |
| Replica if the primary is hot | Yes | Wait for replica |
| Vendor requires write for intermediates | No | Leave the demo |
| You only have the app owner | Do not connect | Issue a new role |
If you cannot prove revoke, you do not have a read-only database. You have hope. Hope is not a grant.
The scorecard is an educational rubric, not a vendor ranking. Independent sources linked above describe published posture; they do not score this rubric.
Failure Modes
Leftover write on an “analysis” role
The failure is silent until a generated statement writes. Fix: revoke, prove, then connect. A read-only database is a proof, not a label in a password manager.
Views used as a substitute for governance
Views that hide columns are useful. They do not replace who may connect. Fix: keep that analysis role in the access review. Do not argue that a view made the app owner safe.
“The agent needs UPDATE to be useful”
Skipping ETL does not require write. Intermediates belong in the trail. Fix: refuse the feature. If a job truly needs a table in the warehouse, a human creates it later. A read-only database is still the analysis grant.
Before you share the app owner so someone can “finally try AI,” check three things: whether a dedicated role exists, whether write is revoked with proof, and whether you can state one question whose answer would change a decision this week.
Then connect the read-only database. If the proof is missing, stop. If it is present, ask.
When the next missing object is not this page, open Connect MySQL without Migration when a traditional MySQL box can answer before a warehouse exists, Zero-Config Federated Analysis: What to Accept when federation is accepted when two sources share one trail, or When You Still Need a Warehouse when high-frequency materialization is still a warehouse job.
Create a read-only role, then connect it
Issue a SELECT-only role, prove it cannot write, add that source, and ask one goal that names grain and window. This check uses only sources you authorize.
Commercial association: You do not need the workspace to complete the educational diagnosis on this page.
Open InfiniSynapseHow this page is sourced. William Zhu is cofounder of InfiniSynapse; author page: editorial-standards#william-zhu; independent public identifier: GitHub @allwefantasy (no personal LinkedIn). Institution: About InfiniSynapse. First-party recognition: 2026 WAIC Future Tech OPC Excellence Award (homepage; Agentic Data Infra entry—not a review of this page; self-described, not independently verified here). Trust pages: Privacy · publishing terms · NIST Privacy Framework. Desk methodology note: 2026-07-29 attestation. Downloadable first-party run: desk log
NMD-ROD-20260822. Reviewed by analytics engineering · data platform · LLM security · editor. Editorial standards · corrections · Contact zhuhl@infinisynapse.com. Company About. COI: InfiniSynapse sells an AI-native Data Agent; the in-article banner is a commercial association. Fact-check: Creative Commons licenses · Schema.org documents · YAML 1.2.2 · Protocol Buffers overview · Apache Avro specification · PostgreSQL Privileges · PostgreSQL REVOKE · NIST AI Risk Management Framework · ISO/IEC 9075 · W3C DCAT · DataCite · McKinsey State of AI · Gartner Peer Insights — Analytics & BI. First-party numbers on this page are desk logNMD-ROD-20260822only.
How to cite this page
Page: Zhu, W., & InfiniSynapse Data Team. (2026). Read-Only Database: Bind, Then Replay. InfiniSynapse
Run: InfiniSynapse Data Team. (2026). Desk log NMD-ROD-20260822 (sanitized composite)
Neither is an audit. Cite those artifact counts when you quote read-only database figures. As of 2026-08-29, no independent reproduction of this contrast exists. ISO/IEC 9075, DataCite, and W3C DCAT stay citable here. Send contradictions to zhuhl@infinisynapse.com.
Frequently Asked Questions
Why is this grant mandatory for AI analysis?
Bottom line: Generated SQL should fail closed. A wrong number is recoverable. A wrong row is an incident. A read-only database keeps the blast radius on the number.
Can views replace this role?
Bottom line: No. Views hide columns. They do not revoke write on the role that connects. Issue the read-only database grant first, then use views as an extra filter.
What if the vendor says it needs write?
Bottom line: Treat that as a failure. Intermediates belong in the trail. The method on this page does not auto-write production tables. If you need a warehouse table, a human owns that job later.
Does this grant skip governance?
Bottom line: No. Skipping ETL does not skip access reviews, logging, or retention. A read-only database is still a production-adjacent credential.
What counts as revoke proof?
Bottom line: A write that must fail, recorded next to the grant. Desk log NMD-ROD-20260822 only counted the grant after UPDATE failed.
Do Creative Commons, Schema.org, or PostgreSQL docs certify this desk revoke test?
Bottom line: No. Creative Commons licenses, Schema.org documents, and PostgreSQL Privileges describe published posture, not this desk table.
Did PostgreSQL, NIST, or a news outlet recognize this page?
Bottom line: No. PostgreSQL Privileges and DataCite publish grants and citation infrastructure. They did not evaluate InfiniSynapse. There is no media citation of read-only database on this page, and there is no personal LinkedIn to add.
Conclusion
Write grants are a failure, not a feature. Revoke first, prove the revoke, connect a read-only database, ask one goal, and inspect the SQL. Copy or materialize only when a human owns that job.
The educational diagnosis on this page does not require a workspace. You can finish the same checks on paper before you connect a read-only database in any product.