Comment by BeefWellington | Hacker News Reader

Comment by BeefWellington | Hacker News Reader

I'm just going off the abstract in my reply here.

I'd wager that any performance gains achieved by returning a database file instead of a (well-known, long-established, well-understood) resultset is going to be negated by literally the rest of the owl.

By that I mean, you then need to instrument loading the database file that is returned, applying specific local security and performance considerations that come with that choice, and then querying the normalized data within that returned file.

Could that be fast? Maybe. The best bet would be scenarios where the wire speed / bandwidth / system memory of the consuming device are very very limited. In those situations there's already an established way of handling it though: cursors.

A resultset is, for the most part, highly compressible already (barring scenarios where you're just returning blobs, which incidentally this is doing as well), so it's not clear to me this is even saving you that much in terms of the "data duplication" they're discussing.

I don't think it's talking about returning a database per se. Their contribution seems to be a new type of query that, instead of using joins to join together results from many tables into a single denormalized output "table," it actually returns multiple output "tables" whose rows you can associate together in your code. It's kind of a "normalized join," if you will.

Yeah. I'm imagining e.g. a full database schema at my disposal in the ORM layer, but with only the handful of rows relevant to the logged-in user.

Could be useful in many read-heavy scenarios, and would make a default way that skips DB fetches.

That’s kind of cool. Also related to local-first, maybe.

One thing to note is that with a row-level security implementation like Postgres you can pretty much do this already. For example, if you have a table `users` with appropriate RLS policies, `SELECT * FROM users` will only return the rows that whoever's doing the selecting is allowed to see.

AFAICT that’s limited to single table calls though.

I guess you could use to recreate the DB at the ORM level since you know the schema as well. But I still like this idea living at the database layer and not an extra layer of abstraction on top of it.

That is a valid use case, but IMHO the proper mental model for it would be not "SQL statement that returns a database" but rather "a synced partial mirror database instance", i.e. you have a local database server (likely in-memory SQLite or something) that gets synced with the master DB (perhaps even both ways) but only for a specific subset of rows.

Reply on news.ycombinator.com