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

Databases in 2025: A Year in Review

cs.cmu.edu

Post reply on HN
Print view View original

131–140 of 196 posts

Re: Databases in 2025: A Year in Review

#131

Post by quotemstr »

Miyamura80 wrote: post #5
A1aM0 wrote: post #2

Pavlo is right to be skeptical about MCP security. The entire philosophy of MCP seems to be about maximizing context availability for the model, which stands in direct opposition to the principle of Least Privilege. When you expose a database via a protocol designed for 'context', you aren't just exposing data; you're exposing the schema's complexity to an entity that handles ambiguity poorly. It feels like we're jus…

Totally agree, unfettered access to databases are dangerous There are ways to reduce injection risk since LLMs are stateless and thus you can monitor the origination and the trustworthiness of the context that enters the LLM and then decide if MCB actions that affect state will be dangerous or not We've implementeda mechanism like this based on Simon Willison's lethal trifecta framework as an MCP gateway monitoring w…

> Totally agree, unfettered access to databases are dangerous

Any decent MVCC database should be able to provide an MCP access to a mutable yet isolated snapshot of the DB though, and it doesn't strike me as crazy to let the agent play with that.

Re: Databases in 2025: A Year in Review

#133

Post by thesz »

quotemstr wrote: post #131
Miyamura80 wrote: post #5

Earlier quoted context omitted.

Totally agree, unfettered access to databases are dangerous There are ways to reduce injection risk since LLMs are stateless and thus you can monitor the origination and the trustworthiness of the context that enters the LLM and then decide if MCB actions that affect state will be dangerous or not We've implementeda mechanism like this based on Simon Willison's lethal trifecta framework as an MCP gateway monitoring w…

> Totally agree, unfettered access to databases are dangerous Any decent MVCC database should be able to provide an MCP access to a mutable yet isolated snapshot of the DB though, and it doesn't strike me as crazy to let the agent play with that .

For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, and not many databases have them. Also, a double COMMIT may propagate changes outside of agent's playbox.

Re: Databases in 2025: A Year in Review

#134

Post by quotemstr »

thesz wrote: post #133
quotemstr wrote: post #131

Earlier quoted context omitted.

> Totally agree, unfettered access to databases are dangerous Any decent MVCC database should be able to provide an MCP access to a mutable yet isolated snapshot of the DB though, and it doesn't strike me as crazy to let the agent play with that .

For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, and not many databases have them. Also, a double COMMIT may propagate changes outside of agent's playbox.

> For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database,

Correct, but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway (although you might have to factor out things like row watermarks to lookaside tables if you want to let them be branchy instead of XID being a write lock.)

You could version the index B-tree nodes too.

Re: Databases in 2025: A Year in Review

#135

Post by felipelalli »

I think it's time for a big move towards immutable databases that weren't even mentioned in this article. I've already worked with Datomic and immudb: Datomic is very good, but extremely complex and exotic, difficult learning curve to achieve perfect tuning. immudb is definitely not ready for production and starts having problems with mere hundreds of thousands of records. There's nothing too serious yet.

Re: Databases in 2025: A Year in Review

#136

Post by odie5533 »

CyberDildonics wrote: post #123
odie5533 wrote: post #13

Earlier quoted context omitted.

For as much talk as I see about SQLite, are people actually using it or does it just have good marketers?

It is fantastic software, have you ever used it?

I don't have a use case for it. I've used it a tiny bit for mocking databases in memory, but because it's not fully Postgres, I've switched entirely to TestContainers.

Re: Databases in 2025: A Year in Review

#137

Post by da02 »

cryptica wrote: post #99

It's so weird how everyone nowadays is using Postgres. It's not like end users can see your database. It's disturbing how everyone is gravitating towards the same tools. This started happening since React and kept getting worse. Software development sucks nowadays. All technical decisions about which tools to use are made by people who don't have to use the tools. There is no nuance anymore. There's a blanket solutio…

Which alternatives to PostgreSQL would you like to see get more attention?

Re: Databases in 2025: A Year in Review

#138

Post by felipelalli »

beders wrote: post #21

While the author mentions that he just doesn't have the time to look at all the databases, none of the reviews of the last few years mention immutable and/or bi-temporal databases. Which looks more like a blind spot to me honestly. This category of databases is just fantastic for industries like fintech. Two candidates are sticking out. https://xtdb.com/blog/launching-xtdb-v2 (2025) https://blog.datomic.com/2023/04/d…

FYI I made a comment very similar to yours, before reading yours. I'll put it here for reference. https://news.ycombinator.com/item?id=46503181

Re: Databases in 2025: A Year in Review

#140

Post by thesz »

quotemstr wrote: post #134
thesz wrote: post #133

Earlier quoted context omitted.

For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, and not many databases have them. Also, a double COMMIT may propagate changes outside of agent's playbox.

> For this database has to have nested transactions, where COMMITs do propagate up one level and not to the actual database, Correct, but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway (although you might have to factor out things like row watermarks to lookaside tables if you want to let them be branchy instead of XID being a write lock.) You could version the inde…

  > but nested transaction support doesn't seem that much of a reach if you're an MVCC-style system anyway
You are talking about code that have to be written and tested.

Also, do not forget about double COMMIT, intentional or not.

Post reply on HN