11–19 of 19 posts
This is so weird. If you're using this library 1) your serverless and edge runtime needs to have internet access, so it can contact anyone 2) you're obviously not going to be able to efficiently write to S3 while providing guarantees, so it'll be expensive 3) you're writing in rust, so you really care about correctness and efficiency This seems like a contradiction. Why would you do this as opposed to hosting a redun…
How does it compare to https://slatedb.io/ ? Seems similar ideas, although SlateDB seems a bit more lightweight and using Parquet as primitive (even using Arrow) might mean more compute-heavy on client-side?
>SlateDB is designed for key/value (KV) online transaction processing (OLTP) workloads. It is optimized for lowish-latency, high-throughput writes. It is not optimized for analytical queries that scan large amounts of columnar data. For online analytical processing (OLAP) workloads, we recommend checking out Tonbo.
This is so weird. If you're using this library 1) your serverless and edge runtime needs to have internet access, so it can contact anyone 2) you're obviously not going to be able to efficiently write to S3 while providing guarantees, so it'll be expensive 3) you're writing in rust, so you really care about correctness and efficiency This seems like a contradiction. Why would you do this as opposed to hosting a redun…
What's shifting is workloads. More and more compute runs in short-lived sandboxes: WASM runtimes (browser, edge), Firecracker, etc. These are edge environments, but not just for web applications.
We're exploring a different architecture for these workloads: ephemeral, stateless compute with storage treated as a format rather than a service.
This also maps to how many AI agent service want per-user or per-workspace isolation at large scale, without operating millions of always-on database servers.
If you're happy running a long-lived Postgres service, Neon or Supabase are great choices.
How big is the wasm?
License does not yet exist? Hope it’s Apache 2.
This is so weird. If you're using this library 1) your serverless and edge runtime needs to have internet access, so it can contact anyone 2) you're obviously not going to be able to efficiently write to S3 while providing guarantees, so it'll be expensive 3) you're writing in rust, so you really care about correctness and efficiency This seems like a contradiction. Why would you do this as opposed to hosting a redun…
Owner of Tonbo here. This critique makes sense in a classic web-app model. What's shifting is workloads. More and more compute runs in short-lived sandboxes: WASM runtimes (browser, edge), Firecracker, etc. These are edge environments, but not just for web applications. We're exploring a different architecture for these workloads: ephemeral, stateless compute with storage treated as a format rather than a service. Th…
And you use Rust ... so you care about speed and correctness. This seems like a very wrong approach.
Earlier quoted context omitted.
Owner of Tonbo here. This critique makes sense in a classic web-app model. What's shifting is workloads. More and more compute runs in short-lived sandboxes: WASM runtimes (browser, edge), Firecracker, etc. These are edge environments, but not just for web applications. We're exploring a different architecture for these workloads: ephemeral, stateless compute with storage treated as a format rather than a service. Th…
This makes no sense. DB connections have been part of the "short-lived sandbox" since the very beginning. CGI, PHP, ... all use database connections, and that's way faster and correcter (with proper transactions) than this approach. And you use Rust ... so you care about speed and correctness. This seems like a very wrong approach.
That model worked when you had a small number of stable app servers. It becomes much harder when compute fans out into thousands or millions of short-lived sandboxes.
We're already seeing parts of the data ecosystem move away from this assumption. Projects like Iceberg and DuckDB decouple storage from long-running database services, treating data as durable formats that many ephemeral compute instances can operate on. That's the direction we're exploring as well.