Jesus Christ. All this is true only if you let them.
It’s good idea to be defensive, design the system in a way that it can “fix” itself.
But for love of god, don’t let an LLM do everything it wants.
Agentic AI systems violate the implicit assumptions of database design
61–70 of 115 posts
Re: Agentic AI systems violate the implicit assumptions of database design
#62Giving an LLM write access is insane but I gave LLM’s read-only access to our database and it’s been a huge productivity win. Executives who wouldn’t take the time to build a report are happy to ask an AI agent to do so.
How do you prevent your customer data being used for training?
Re: Agentic AI systems violate the implicit assumptions of database design
#63At one place, the saying was that databases can handle everything except a class of sophomores learning how to use databases.
Re: Agentic AI systems violate the implicit assumptions of database design
#64Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me. NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should. F…
I’m a DBRE. I spend a good portion of my day with a shell into one or more prod databases. The schema definitions in code are scattered between ORM model definitions, Alembic migrations, and Liquibase migrations, so the only reliable way I have of understanding a schema as it exists is to view it. Plus, I am very comfortable with SQL, and the various system catalogs of both MySQL and Postgres, so it’s a ton easier to work with.
Truly sensitive customer information is encrypted, and on an isolated DB cluster that no one has regular access to. I also operate with a read-only grant, because manual writes to a prod DB is generally a terrible idea.
Re: Agentic AI systems violate the implicit assumptions of database design
#65The article describes idempotency keys and then completely misses making them the PK. The example is already using UUIDv4 as a PK, so they’re clearly not optimizing for performance. If you’re using the first 32 characters of a SHA256 hash, congratulations, store it as BINARY(8) / BYTEA - it’s even half the size of an encoded UUID, to boot.
Also, the DB will most certainly not silently ignore a unique constraint violation: it will send an error back. EDIT: unless you’re using INSERT OR IGNORE, of course.
Re: Agentic AI systems violate the implicit assumptions of database design
#66Giving an LLM write access is insane but I gave LLM’s read-only access to our database and it’s been a huge productivity win. Executives who wouldn’t take the time to build a report are happy to ask an AI agent to do so.
How do you prevent your customer data being used for training?
The same way everyone does, by not using free LLMs, but instead paying OpenAI/Microsoft/Anthropic for an enterprise subscription?
Re: Agentic AI systems violate the implicit assumptions of database design
#67Earlier quoted context omitted.
How do you prevent your customer data being used for training?
The same way everyone does, by not using free LLMs, but instead paying OpenAI/Microsoft/Anthropic for an enterprise subscription?
I thought the way is not feeding customer data to the LLM.
Re: Agentic AI systems violate the implicit assumptions of database design
#68Earlier quoted context omitted.
> LLM agents are the best way to analyze data stored in these databases Why, and how?
> Why Based on my experience with Claude, it's pretty damn good at doing data analysis, if given the right curated data models. You still need to eyeball the generated SQL to make sure it makes sense. > and how? 1. Replicate your Postgres into Snowflake/Databricks/ClickHouse/etc, or directly to Iceberg and hook it up to Snowflake/Databricks/ClickHouse/etc. 2. Give your agent read access to query it. 3. Build dimensio…
> Side note: I'm currently building a platform
Oh ok this comment is just an ad then
Re: Agentic AI systems violate the implicit assumptions of database design
#69Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me. NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should. F…
How does that even work in compliance-relevant scenarios where the audit trail shows some LLM messed with the data? Who, if anyone, is on the hook?
Whoever provided the authorization credentials to the agent is on the hook.
Re: Agentic AI systems violate the implicit assumptions of database design
#70Giving LLM agents direct, autonomous access to a real production databases with write access seems insane to me. NO ONE, agent or human, should have direct write access to production databases outside of emergency break glass scenarios. This is why we have stored routines and API layers to pre-define what writes are allowed. The facts that agents CAN autonomously write to a database does not imply that they should. F…
LLM agents are unlocking demand and supply for applications that wouldn't have been possible before due to time constraints though. There's a growing demand for single user or smaller scoped apps where giving LLM agents direct access means velocity. The failure/rollback model is much easier with these as long as we have good backup hygiene.
I think a lot of the objections to your post could be answered by reminding folks of how Microsoft Access databases tend to pop up in small businesses as well as corporate environments outside of IT departments. Yes, they're not "proper" databases but they /get business done/ and often serve as v0 before a real app can be properly conceived of.
One can easily imagine an LLM-enabled database that lets a wider audience build meat-and-potatoes line-of-business apps for small team use with minimal compliance concerns.