necubi

Cloudflare’s clef is multimodal (https://blog.cloudflare.com/clef-decision-models/)

(Disclaimer, I work at Cloudflare, but not on models)

This is a great suggestion, it has the same semantics but avoids the extra round trip. We’ll add this.

Sure! There are definitely some overlapping use cases, and we've seen folks using/abusing queues for use cases that are more appropriate to something like k2.

Queues are great when you have a unit of work that needs to be completed, retried, and tracked individually. For example, a shop might need to call a payment processor API that can fail or timeout, and retry it until it succeeds, while polling on the frontend for the state of that particular message. With a queue, you can insert a message tracking that payment, and have a queue processor that keeps getting sent it until it succeeds or has failed too many times.

In a queue each item is its own thing that's important to someone, and queues give you APIs to interact with that particular item.

K2 is for moving large volumes of data around. Pricing is per GB, not per message. Records are produced and consumed in bulk, and what matters is that all records are processed, but no one is querying the state of a particular record. K2 also supports multiple consumers for the same record, and long term retention. For example, all of your applications may emit events when things happen, and those events need to be read by an alerting system, a system that durably stores them, and a system that uses them to build ML features.

Yep. I'm not personally a huge fan of the kafka API — I think it's simultaneously too low level for normal users and too high level to deeply integrate into other systems (like stream processing engines), and requires a complex client library to use effectively.

We went with a simpler and more user friendly consume API, that also allows much higher levels of read parallelism (particularly important if you're using something like Workers, which parallelize well but aren't very powerful individually).

But we know many companies are invested in the Kafka ecosystem, and we want to provide an easy on (and if necessary, off) ramp for them.

Yes! We originally built K2 to serve as the ingestion layer for Basin Pipelines [0], our stream processing product. We have a number of other teams building new products on top of it at the moment which I can't talk about yet :)

[0] https://developers.cloudflare.com/basin-pipelines/

Definitely agree that every data system that doesn't need <100ms latency is moving to object storage.

> I do wonder if we will see an expansion of the s3 api to support more of these use cases

This is actually an area where I think we have a big leg up on folks building on top of S3. My team (which built K2) sits next to the R2 team, and we have the opportunity to co-evolve the products in mutually beneficial ways.

Google PubSub is a great product. The primary benefit of K2 is cost, particularly for longer retention periods. Being backed by object storage means that we can store data extremely cheaply compared to disk backed solution, and we pass that on in our pricing.

Compared to self-hosted or cloud-hosted Kafka (e.g., Amazon MSK or Confluent), K2 is much cheaper, and fully serverless. There are no clusters to manage or scale, and consistent performance even as you vastly increase the amount of data.

The main downside is produce (and end to end) latency is higher (around 1s p99) than systems that rely on local disk replication, like Kafka.

So it's great if you're trying to move a huge amount of data around, or for use cases where cost is more important than latency.

I'm the author of the post and tech lead for K2. Happy to answer any questions!

I've similarly spent a decade in the streaming space, started a stream processing startup, built three streaming platforms at various large companies... and I basically agree.

Streaming always felt like it was about to happen, and it kept not happening, in a year of the linux desktop sort of way. I (and others, who also optimistically started stream processing startups) thought it was a technology problem but ultimately it's a demand problem: very few companies actually need low latency processing. And continuously running, stateful systems are inherently more complex to operate and evolve compared to batch systems.

Now that relatively low-latency ingest into warehouses and datalakes is easily achieved, it's really hard to make the argument to invest in complicated streaming systems.

That said, it still feels like we've landed in a suboptimal spot. Stream processors (in particular, those following the dataflow model) solve two problems that are hard in batch systems:

1. Determining and signaling completeness for a time period (when have I likely received all of the data for 12:01pm, such that I can now safely process it)

2. Avoiding expensive recomputations for periodic queries

I do think long term we'll see some amount of streaming influence moving back into the batch systems, particularly as object storage gives us the ability to run stateful workloads with less operational headache.

(If anyone else finds these problems interesting, I'm hiring for my stream processing team at Cloudflare. Email in my profile)

The forest scenes in shogun were filmed in Squamish, around some very popular climbing areas. You can even see chalk on some of the boulders.

ABC was originally designed for European folk music [0], not church music. The corpora as a result is largely fiddle tunes, particularly Irish (see for example https://thesession.org).

ABC started very simple, because most of the performance information for folk music isn't written down, it's inferred by the player according to the idiom of that particular tradition. As usage of ABC has grown it's gotten more powerful but still falls far short of formats designed for western classical, like MusicXML or Lilypond.

[0] https://abcnotation.com/history

MIPS is increasingly common in rock helmets. Black Diamond (anecdotally the most common brand I see in the US) now has it in their higher end models, and Mammut as well.

You do not need perfect pitch to quickly learn fiddle tunes by ear (source: I play fiddle, can quickly learn by ear, do not have perfect pitch). You learn tunes primarily by relative pitch, which most people can develop.

There's also an element of violin-specific pitch detection; if you play violin for long enough, you can recognize the specific timbre of different notes on a violin (particularly easy for open strings) which helps ground you while listening to a tune.

It's 5B active params in MoE, not 5B total params (total is 137B).

Better this than the Bot Company, which has been apparently renting out AirBnBs for robot testing and leaving them trashed: https://sfstandard.com/2026/05/28/sf-startup-secretly-testin...

This isn't at all how YC companies operate (source: I did YC), but also... Plaid is not YC.

CloudFront may sound like Cloudflare, but it is an unrelated AWS service (https://aws.amazon.com/cloudfront/)

(Disclaimer: I work for Cloudflare)

GitHub launched in 2008, so that seems unlikely?

Humans are also famously bad at drawing bicycles from memory https://www.gianlucagimini.it/portfolio-item/velocipedia/

Those would be angels, not VCs. VCs manage outside money.

I’m someone who is not a python developer but has to use python tools and run other people’s python code. I have suffered through learning about anaconda, virtualenv, pip, and more. Uv is the first time there’s a tool that just runs the software without requiring me to become a python ecosystem expert

It would be pretty shocking for Amazon to break the S3 API at this point. There is a huge 3rd party ecosystem that would be affected. For example, in Rust land the object_store crate is at least as popular as the official SDK.

Matt Levine has a take: https://www.bloomberg.com/opinion/newsletters/2026-02-24/ai-...

> Look, I am sorry. But if you go to Jump Trading and Jane Street and say “hello, I have an unregulated poorly designed mechanism that could lead to $50 billion of market value collapsing overnight, would you like to trade with me,” they are going to say yes, but their eyes are going to light up, you know? If at Time 0 you give them an extremely gameable system that can produce billions of dollars of profit, at Time 10 your system is going to be a smoking wreckage and they are going to have billions of dollars of profit. That’s their whole job, you know? I couldn’t tell you in advance what all the intermediate steps will be, and in fact in hindsight I cannot tell you what the intermediate steps actually were, how Jump and Jane Street made money off the collapse of Terra. But as a heuristic, I mean, come on. Terra was like “hello we have a balloon full of money, here is a pin, dooooooon’t pop the balloon.” Guess what!

Would love to see this for Rust!

Or if you’re a newish startup who they hope will eventually spend enough to justify it.

I don't think this is meaningfully HTAP, it's gluing together two completely different databases under a single interface. As far as I can tell, it doesn't provide transactional or consistency guarantees different than what you'd get with something like Materialize.

This isn't new either, people have been building OLAP storage engines into MySQL/Postgres for years, e.g., pg_ducklake and timescale.

Sorry for the ambiguity and confusing mix of abbreviations and airport codes!

It's San Francisco/Austin/Seattle/New York City/London/Lisbon

Cloudflare | Rust/DB engineers | SF/Austin/Seattle/NYC/London/Lisbon (Onsite) | Full-time

Hey HN, I'm hiring engineers for the new Cloudflare Data Platform (https://blog.cloudflare.com/cloudflare-data-platform). We do streaming ingest and processing, managed Iceberg catalogs, and a distributed query engine—all built on R2 and the Cloudflare Edge. We're making it ridiculously easy for Cloudflare customers to build data lakes.

I'm looking for Rust engineers with experience working on databases, stream processing engines, and query engines. You'll get to work on incredibly cool tech on a huge scale.

Note: we are hiring for on-site roles in one of our engineering hubs, not hiring remote at this time.

If you're interested, shoot me an email (in profile) with subject HN and a brief description of your background and interest in the role.

Expressing your first amendment right to protest is not “almost anything.” Historically, courts have taken very dim view of government retaliation for first-amendment protected activities.

In the same boat, I try it every few months but give up because the emacs mode still isn't good enough. It's been getting slowly, slowly better though.