ethegwo

Yes, I think VCs have already switched to using other metrics that are less easy to fake, such as download per month or customer interviews (or more direct, ARR, even for really early stage startups). I just want to explain the background reason of it.

When a partner decides to recommend a startup to the investment committee, he needs some explicit reasons to convince the committee, not some kind of implicit vibe

Many VCs are only doing one thing: how to use some magical quantitative metrics to assess whether a project is reliable without knowing the know-how. Numbers are always better than no numbers.

I previously worked at Bytedance and we've maintained a Rust zero-copy gRPC/Thrift implementation for 4 years: https://github.com/cloudwego/volo, it is based on Bytes crate (reference counting bytes, for folks don't familiar with Rust ecosystem). A fun fact: when we measuring on our product environment, zero-copy isn't means higher performance in lots of scenarios, there are some trade-offs:

1. zero-copy means bytes are always inlined in the raw message buffer, which means the app should always access bytes by a reference/pointer

2. You cannot compress the RPC message, if you want to fully leverage the advantages from zero serdes/copy

3. RC itself

CGI/PHP treated database connections as something that's always available. That pushes a lot of hidden complexity onto the database platform: it has to be reachable from anywhere, handle massive fan-out, survive bursty short-lived clients, and remain correct under constant connect/disconnect.

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.

Yes it's Apache 2, thanks for pointing this out, I'll be fixing this.

It's currently 3MB, and we've done almost nothing to reduce the file size, so we can expect it to get even smaller.

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.

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.

Yes We'll provide a report to explain how we tradeoff these things, please stay tuned.

Request the source? I researched and calculated the cumulative percentage of global carbon emissions from major economies since the industrial revolution: - United States: 24% - China: 15% - Russia: 6.7% - Germany: 5.2% - United Kingdom: 4.4% - Japan: 3.8% - India: 3.5% - France: 2.2% - Canada: 1.9% - Ukraine: 1.7%

source from Global Carbon Project, is this reliable?

Sure I'd love to, could you share your practice or what you are doing on top of Parquet?

typed-arrow avoids any kinds of runtime side effects: cost, errors, etc.

Tonbo IO | Product Engineer | Remote | https://tonbo.io/careers/product-engineer

Tonbo IO | Product Engineer | Remote | https://tonbo.io/careers/database-engineer

We are a startup founded in the fall of 2023, working on offering "headless" real-time data analytics under Postgres. We have released several open-source projects that you can check out at https://github.com/tonbo-io.

Back-End Core Stack: Rust, Apache Arrow/Parquet, Open Telemetry

Front-End Core Stack: Python/JavaScript, NodeJs/Deno, Next.js/React, Drizzle, D3.js, WebAssembly

Thanks, easy-to-scale is the first thing we consider, also using S3 as a shared storage service makes architecture easy to achieve this.

We are building tonbo: https://github.com/from-the-basement/tonbo , An embedded KV database allows to use S3 as storage backend, and we are trying to implement SQLite virtual table on it: https://github.com/tonbo-io/sqlite-tonbo a real pay-as-you-go DB.

Random reads and sequential writes are enough to build a log-structured database, but S3 does not really support the latter.

the post only talks about "future state", maybe I'm not clearly to point out this. with epoll, accept syscall and future state changing is happened in the same polling, which io_uring is not. Once accept syscall is complete, future has already advanced to complete, but actually it is not at that moment in the real world Rust.

Thanks, I will fix it.

> if the accept completes before the SQE for the cancellation is submitted, the FD will still be leaked.

If the accept completes before the cancel SQE is submitted, the cancel operation will fail and the runtime will have a chance to poll the CQE in place and close the fd.