Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agentic AI systems violate the implicit assumptions of database design

arpitbhayani.me

Post reply on HN
Print view View original

91–100 of 115 posts

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

#91

Post by 2ndorderthought »

jmalicki wrote: post #87
cowlby wrote: post #78

Earlier quoted context omitted.

Not everything is a SaaS. I commented this elsewhere but I picture all the business running on spreadsheets/CSVs/MS Access databases on someone's desktop. People delete these all the time by accident. They have no security, no authentication, etc. An LLM agent (with RW access to a DB), a developer, and a few days these become proper apps that SMB business would pay well for. Sure don't give an LLM agent access to PII…

At the very least you should give it a non-prod copy of the database, not direct access to the DB actively powering production right now. I've done work for a hedge fund where the DB ran directly on the manager's desktop. I worked with my local copy and sent an update script, and he had a second copy he ran on to verify. Even with humans you shouldn't be working directly against the prod DB in these cases!

There is literally no excuse. The fact that there is any resistance to this let alone from multiple people terrifies me.

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

#92

Post by tyzoid »

Pxtl wrote: post #82
sgarland wrote: post #64

Earlier quoted context omitted.

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…

So what do you do for "okay, we need to run this script that we've decided is a necessary operation". Special account? Everything go through the build server? I've been looking for tooling for "I need to do a production operation but I want it to have proper interlocks and reviews".

You can use something like flyway on top of your existing git/cicd stack. Write the query as a migration, have it reviewed using your git code review process, and merge to run the migration.

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

#93

Post by bloaf »

angra_mainyu wrote: post #81
bloaf wrote: post #24

> The API failed silently because the database connection pool was exhausted downstream. I work with a team that does stuff like this, returning a 200 and a body containing "error: I didn't do what you said because _insert error here_" The problem is that you returned OK instead of ERROR when things were not OK and there was an ERROR. Its a design that smells of teams trying to hit some kind of internal metrics by sl…

>returning a 200 and a body containing "error: I didn't do what you said because _insert error here_" I've seen this approach before, it mostly follows from using the code to signal application errors (200 + ok/error) from other kinds of errors that might arise.

HTTP error codes are divided between server (5xx) and client (4xx).

Where do these "application errors" occur if neither on a server nor a client?

I think the reality is that management sees "5xx means server error, so our team's KPI is now server error rate, the lower the better!" Then the team just stops using 500 errors as much as possible. They probably justify it with things like "well, such and such problem isn't our fault so its not really a server error." This kind of thinking is perverting the intent of 5xx messages. They are supposed to indicate any failure to handle the request that happens on the server, NOT measure whether the dev team is making a good application.

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

#94

Post by waterTanuki »

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.

dilution of responsibility isn't just dangerous, it's illegal for some industries. Aircraft manufacturers need to log and track every single bolt, panel, and fastener on a plane back to the engineer who installed it. The moment you dilute risk between people you eliminate auditability.

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

#95

Post by aforwardslash »

How is this different from "people that cant write sql should not use orms"? With code agents you can write raw sql better than most developers; and if you want, you can basically ask for the same implementation using whatever orm you want. Lastly, AI generated code is supposed to be reviewed by a human, just like code done by your colleague. Thing is, with AI, you can establish automatic review guidelines, and even ask for proper benchmarks and optimizations, at zero cost.

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

#96

Post by aforwardslash »

gib444 wrote: post #15
lateforwork wrote: post #9

There are two broad types of databases: operational and analytical. Operational databases store transactions and support day-to-day application workflows. For analysis, data is often copied into separate analytical databases (data warehouses), which are structured for efficient querying and large-scale data processing. These systems are designed to handle complex, random queries and heavy workloads. LLM agents are th…

> LLM agents are the best way to analyze data stored in these databases Why, and how?

Wide tables and rich data. Dozens to hundreds of columns, some of them a json dimension. Way easier to explore these datasets with AI

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

#97

Post by steve_adams_86 »

sroussey wrote: post #88
cowlby wrote: post #76

Earlier quoted context omitted.

That's the issue that I feel misses the forest for the trees. Relatively simple applications or thin slices exist right now, in production, in critical paths, as spreadsheets/CSVs/files on someone's desktop. That's the pent up demand I picture out there for developers. Go to any SMB out there and there's a goldmine of processes that could be improved with LLM agents with full RW access to a database. Where backups ar…

I think the Venn diagram of people letting LLMs have complete control of their database AND having good backups, will have no overlap. The people that would benefit or not the people that have backups.

This is also a good point. Details like this are why I think experienced developers are going to remain relevant for a while yet. Anticipating what can go wrong is such a huge component of what building software systems is about. LLMs can be great at it, but only with the limited context they have, and even then only somewhat coincidentally.

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

#98

Post by dwd »

mamcx wrote: post #55
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,…

I may have worked with that one. Did it have a parallel schema that mapped tables and fields with legible/customisable names, so every SQL call had to join the mapping tables to hit the required table and fetch the fields you were after?

Wrote a Windows .Net program once upon a time to convert the data from other financial CRM systems into the system I worked on. Built a data mapping tool as no customer we onboarded placed "custom" data in the same tables or fields even when using the same financial system.

I actually miss doing that kind of work, my brain seems to be wired to find it fun. Writing SQL is one thing I don't delegate to an AI or even an ORM like Doctrine.

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

#99

Post by stephenlf »

> The database can be dumb and fast because the application layer is smart and careful.

I’ve always baked important invariants directly into the database with constraints and triggers. Maybe this is because I work on internal apps, where the data is more important than the presentation. Maybe it’s from my functional programming experience and some need to make invalid states unrepresentable.

Regardless, I believe that the data layer should be the most carefully designed part of an app.

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

#100

Post by smartbit »

DaiPlusPlus wrote: post #53
hasyimibhar wrote: post #49

Earlier quoted context omitted.

> 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.

Postgres has network types https://www.postgresql.org/docs/current/datatype-net-types.h...

  inet —- allows zero bits to the right of the netmask
  cider —- does not allow
Post reply on HN