←back to thread

224 points mlissner | 7 comments | | HN request time: 0.581s | source | bottom
1. SteveMoody73 ◴[] No.45776387[source]
My initial thought is why query 1TB of data in a browser, maybe I'm the wrong target audience for this but it seems that it's pushing that everything has to be in a browser rather than using appropriate tools
replies(5): >>45776430 #>>45776769 #>>45776801 #>>45777955 #>>45778216 #
2. cyanydeez ◴[] No.45776430[source]
Browsers are now the write-once works everywhere target. Where java failed, many hope browsers succeed. WASM is definitely a key to that, particularly because it can be output by tools like rust, so they can also be the appropriate tools.
3. majormajor ◴[] No.45776769[source]
Why pay for RAM for servers when you can let your users deal with it? ;)

(Does not seem like a realistic scenario to me for many uses, for RAM among other resource reasons.)

4. some_guy_nobel ◴[] No.45776801[source]
The one word answer is cost.

But, if you'd like to instead read the article, you'll see that they qualify the reasoning in the first section of the article, titled, "Rethinking the Old Trade-Off: Cost, Complexity, and Access".

5. simonw ◴[] No.45777955[source]
What appropriate tool would you use for this instead?
6. shawn-butler ◴[] No.45778216[source]
I doubt they are querying 1 TB of data in the browser. DuckDB-WASM issues http range requests on behalf of client to request only the bytes required, especially handy with parquet files (columnar format) that will exclude columns you don't even need.

But the article is a little light on technical details. In some cases it might make sense to bring the entire file client-side.

replies(1): >>45780424 #
7. fragmede ◴[] No.45780424[source]
For small databases, SQLite is handy, as there are multiple ways to parse the format for clients.