Agentic AI systems violate the implicit assumptions of database design • Hacker News Board

Re: Agentic AI systems violate the implicit assumptions of database design

#51

Post by jimlawruk » Sun, Apr 26, 2026, 6:07 PM UTC

aleda145 wrote: post #33

phillipcarter wrote: post #26

Earlier quoted context omitted.

I think the best db schema I had the displeasure of working with was one where it was a requirement that every table and column name NOT have vowels, except for the few that could, and "the few that could" were governed entirely by a spreadsheet owned by the DB admin. And so you got tables like LANDMRK and columns like RCR_RCRDR.

Oh my. What could possibly be the justification for this?

I work with an Oracle database like this. In the old days, there was a 30 character limit on column names, so you end up with conventions like no vowels. The limit no longer exists today, but the DBA continues to enforce the limit on new columns.

Re: Agentic AI systems violate the implicit assumptions of database design

#52

Post by stavros » Sun, Apr 26, 2026, 6:09 PM UTC

I'm exasperated whenever I read articles like this. Anyone who underscores the difference between humans and agents by saying "[agents] write based on their current understanding of the task, which may be wrong" is clearly working with a different species of human than the one I've worked with.

Re: Agentic AI systems violate the implicit assumptions of database design

#53

Post by DaiPlusPlus » Sun, Apr 26, 2026, 6:10 PM UTC

hasyimibhar wrote: post #49

gib444 wrote: post #15

Earlier 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…

> Claude is pretty good at designing data models in my experience

Yesterday, Claude decided to go with nvarchar(100) for an IP address column instead of varbinary(16), and thinks RBAR triggers are just-as-good as temporal tables.

So, no. Claude is not good at designing data models in my experience.

Re: Agentic AI systems violate the implicit assumptions of database design

#54

Post by hasyimibhar » Sun, Apr 26, 2026, 6:12 PM UTC

I'm not sure why you are giving your agents write access to query your OLTP database, let alone write to it. The pattern that I use at work is:

- Read access through OLAP, not OLTP. You just need to setup a near real-time replication between your OLTP and OLAP.

- Write access through API, just like your application. You can add fancy things like approval layer, e.g. you agent cannot "ban_user(id)", but it can "request_to_ban_user(id)", and the action only happens once you approve it.

Re: Agentic AI systems violate the implicit assumptions of database design

#55

Post by mamcx » Sun, Apr 26, 2026, 6:14 PM UTC

aleda145 wrote: post #11

I totally agree on investing in a sane data model upfront. So many production systems have schemas that only made sense to the engineer that created them. I would be delighted if I can read a schema and understand what a column means without having to dig through a bunch of migration PRs. I recently encountered `is_as BOOL` in an important table. After way too much invested time we found out it meant "is active servi…

I integrate with many ERPs and this is the bane of my existence.

One of the worst has field names like `ft_0001...N` and table names like `UNCC_00001...N`, all in `text` fields (even numbers!), zero FK, almost no indexes and what are views?

The other has this funny field that is a blob that need decoding using a specific FreePascal version. The field? Where is the price of the product.

Other has, in the same column, mix of how handling "," or "." for numbers and I need to check the digital places to deduce which.

FUN.

P.D: I normalize all this Erps into my own schema and has get praise for things like, my product table is called products.

Re: Agentic AI systems violate the implicit assumptions of database design

#56

Post by brunkerhart » Sun, Apr 26, 2026, 6:15 PM UTC

Databricks introduced Lakebase exactly for this purpose. Lakebase supports branching that makes querying, schema evolution and writes cheap. Each agent can run its own branch without affecting production data.

Re: Agentic AI systems violate the implicit assumptions of database design

#57

Post by setr » Sun, Apr 26, 2026, 6:21 PM UTC

> The contract goes something like this: the caller is a human-authored application, running deterministic code, issuing predictable queries, reviewed by a developer before deployment. Writes are intentional. Connections are brief. When something goes wrong, a human notices. The database can be dumb and fast because the application layer is smart and careful.

This assumption is that of a non-DBA who happened to get a hold of a database.

When you have sufficient users, your expected set of queries is a complete shit show. Some will be efficient, many will be poorly tested and psychotic, and indistinguishable from a non-deterministic LLM.

Also who said humans can’t query the database directly in prod? If not direct sql access, business users have the next best thing with custom reports and such. And they will very much ask for ridiculous amounts of computation to answer trivial questions.

It was a foundational assumption of SQL that business users would directly access the database and write their own queries.

It’s why row level access and permissions exist. Use them

Re: Agentic AI systems violate the implicit assumptions of database design

#58

Post by lowsong » Sun, Apr 26, 2026, 6:33 PM UTC

> None of this requires new technology. It requires treating the database as a defensive layer that assumes the caller might be wrong, might retry, and might not be watching the results.

This is one of those takes that is so close to understanding the problem, and then drawing an insane conclusion.

The problem is that AI agents and the code they output is untrustworthy, buggy, insecure, and lacking in any of the standards the industry has developed over the last 30 years. The solution to this is "don't use AI agents", not "change the rest of the stack to accommodate garbage".

Re: Agentic AI systems violate the implicit assumptions of database design

#59

Post by coalstartprob » Sun, Apr 26, 2026, 6:35 PM UTC

bmurphy1976 wrote: post #37

_bypa wrote: post #12

Earlier quoted context omitted.

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?

The dev who ran it. The manager who allowed it. The director/VP/CTO who enabled the culture. They all have some responsibility for it.

[dead]

Re: Agentic AI systems violate the implicit assumptions of database design

#60

Post by fl4regun » Sun, Apr 26, 2026, 6:36 PM UTC

nananana9 wrote: post #17

kgeist wrote: post #10

Earlier quoted context omitted.

How do you validate that the reports are correct? What if an executive makes a wrong business decision because the LLM wrote a wrong SQL query?

The same way we've always done it - glance at it and see if the numbers look like they're within an order of magnitude of what looks reasonable.

so what if there were some numbers in the report which are in actuality, an order of magnitude or two outside of what you think is reasonable, because something was wrong, but the AI agent reports something that looks normal?