Cloudflare Durable Objects with SQLite storage charge $1.00 per million rows written and $0.001 per million rows read. Writes are 1,000x more expensive than reads. The docs tell you that "every row update of an index counts as an additional row written" — but that's where the guidance ends.

How much does a compound index cost? Does WITHOUT ROWID actually save money? If I update a column that isn't indexed, do I still pay for the indexes? Does UNIQUE have an impact? Questions like these come up regularly on the #durable-objects Discord, and I've never seen an experimentally-validated publication that answers them. So I wrote 36 tests and measured everything.

If you're building on Cloudflare Workers and Durable Objects, you've probably wired up auth at least once — JWT validation, token refresh, key rotation, permission checking. It's not glamorous work, and bolting on an external auth service (Auth0, Clerk, Supabase Auth) means another dependency, another bill, another point of failure, and latency from round-trips to someone else's infrastructure.

@lumenize/auth is a different approach: passwordless authentication that runs entirely inside your Cloudflare Worker. No external service. No SDK. Just a Durable Object that handles magic-link login, JWT signing, refresh token rotation, and access control — all at the edge.

Today we're releasing Lumenize Mesh in beta — a de✨light✨fully radical new way to build on Cloudflare Workers and Durable Objects, where DOs, Workers, and browser clients are all equal peers in one mesh.

Lumenize Nebula is an agentic software engineering platform built on Lumenize Mesh. Define your business ontology declaratively. Nebula handles the rest.

Alongside the Lumenize Mesh beta announcement, we're making several package changes. Here's what moved, what's new, and what to update.

I was today years old when I learned how WebSockets and CORS really work. And: how CORS can be implemented in a non‑standard (but arguably better) way.

One of the "Larry-isms" that my family and coworkers are tired of hearing is, "You can't be better unless you are different." It's not an endorsement for being different just to be different but rather, to look for opportunities to deviate from the norm when you think you have found a better way to do something. I always follow it with a statement that just because you think you have a better way doesn't mean that you actually do — and that may very well be the case with what I did today.

I implemented a non-standard way of handling Cross-Origin Resource Sharing (CORS) in Lumenize. You be the judge of whether or not it's better.

Remember that childhood game called "broken telephone" where we lined up in a circle with our friends. Then, one person would whisper something into their neighbor's ear, and they would in turn whisper it into the next friend's ear until you completed the circle? If you were lucky, you might land beside the person you secretly liked—the tiny thrill of whispering anything into their ear. The lesson was that every translation from brain to words and back again was just a little bit lossy. Cumulatively, what came out the other end was nothing like the original message.

Software systems, and APIs in particular, are no different. Every layer of translation risks just a little bit of loss in fidelity. This is nowhere more true than in the realm of types, schemas, validation, and code generation — the same patch of cognitive quicksand occupied by TypeScript, JSON Schema, Ajv, Zod, and friends.

MCP is all about context portability: moving structured data democratically across agents, runtimes, and languages. The type/schema has to remain the same throughout the journey around the circle of friends. Tooling decisions have very real consequences for portability and correctness. So imagine my surprise when I discovered the Babel of type/schema translations running in MCP stacks today.

Somewhere between recess and real life, we all learned the difference between a childhood crush and a partner you can build with. Flash is fun on the playground; fidelity gets you into adulthood. With Lumenize, I wasn’t looking for puppy love. I was looking for a commitment that would survive different runtimes, languages, and teams.

Kenton Varda​

I started playing with DOs shortly before Kenton Varda (aka @kenton) published his now famous Easy, Fast, Correct — Choose three post which introduced a high-consistency concurrency model via: 1) input gates, 2) output gates, and 3) storage cache. The good news was that this gave us a wonderful new way to build highly-scalable applications. The bad news was that it's such a radical departure from what we are used to doing, that it requires a huge mindset shift to take advantage of.

Over the next few years,