Microsoft Just Put a Workflow Engine Inside Postgres

Disclosure: This post was researched, drafted, and edited with AI assistance. Microsoft's pg_durable GitHub repository and README were the primary source; the HN announcement thread (281 points, 72 comments at time of writing) was the secondary source. Opinions, framing, and analysis are the author's.

Microsoft open-sourced pg_durable on June 5th and most coverage will focus on the SQL DSL, the ~> and |=> operators, and the question of whether writing workflows as SQL strings is a good idea. That's the wrong story. The real story is that the author of pg_durable is the same person who built the orchestration layer for Durable Task Framework — the framework that has been running Microsoft-internal workflows and Azure Durable Entities for close to a decade — and the team is now putting that capability inside Postgres. If you've ever told someone "we need a workflow engine for this," and the answer was Temporal, or Airflow, or Step Functions, that answer just got weaker.

What pg_durable actually does

A pg_durable function is a graph of SQL steps that Postgres executes and checkpoints as it goes. If the database crashes, restarts, or a step fails, execution resumes from the last durable checkpoint instead of forcing you to reconstruct state by hand. You start one with a one-liner:

SELECT df.start(
  'SELECT id FROM documents WHERE processed = false LIMIT 100' |=>
  'batch' ~>
  'UPDATE documents SET processed = true WHERE id = ANY($batch)'
);

The runtime checkpoints between steps, so a restart in the middle of a long job doesn't rerun work that already succeeded. Status and results are queryable from standard Postgres tables (the README points to df.instances) — same auth model, same backup model, same observability tooling. There is no Redis, no Temporal cluster, no separate queue service. It installs as a PostgreSQL extension and ships as a Debian package for PG 17 and 18 on amd64.

Under the hood, pg_durable is built on duroxide, a Rust-based durable execution runtime that handles deterministic replay, checkpoints, sub-orchestrations, and timers. pg_durable is the Postgres-flavored wrapper (PostgreSQL License); duroxide is the engine (MIT). The two components carry different licenses.

The "Postgres is enough" thesis just got real

There's been a persistent argument in the Postgres community for years — most visibly at postgresisenough.dev — that you can replace a lot of operational machinery with Postgres if you reach for the right extensions. pg_durable is the most ambitious version of that argument yet: it claims that durable execution, the thing that has historically required a separate orchestrator like Temporal, is just another primitive the database should provide.

The README's own list of "what you're probably doing today" makes the displacement target explicit:

• pg_cron plus a jobs table, status columns, retry counters, and a polling worker
• An external orchestrator (Airflow, Temporal, Step Functions, Argo) calling back into Postgres
• A queue plus workers plus a separate state table to coordinate retries
• A plpgsql procedure that works until a crash or long-running transaction forces you to start over

That's the menu. If pg_durable works as advertised, several of those menu items become the same thing, and the "we need Temporal for this" justification gets harder to make.

The maintainer of postgresisenough.dev is already asking for a PR to add pg_durable to the site. That's the tell — the people who've been arguing "Postgres is enough" see this as a real entry in the catalog, not a marketing stunt.

The Microsoft stake is bigger than it looks

Two things are easy to miss. First, the lead committer, affandar, is also the author of Durable Task Framework, the orchestration library that has powered Azure Durable Functions and Durable Entities. This isn't a new team learning the durable-execution category. It's the same team shipping their next move in the open.

Second, the same repo's documentation points at Azure HorizonDB, Microsoft's new PostgreSQL cloud service, as the place to try pg_durable — and notes that it's "engineered for performance and built with pg_durable inside." This isn't a one-off OSS contribution. It's a positioning move. Microsoft is betting that the database is the right substrate for workflow orchestration, and the database they want to bet on is Postgres, not a proprietary service they control end-to-end. That tells you something about where they think the leverage is.

The honest counterargument: the SQL DSL is awkward

The most consistent pushback in the HN thread is that the workflow syntax is hard to read. One commenter, looking at the README example, called it "bizarre." Another pointed out that embedding SQL strings inside other SQL strings — which is what the df.start(...) syntax essentially is — is a maintainability hazard waiting to happen.

Both criticisms are fair, and the maintainers know it. gdecandia, a contributor, said: "Agree that the DSL ergonomics can be improved. Our pipelines use a higher level language and therefore simplified, but pg_durable is meant to solve a wider array of problems. We're happy to take suggestions for improvements." A committer also noted that the state-provider layer is an extensibility point — they're open to alternative backends like a pgmq-based state provider, rather than the default PostgreSQL one.

The DSL awkwardness is the price you pay for putting workflows inside a SQL-shaped runtime. The tradeoff is real: pure SQL workflows are more constrained than Temporal's TypeScript SDK, but they force the architecture into a shape that survives database restarts, which is the whole point. If you've been writing Temporal workflows in TypeScript and never worrying about the underlying state store, you may not feel the pain pg_durable is solving. If you've been writing plpgsql procedures and losing work to transaction timeouts, you will.

What it's not

• It's not a replacement for Airflow if your workflows fan out across heterogeneous systems (S3 + Spark + Slack + a database). The README explicitly says: "if the workflow mostly lives outside Postgres and spans many heterogeneous systems," reach for a general-purpose orchestrator.
• It's not a sub-millisecond request handler. It's for durable background work, not synchronous request paths.
• It's not available everywhere. The first-class deployment is Azure HorizonDB. If you're on AWS RDS, Aurora, Supabase, or Neon, you'll need to install the extension yourself and check whether your provider's PG build allows it.
• It's not the first durable-execution project on Postgres. pg-boss, pg-workflows, and several others have been filling this niche for years. pg_durable is the most ambitious and the first with a major-vendor seal.

The performance and architecture story that's still developing

The README lists workloads (vector embedding pipelines, ingest pipelines, scheduled maintenance, fan-out aggregation, external API workflows) but doesn't publish benchmark numbers as of the v0.2.2 release. That's reasonable for an early OSS drop, but it means the "is this faster than my current setup" question is one you'll have to answer with your own load tests. The engine is Rust (duroxide) and the integration is in-PG, so there's no obvious reason it should be slow — but the early numbers will tell.

The architectural claim most worth testing is the parallel-fanout story. The README says pg_durable supports "fan-out aggregation: run independent queries in parallel, then join the results." If this works inside a single Postgres connection without an external worker pool, it's a real differentiator from the queue-plus-workers pattern.

The original take: the orchestrator is being absorbed into the database

pg_durable doesn't beat Temporal feature-for-feature today — Temporal has sub-orchestrations, versioning, signals, queries, and a TypeScript SDK that a generation of developers have already learned. pg_durable has none of those. The interesting question is what happens if a category of workflow tools gets pulled into the database itself over the next three to five years. Microsoft shipping pg_durable as a PG extension, embedded in their new cloud Postgres, is a strong signal that the answer to "where does the orchestrator live?" is shifting from "separate service" back to "the database." If this pattern holds, expect to see competing extensions in MySQL, MariaDB, and DuckDB within 24 months. The durable-execution category as a standalone product category gets thinner with each one.

The counter-trend is the continued rise of general-purpose orchestrators with mature SDKs (Temporal, Restate, Inngest) and the assumption that workflows will increasingly be written in application code, not SQL. If you're betting on that future, pg_durable is a 2026 data point, not a trend reversal. If you're betting on the database-absorbs-orchestration future, this is the most significant open-source release of the year so far.

What to do this week

# Check what your current workflow stack actually is
SELECT count(*) FROM information_schema.tables
WHERE table_name IN ('jobs', 'job_runs', 'workflow_state', 'scheduled_tasks');
# If you have more than 2 of these, you have a homegrown orchestrator.

# Look at what extensions your Postgres allows
SELECT name, default_version, installed_version
FROM pg_available_extensions
WHERE name IN ('pg_cron', 'pg_durable', 'pgmq');
# If pg_durable shows up with a version, your provider has built it in.
# If it doesn't, ask them when it will.

If you have a Temporal deployment that's mostly doing "fetch some rows, update some rows, wait, update some more rows" — that's exactly the workload pg_durable is for, and it's worth a one-week prototype to see if you can drop the orchestrator from your architecture diagram.

If you're on Azure and you've been waiting for "modern" Postgres features to land on Azure, the HN commenter who said "I'm trapped on Azure" is the user you should be listening to. Azure HorizonDB is the response to that complaint, and pg_durable is one of the first things it ships with.

If you're a maintainer of an existing pg-boss or pg-workflows-style project: now is the time to make sure your README has a "how this compares to pg_durable" section. The displacement question is going to come up in every HN thread for the next quarter.

What this means for you

The story of pg_durable is that the most valuable open-source workflow orchestration capability — the kind that was, until now, the reason to deploy a separate service — is now an install command away from every team that already runs Postgres. The deployment cost of "I need durable execution" just went from "spin up a cluster" to "apt install pg-durable-postgresql-17." That's the same kind of leverage shift that Redis 8.8's array data type brought to in-memory data structures, and the same pattern Cloudflare applied in acquiring VoidZero — own the substrate, and the layers above it become someone else's problem to defend. (For more on what "owning the substrate" looks like on the model side, see how Gemma 4 12B dropped the multimodal encoder — different substrate, same play.)

The next time someone tells you "we need Temporal for this," the better question is: do you need a workflow engine, or do you need Postgres to remember what it was doing?

Redis 8.8: Your Lua Rate Limiter Is Now Obsolete

Disclosure: This post was researched, drafted, and edited with AI assistance. Redis's official announcement was the primary source; benchmark numbers and feature claims were verified against the markdown source of their post. Opinions, framing, and analysis are the author's.

Redis 8.8 shipped on June 2nd with six new features, and most coverage will lead with the array data type. That's a mistake. The real story is that Redis has quietly crossed the line from "in-memory data structure server" into "a different kind of database," and two of these features do most of the work to get it there.

The new array data type (and why it isn't the real story)

The new array data type is going to get most of the attention. It's an index-addressable, dynamic, sparse-friendly container that supports server-side SUM, MIN, MAX aggregations over index ranges and can act as a ring buffer with a single command (ARRING). For random-element access at 100K elements with 1KB values, the benchmarks show arrays running 5x faster than lists and 8–15% faster than hashes. For ring-buffer operations, ARRING is twice the throughput of the RPUSH+LTRIM idiom everyone has been using for years.

That's all real and worth knowing about. But the data type is the easy part. The hard part is the implicit claim embedded in the design: that the right place to do sliding-window aggregations, log-line searches, and sensor-data sum/min/max is inside Redis, not in your application code. That's a much bigger architectural shift than a new container.

The story nobody's writing: INCREX ends a decade of Lua

If you've built a production rate limiter in Redis at any point in the last eight years, you wrote a Lua script. Some combination of INCR, EXPIRE, conditional logic, maybe a sliding window via a sorted set, and a Lua wrapper to keep the whole thing atomic. It's the kind of code you copy from a 2014 blog post and never look at again.

Redis 8.8 introduces INCREX, a new generalized INCR-family command that does this natively:

INCREX key
       [<BYFLOAT|BYINT> increment]
       [LBOUND lowerbound] [UBOUND upperbound] [SATURATE]
       [EX sec | PX msec | EXAT unix-time-sec | PXAT unix-time-msec | PERSIST]
       [ENX]

Three things make this more than just "another increment command." First, it returns both the new counter value and the actual increment applied, so the caller knows immediately whether the request was allowed or rejected. Second, the ENX flag sets the expiration only if no expiration is already set, which means a window's TTL is anchored to its first request and not silently reset by every later call — a subtle bug that has bitten a lot of production rate limiters. Third, the SATURATE flag with UBOUND lets you clamp the counter at the limit rather than reject, which is the difference between a strict rate limiter and a graceful one.

If you maintain a Redis-backed rate limiter in production: your Lua script is now a one-liner. The pattern is no longer worth its complexity.

The "real" message queue story: XNACK

For two years the most-cited reason not to use Redis Streams as a serious message queue was the failure-recovery story. A consumer that couldn't process a message had two options: ACK it (lying about success) or leave it pending and wait for XAUTOCLAIM to redistribute it after the idle timeout. For anything latency-sensitive, the second option was a non-starter.

Redis 8.8 adds XNACK, a real negative-ack command with three modes designed for three failure patterns:

• SILENT — failure was unrelated to the message (consumer shutting down, transient network error). The delivery counter is decremented, undoing the original increment. The message becomes immediately available to other consumers.
• FAIL — message is too expensive for this consumer but might succeed elsewhere. Delivery counter stays incremented; the message returns to the head of the queue.
• FATAL — poison message, malformed, or potentially malicious. Delivery counter is set to LLONG_MAX, making it easy to detect and route to a dead-letter queue downstream.

This is the missing piece. It transforms Redis Streams from "queue-ish, with caveats" into "queue, full stop," because the failure-handling primitives now match what RabbitMQ or Kafka consumers take for granted. If you were weighing Redis Streams against a heavier queue service for a new project, that calculation just changed.

What the new array type is actually for

Two concrete things you can build with arrays + streams + 8.8 features:

1. A self-hosted log aggregator. Arrays hold the last N lines per service, server-side SUM/MIN/MAX does count-by-severity and percentile queries, XNACK SILENT handles the dead-letter path when a parser crashes. No Elasticsearch, no ClickHouse, no managed SaaS — and the same Redis instance you already operate for caching carries the workload.
2. A sensor pipeline ingest layer. Array-as-ring-buffer holds the last 60 seconds of readings, SUM/MIN/MAX over an index range gives you windowed stats without bolting on a separate TSDB. Useful for the "alert me when p99 latency in the last 30 seconds crosses X" pattern that currently needs Prometheus or InfluxDB.

This is what I mean by "a different kind of database." Redis used to be a cache you put in front of your real database. With 8.8, you can plausibly make it the system of record for narrow, time-bounded use cases where you used to reach for something heavier.

The performance numbers worth quoting

Beyond features, the 8.8 release is also a serious performance update. From the official benchmarks:

• MGET pipelined with I/O-threads: up to 68% throughput improvement
• XREADGROUP with COUNT 100: up to 83% improvement
• ZADD/ZINCRBY/ZRANGEBYSCORE (sorted set operations): up to 74% improvement
• Persistence and full synchronization: up to 60% faster
• JSON numeric arrays (introduced in 8.4): up to 92% memory reduction, with new explicit control over BF16/FP16/FP32/FP64 storage for vector indexing needs

That last one is the AI angle nobody is connecting yet. Vector storage in Redis is now substantially cheaper than the marketing typically suggests, and the new precision control means you can store embeddings in the exact format your model expects — no casting, no precision loss, no awkward BF16 conversion layer. (For more on the model-side tradeoff, see how Gemma 4 12B dropped the multimodal encoder for the parallel argument that unified token spaces simplify AI plumbing.)

The meta-story: how the maintainers actually built it

There's been discussion on Hacker News (the announcement thread, 78 points at time of writing) about whether the array data type was implemented with LLM assistance. I won't make stronger claims about that than the public record supports — the announcement credits @antirez as the author, and the deeper "how it was built" question is best answered by reading the maintainer's own posts rather than by an outside observer guessing. Worth noting for context, but take second-hand claims with salt.

What's clear from the announcement itself is that the Redis project shipped a substantial new feature, benchmarked it, documented it, and put it in a numbered release. The takeaway for engineering managers who are still working out their AI policy isn't "use AI to write your database" — it's that AI is a tool, the verification step is the work, and a maintainer with a real test suite and benchmark suite can ship a major feature in a way that's documented and reproducible.

The trade-offs you should know about

• Arrays are not free. They use about 18% more memory per element than a list. If your bottleneck is memory, not CPU, a list might still be the right choice. The benchmarks measure throughput, not footprint.
• The new features are open-source-only. Redis 8.8 is the open-source release; managed Redis services (AWS ElastiCache, Azure Cache, Redis Cloud) will roll out these features on their own timelines. If you depend on a managed service, check the roadmap before planning around INCREX or XNACK.
• The 92% JSON numeric array reduction is for a specific workload (homogeneous numeric arrays, especially vector embeddings). It's not a general-purpose JSON storage improvement.
• The announcement thread on Hacker News was solid, not viral (78 points, 33 comments at time of writing — see the full discussion). Search volume for "Redis 8.8" will be real but bounded. The high-intent long-tail keywords (rate limiter, sliding window, streams NACK, array data type) are the realistic targets for organic search.

For comparison on what a more focused single-feature announcement looks like, see Cloudflare's recent VoidZero acquisition post — different topic, but the same pattern of one large headline news item generating a deeper, narrower technical conversation over the following week.

What to do this week

If you have a Lua rate limiter in production:

# Check the script's complexity first
redis-cli SCRIPT EXISTS $(redis-cli SCRIPT LOAD "$(cat rate_limiter.lua)")
# If it comes back 1, you have a Lua rate limiter.
# Read the INCREX docs and start planning the migration.

If you're building anything message-queue-shaped and avoiding Redis Streams because of the failure-recovery story: that objection just got answered. Run the same load test against RabbitMQ and against Redis Streams + XNACK and see how close the numbers are.

If you're storing vectors in Redis: check what precision you're actually using and whether the new BF16/FP16/FP32/FP64 control lets you cut memory without losing model quality. For most embedding models the precision difference is in the noise.

What this means for you

The story of Redis 8.8 isn't "here are six new features." It's that the project is now competing on three fronts it wasn't competing on a year ago: as a primary database for narrow, time-bounded use cases; as a message queue with proper failure handling; and as a vector store with explicit precision control. None of those is going to displace the best-in-class tool for any single use case. But the combination — one system you already operate that now does all three — is exactly the kind of leverage small teams have been waiting for.

The next time someone tells you Redis is "just a cache," ask them which cache ships its own sliding-window database, message queue, and vector store in a single binary.

Cloudflare Just Bought the Build Tool That Runs the Web

Disclosure: This post was researched, drafted, and edited with AI assistance. The Cloudflare announcement and VoidZero product pages were the primary references; technical claims and direct quotes were verified against them. Opinions, framing, and analysis are the author's.

Evan You — creator of Vue.js and founder of VoidZero, the company behind Vite — announced this morning that VoidZero is joining Cloudflare. The full team is moving over, all the projects stay MIT-licensed and community-driven, and Cloudflare is putting a million dollars into a Vite ecosystem fund. If you build anything for the web, this is the most consequential tooling acquisition in years. Here's why the deal matters, and why the buyer matters more than the size of the check.

The numbers that should change how you think about "build tools"

Vite — the build tool VoidZero is most famous for — pulls 129 million weekly downloads. That number is so large it stops meaning anything until you compare it. React gets about 35 million. Next.js about 25 million. Webpack, the previous generation's default, around 60 million. Vite is now the most-installed frontend build tool on the planet by a factor of two.

It's not just popular in raw numbers. Vite is the foundation under Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, React Router, TanStack Start, and Angular (via the community-maintained Analog and @analogjs/vite-plugin-angular). Cloudflare's own vinext project is a drop-in Next.js reimplementation built on Vite. When you ship a SvelteKit app, you're shipping on Vite. When you ship an Astro site, you're shipping on Vite. When you ship a TanStack Start app, you're shipping on Vite. The web framework ecosystem in 2026 is, effectively, a Vite ecosystem.

That's the context for why this acquisition matters. Cloudflare didn't buy a popular dev tool. They bought the substrate almost every modern web framework compiles through. Whoever owns Vite has more influence over how the next decade of web apps get built than any other single entity in the JavaScript world.

Three reasons Cloudflare wanted this

The acquisition announcement frames it around three themes. They're worth reading carefully, because each one tells you something about where the web is going.

One: the "open internet" argument. Cloudflare's public framing is that Vite underpins so many frameworks that tilting it toward a single vendor would damage trust and slow the whole ecosystem. Buying it and then keeping it neutral is, in their telling, the most pro-developer outcome possible. Whether or not you take that at face value, it's the right argument to lead with. Anything else would scare the ecosystem.

Two: AI agents are the new heavy users of dev tooling. Cloudflare and the VoidZero team make the case that agent-coded applications are already choosing Vite — agents scaffold projects, run dev servers, read errors, write tests, and deploy, all of which Vite makes fast. If the agent-coding thesis is right (and the hiring data, the funding data, and the GitHub commit data all suggest it is), then owning the build tool that AI agents reach for first puts Cloudflare in the path of every agent-generated app. The same stack builds the app and deploys it.

Three: Vite is becoming the full-stack dev experience. Modern apps aren't just bundles anymore. They have serverless functions, agent backends, vector databases, edge runtimes. The Vite+ product wraps the VoidZero toolchain (Vite, Vitest, Rolldown, Oxc) into a single CLI with one configuration model. If Vite becomes the place where "code becomes a running app" happens, owning Vite means owning the most important transition in the developer experience. Cloudflare is the natural buyer here because they already have the deployment half.

Why Cloudflare is the best possible buyer

A year ago I would have bet on Microsoft or Amazon being the most likely acquirer of a tool this important. Both have deeper pockets and more existing dev-tool relationships. But neither would have been good news.

Microsoft buying Vite would have raised immediate GitHub Copilot and VS Code conflict-of-interest questions. Amazon buying Vite would have meant months of uncertainty about whether the AWS Amplify team would get preferential treatment. In either case, the trust that took Vite from "fast dev server" to "129 million weekly downloads" would have evaporated overnight. The community would have forked the project within a week, and the fork would have won.

Cloudflare is the right buyer for three reasons that don't get enough attention:

They have no existing dev-tools product to favor. Cloudflare sells CDN, Workers, R2, D1, Pages. They don't have a competing bundler, framework, or package manager. There's no internal team whose budget depends on Vite failing. The conflict-of-interest surface is genuinely small.

Their mission aligns with Vite's "open" stance. Cloudflare has historically been the buyer-of-record for open projects that need a corporate home without a corporate agenda — the Astro team joined Cloudflare earlier this year under exactly this model. The same playbook is being applied here. That's not a small thing: it's the single most important signal about what the next five years look like.

They're putting the right guardrails in writing. The announcement is unusually explicit about what won't change. Vite stays MIT-licensed. Vite's roadmap is community-driven. Features added to Vite itself should not be Cloudflare-specific. The Vite team continues leading the projects. The $1M ecosystem fund goes to the Vite core team to administer, not to a Cloudflare-controlled foundation. The Astro acquisition set this template, and VoidZero is being folded into the same structure.

What's in it for you, the developer

If you're already using Vite, the announcement is explicit: in the short term, nothing changes. Your existing project keeps working. Your existing plugins keep working. Your existing CI keeps working. Evan You and the VoidZero team are still running the show. Roadmap discussions happen in the same GitHub repos and Discord servers as before.

In the medium term — six to eighteen months — three things are likely to get noticeably better:

1. Vite + Cloudflare gets a first-class full-stack story. The existing Cloudflare Vite plugin (14 million weekly downloads) runs your server code inside workerd locally, so the dev server matches production byte-for-byte. With VoidZero's full engineering team now part of Cloudflare, expect that integration to deepen, with the cf CLI rebuilt to feel like Vite, not like a separate tool.
2. Linting and formatting will get fast everywhere. Oxlint is already "saving days of engineering time" at Cloudflare per the announcement. With the VoidZero team inside the company, expect the oxlint/oxfmt tools to become deeply integrated into the Vite+ stack, replacing slower alternatives in the dev loop.
3. AI-agent-friendly tooling becomes a first-class concern. Both the Cloudflare and VoidZero teams have been talking about agent ergonomics. Expect Vite's "what can the agent see and call" surface to expand significantly.

In the longer term, the bet is that Vite becomes the default runtime gateway for edge-deployed JavaScript: bundle, test, deploy through the same tool. Cloudflare's commercial strategy depends on this story, and Vite is now part of how they get there.

What's the catch

Every acquisition has a catch. Here it's the same one it always is: corporate priorities can drift over five-to-ten-year horizons. The founders and maintainers could leave. The community could fragment. A future Cloudflare leadership team could reinterpret "vendor-agnostic" loosely.

The mitigations are real, though. The Astro acquisition set the playbook: open source stays open source, deploy-anywhere stays deploy-anywhere, community governance stays community governance. The Vite team has explicitly committed to the same model. The MIT license is enforceable regardless of corporate intent. The community can fork if it has to, and the goodwill to do so exists.

The honest read: this is a 90th-percentile outcome. The only better one would have been Vite staying independent forever, which was never going to happen given the scale. Of the realistic buyers, Cloudflare was the best outcome of the available ones.

The bottom line

If you build with Vite today, your workflow doesn't change this week. If you build with Vite next year, it gets better in ways you don't have to think about. If you're picking a frontend stack for a new project, Vite is now the lowest-risk default it has ever been — the company behind it is owned by a buyer whose business model depends on the open web, with the governance, the funding, and the explicit commitments to keep it that way.

The bundler wars are effectively over. Vite won, and the buyer it ended up with is the one the open web can live with. For now.

Gemma 4 12B Just Killed the Multimodal Encoder — Here's What That Means for You

Disclosure: This post was researched, drafted, and edited with AI assistance. Google's announcement was the primary reference; technical claims and direct quotes were verified against it. Opinions, framing, and analysis are the author's.

Google released Gemma 4 12B yesterday, and if you only read the headline you might think "another mid-sized open model, whatever." Don't move on. This one is different under the hood, and the architectural choice Google made is going to ripple through every open-weights release for the rest of the year.

The thing nobody's talking about: drastically lighter encoders

Most popular multimodal models today — GPT-4o, Claude, Llama 3.2 Vision, Qwen-VL — still rely on substantial modality-specific encoders. A vision encoder turns images into a stream of "vision tokens." An audio encoder does the same for sound. The main language model then sits on top of all these encoded streams and reasons over them.

Gemma 4 12B takes that apart. The vision "encoder" is replaced with a lightweight embedding module — a single matrix multiplication plus positional embeddings and normalizations. The audio path is even leaner: the raw audio signal is projected directly into the same dimensional space as text tokens.

In Google's own words from yesterday's release post:

"We replaced Gemma 4's vision encoder with a lightweight embedding module consisting of a single matrix multiplication, positional embedding and normalizations."

"We removed the audio encoder entirely and projected the raw audio signal into the same dimensional space as text tokens."

Read that again. A single matrix multiplication for vision. A direct projection of raw audio into the same dimensional space as text tokens.

This is a notable architectural choice. Google is betting that modality-specific preprocessing can be dramatically reduced. The old way treats vision and audio as fundamentally different modalities that need specialized pre-processing. The new approach says: "tokens are tokens. Project everything into the same space, let the transformer figure it out."

(Some researchers will quibble with the "encoder-free" framing — a projection layer plus positional embeddings is still a form of encoding. Fair. What's different is the order of magnitude: the encoder is now a single matrix multiplication rather than a ViT or a Whisper.)

Why this matters if you build with AI

If you're using a hosted API, this change mostly shows up under the hood — you'll get slightly lower latency, slightly lower memory cost, and the same end-user experience. The interesting part is what it enables for the local crowd.

Quantized versions of Gemma 4 12B can run on many consumer laptops with 16GB of unified memory. Not 24GB. Not 48GB. Sixteen. A $1,200 MacBook Pro with the base M-series chip can run a quantized build. A year-old gaming laptop with an RTX 4060 can run one too. Full-precision multimodal inference at meaningful speed may still need more, but the floor for "useful local multimodal" just dropped a lot.

Local multimodal models have existed for a while (Qwen2.5-VL 7B, Llama 3.2 Vision 11B, Phi-3 Vision, InternVL, MiniCPM-V), but they typically involved trade-offs in capability, latency, or hardware requirements. What Gemma 4 12B does differently is combine vision, audio, and chat in one model at the 12B size, on consumer hardware, with a single unified token space. That combination is what's new.

That's the actual story. Not "Google released a model." "Google released a model that makes truly local multimodal practical for the hardware people already own."

The 150 million download context

Google's release notes say Gemma models have been downloaded 150 million times across all platforms — a number that puts them in the same league as the major open-weights families, though exact comparisons to Llama's distribution are hard to pin down since different platforms count downloads differently.

What that tells me is that the developer gravity around Gemma is real, not hype. People are picking Gemma not because Google's marketing is loud, but because the licensing has been permissive (the team moved to Apache 2.0 for Gemma 4, and earlier versions used the Gemma license which was also commercial-friendly) and the model family covers the full hardware range from "phone" (2B, 4B) to "data center" (26B MoE, 31B dense).

Gemma 4 12B slots in the gap that was actually missing. Before this, you had a 4B model for phones and a 26B model for servers, and not much in between. The 12B is the one you'd want for a serious desktop dev machine.

What you can actually build with it

Yesterday's post highlighted two examples from the community: a wearable robotic arm that uses Gemma for physical assistance, and an enterprise security tool. Both are the kind of thing that needs multimodal input (vision for the robotic arm, audio for the security tool) but doesn't need a 200B parameter model.

Here are three concrete project types that became realistic yesterday:

1. A local accessibility tool that reads a webpage aloud, watches the cursor, and adjusts UI in real time. Vision for the cursor, text for the page, audio output for the user. All on-device, no cloud roundtrip.
2. A second-brain app that ingests voice memos, screenshots, and notes, and lets you search across all three with a single query. The unified token space means the model can reason about "the screenshot I took while talking about the API bug" without separate pipelines for image and audio.
3. A coding assistant that sees your screen, not just your text. Click on a function, get an explanation, ask "what's the bug here" with the screenshot as context. Quantized runs of Gemma 4 12B on a $1,200 laptop make this kind of project much more tractable than it was last week.

The agentic angle nobody's writing about

Google quietly released something alongside the model that's worth more attention: the Gemma Skills Repository at github.com/google-gemma/gemma-skills. It's a library of "skills" — pre-built capabilities that agents can compose — designed specifically for Gemma.

This is Google's answer to Anthropic's Skills system, and it's a signal that the agent-building game is now firmly a model-family-level competition, not a model-level one. The differentiator isn't "we have a 12B model" anymore. It's "we have a 12B model plus a thousand working agent patterns you can copy."

If you're building anything agent-shaped, the right move is to spend 30 minutes browsing the skills repo even before you download the model. The patterns there will save you weeks of trial-and-error.

The license and what it means for commercial use

Per Google's announcement, Gemma 4 ships under Apache 2.0. That's a meaningful change from earlier Gemma releases, which used a custom "Gemma license" (also commercial-friendly but more restrictive). Apache 2.0 means you can ship a commercial product on top of Gemma 4 12B. You can fine-tune it and sell the fine-tune. You can distribute it embedded in your application. You don't owe Google anything except to keep the license notice in your source distribution. (If you want to be paranoid — and you should, before building a company on it — pull the model card directly from Hugging Face and have your lawyer read it.)

The permissive licensing is part of why the 150M downloads number isn't a fluke. The license is the kind you can hand to a lawyer and get a "yes, ship it" answer in five minutes.

The trade-offs nobody will mention

It's not all good news. A few honest caveats:

• The 12B parameter count is a target, not a guarantee of capability. Compared to a 70B model, the 12B will be dumber on hard reasoning tasks. If you need the model to write production code from a vague spec, you'll want a bigger one. For "look at this and tell me what's wrong," 12B is plenty.
• Lighter encoders don't mean "free." The matrix multiplication for vision is cheap, but the audio projection is still doing real work. Expect memory usage to scale with how much audio you feed it.
• The benchmarks are Google's. "Performance nearing the 26B MoE at less than half the memory" is a claim, not an independent measurement. The community will publish independent benchmarks within a week, and those are the ones to trust.

What to do today

If you have a 16GB Mac or PC and 30 minutes:

# Install Ollama (one-time, https://ollama.com)
ollama pull gemma4:12b
# Start it as a server
ollama serve
# In another terminal, try the multimodal API
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "Describe this image and tell me what app I have open.",
  "images": ["screenshot.png"]
}'

That's it. You now have a multimodal model running locally that fits in your laptop's memory. Two years ago this needed a $10,000 workstation. Yesterday it needed a model. Today it needs a curl command.

The barrier to running useful multimodal models locally has dropped substantially. The next interesting question is what gets built now that anyone with a laptop can answer it.

Advance Copy - My first published app in Google Play

It's been a while since my last post.
Recently I had published my first app in Google Play - Advance Copy.

Logo from my app.

Advance Copy monitoring copied text and identify url. If there is any url, there will be a pop up screen to allow user to open in browser or share with other apps.

This is helpful for those apps that don't link up url. It is another shortcut to open browser or sharing what you have copied to another app.

Hope to see some comments here after you have download so that I can improve on the app.

Thank you.

Free Screen Capture Program by VB.NET

       My new program coded in VB.Net called SCapture. SCapture is a screen capture program with the following function in capturing: 

1. Capture the screen with a fixed Rectangular size.
2. Capture the screen with an adjustable Rectangular.
3. Capture an active window.
4. Capture full screen.

Beside that, it also has setting to save the captured image in:

1. Edit with paint 
2. Copy to Clipboard for Paste
3. Save in Directory

Here is a video that shows how it works.

In this post, I will explain about how the concept that I use in this program.

       

      To capture the program with rectangular size (also for adjustable size), once capture button is clicked or when shortcut key is pressed, a window form with a Picture box appear. The picture box show the screen as image and just simple mouse click and drag will draw a rectangular. In adjustable mode, the rectangular can be adjust after drew.

In later post, I will show my coding (Only if I got some reviews in comments) . For those who want to try this SCapture program, you can download it from my website. Please feel free to leave comments. Thank you.

Simple Tic Tac Toe game for Gadget

As you can see from my Gadget sidebar, there is a Tic Tac Toe game. Anyone of you can have it now.
Just follow the following guide.

1) Add a html/javascript gadget to your sidebar. (or anything that can used for javascript)
2) Add this line into it :

3) Save and it all done, a tic tac toe game in your sidebar for others to play.

This tic tac toe game did not have a pro computer. All steps are randomly pick by computer and it did not store any scores after you refresh the page. It only store the scores in client's browser (the one that playing the game) and it reset after refresh.

Besides that, this tic tac toe game can only be used once in a page. I didn't manage it to be multiple. If multiple in a page, there might be some problems.

Please feel free to update it to your blog/website. Please leave a comment if you like this.