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
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.
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.
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?
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
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.
> 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.