W43: 12–18 October 2026. By Nicolas Dao · published 19 October 2026. RSS

Lambda becomes a web server, and AI learns to just decide

Six things worth your time from 12 to 18 October 2026. AWS finally lets one Lambda serve a whole web app (not in Sydney yet), a new kind of AI model answers yes-or-no questions for a sliver of an LLM's price, and Neon turns any SQL query into a live feed. Plus durable workflows on Lambda grow up, Aurora reads your data lake directly, and an open model gets close to Claude Sonnet for a twentieth of the cost.

92 candidates84 searches7 research agents6 worth your time

This week in 30 seconds

The problem you know, the fix, who ships it, and what it's worth. Each card links to the detail.

01 Watching. The pain: Your API is a swarm of tiny Lambdas. Every concurrent request opens its own Postgres connection, so a traffic spike runs the database out of connections and you end up bolting on RDS Proxy. The fix: One ordinary Node.js web server (Express, Hono) serves up to 64 to 128 requests at once from a single environment, sharing one connection pool. You pay for active CPU, not for time spent waiting. Lambda Web Functions by AWS: One normal web app instead of dozens of functions, with a shared database pool. The catch is that it isn't in Sydney. Medium risk. The details on Lambda Web Functions
02 Watching. The pain: You use a full chat LLM to answer simple questions inside your app (is this ticket urgent, which team owns it, is this spam). Each answer takes seconds, costs frontier prices, and comes back as text you have to parse and can't threshold. The fix: A decision model takes your data and typed questions (yes or no, pick one, score) and returns answers with probabilities and a confidence, in a few hundred milliseconds, for a few cents per million input tokens. It never writes text. Decision models (Jev, and Cloudflare's Clef) by TypeSafe AI and Cloudflare: A new category, five weeks old. TypeSafe's Jev started it and shipped 1.14 this week, but it's an early-access preview. Cloudflare's open-weight Clef answers the same questions on Workers AI. High risk. The details on Decision models (Jev, and Cloudflare's Clef)
03 Watching. The pain: To show live data (a dashboard, a feed, an order list) you either poll the database every few seconds or run a separate realtime layer, with its own permissions, and keep it in sync with Postgres. The fix: Neon Realtime streams the result of any read-only SQL query to the browser over a WebSocket and updates it as transactions commit, straight from the Postgres you already have. Neon Realtime by Neon (Databricks): Live queries with no second system to keep in sync. It's free during the beta, but not in Sydney and with no row-level security yet. High risk. The details on Neon Realtime
04 Worth a pilot. The pain: Retries in an SQS-to-Lambda pipeline only work if the visibility timeout, max receives and dead-letter queue are tuned just right, and a failure in step 3 re-runs steps 1 and 2. The fix: A durable function is the workflow written as plain code. Each call is a step that's saved once it succeeds and retried with your backoff when it fails. Finished steps never run again, and waits cost nothing. Lambda durable functions by AWS: This week, AWS raised the limits tenfold and made the Go SDK generally available. It's now big enough for real pipelines and worth a pilot. Medium risk. The details on Lambda durable functions
05 Baseline Worth a pilot. The pain: Joining live app data in Postgres with years of history in your S3 data lake means a reverse-ETL job that copies data back, or a separate Athena query stitched together in your code. The fix: Aurora PostgreSQL now has DuckDB built in. Declare the lake's Parquet or Iceberg tables (including S3 Tables) as foreign tables, and one SQL query joins them with your live rows. Aurora PostgreSQL reads Iceberg and Parquet by AWS: No extra charge, generally available in every commercial Region, and read-only. It launched on 30 September, before this report existed. Low risk. The details on Aurora PostgreSQL reads Iceberg and Parquet
06 Worth a pilot. The pain: High-volume AI features (classifying, extracting, summarising, agent loops) run on a frontier model because nothing cheaper was good enough, and the bill grows with every user. The fix: An open-weight model released on 17 October scores about 80% of Claude Sonnet 5.5 on an independent benchmark, for about 5% of the cost per task, and a dozen hosts serve it through OpenRouter. DeepSeek V4.1 Flash 1017 by DeepSeek: Close to Sonnet, not equal, for a twentieth of the price. Worth testing on your bulk workloads. Medium risk. The details on DeepSeek V4.1 Flash 1017

01 Watching. Medium risk.

Lambda Web Functions by AWS

One normal web app instead of dozens of functions, with a shared database pool. The catch is that it isn't in Sydney.

The pain: Your API is a swarm of tiny Lambdas. Every concurrent request opens its own Postgres connection, so a traffic spike runs the database out of connections and you end up bolting on RDS Proxy.

The fix: One ordinary Node.js web server (Express, Hono) serves up to 64 to 128 requests at once from a single environment, sharing one connection pool. You pay for active CPU, not for time spent waiting.

What it is

AWS renamed every Lambda you have to "Event Functions" and added a second kind: Web Functions. A Web Function runs an ordinary Node.js web server (node server.js, Express, Hono). One environment handles up to 128 requests at the same time (64 by default), instead of one request per Lambda instance. You're billed for requests, active vCPU time and the memory the environment holds, so time spent waiting on Postgres or an LLM barely costs anything. CloudFront can now use a Web Function as an origin, which gives you edge TLS, caching, a custom domain and WAF. Origin access control locks it so only your distribution can call it.

Before and after

Before: a function per route, each behind a function URL. A spike of 1,000 requests means up to 1,000 Lambda instances, each with its own database connection, and Postgres runs out.
After: one Hono or Express app per domain, behind CloudFront. Each environment shares one pg pool, so connections follow environments, not requests. RDS Proxy may become unnecessary.

The catch for Australian clients

Sydney isn't one of the five launch Regions (us-east-1, us-east-2, us-west-2, Tokyo, Ireland), so a Sydney database means every query crosses an ocean. There's a lead: Aidan Steele ran a multi-Region endpoint with a replica in ap-southeast-2 and reports that requests from Melbourne executed in Sydney. AWS's docs neither confirm nor deny that Sydney can be a replica, and the home Region (control plane, logs) must still be a launch Region. There's a second catch, and this one AWS does document: multi-Region endpoints can't use a VPC connector ("egress network connectors only with HomeRegion endpoints"). So a Sydney replica can reach Neon or any database with a public endpoint, but not an Aurora or RDS cluster inside your VPC. Test it yourself before you promise it to a client.

Gotchas, with fixes

Up to 128 requests share one process, so a module-level "current user" variable leaks between users. Keep request data on the request (or in AsyncLocalStorage), and audit globals before you merge functions.
Your server must listen within 10 seconds on the port Lambda gives it, or requests fail even though the deploy shows Active. Smoke-test after every deploy.
Over the limits you get HTTP 429, not a queue. Retry with backoff, and set rateLimit to protect the database.
Infrastructure as code: Pulumi works only through @pulumi/aws-native (v1.82+), and the Terraform AWS provider doesn't support it yet (issue 50429).

Cost

The us-east-1 rates are $0.30 per million requests, $0.0000276944 per vCPU-second and $0.0000036667 per GB-second. AWS's example of 15 million requests a month comes to $25.78. For a typical API it costs about the same as classic Lambda. The reason to move isn't price: it's the connection pool and a simpler app.

My verdict

Still watching, as in the stack. It's the right direction for Postgres-backed APIs, but it's a week old, has no home Region in Sydney and no Terraform support. Pilot it now only for workloads whose users and data sit in a launch Region.

02 Watching. High risk.

Decision models (Jev, and Cloudflare's Clef) by TypeSafe AI and Cloudflare

A new category, five weeks old. TypeSafe's Jev started it and shipped 1.14 this week, but it's an early-access preview. Cloudflare's open-weight Clef answers the same questions on Workers AI.

The pain: You use a full chat LLM to answer simple questions inside your app (is this ticket urgent, which team owns it, is this spam). Each answer takes seconds, costs frontier prices, and comes back as text you have to parse and can't threshold.

The fix: A decision model takes your data and typed questions (yes or no, pick one, score) and returns answers with probabilities and a confidence, in a few hundred milliseconds, for a few cents per million input tokens. It never writes text.

The idea, in one paragraph

Most "AI" calls in business apps aren't conversations. They're decisions: urgent or not, which team, spam or not, how severe. Sending those to a chat model is slow and expensive, and you get prose back. A decision model is built for exactly this. You send the state (the ticket, the email, the screenshot) and a set of typed questions: noul (yes or no, as a probability), choice (pick one of your labels) or score (a position on your scale). You get back answers with probabilities and a calibrated confidence. Your code acts on its own above a threshold, and sends the unsure cases to a human or a bigger model.

Jev, the one that started it

Jev, from TypeSafe AI, opened the category in early access on 15 September. Version 1.14 shipped as a preview on 14 October, with better multilingual accuracy, a bounding-box answer type and longer context. The headline price is $0.042 per million input tokens. The adoption story is real: it's on the Vercel AI Gateway and in LangChain.

Now the part you need to read before you build on it:

It's early access, and 1.14 is a preview. The jev-latest alias moves to 1.14 around 21 October. Images and long context sit behind "danger zone" headers that TypeSafe says aren't production-ready.
No stability policy is published yet. TypeSafe promises 60 days' notice before retiring 1.13 and 30 days for 1.14, with a formal policy "to come".
The company is two years old, the product five weeks. TypeSafe spent about two years in stealth and reportedly raised an $870M Series A at a $7.5B valuation on 9 October. Plenty of money, almost no track record.
The benchmarks are disputed. Both vendors run their own, and a researcher has claimed the core idea is his uncredited earlier work. That report is third-party, and TypeSafe hasn't responded.

Cloudflare's answer

Two weeks earlier, Cloudflare released Clef: decision models with the same request shape, open weights under Apache 2.0, served on Workers AI and published on Hugging Face. Clef Flash costs $0.038 per million input tokens, with output free. That's slightly cheaper than Jev, and its median latency on Cloudflare's tests is 38.8 ms against Jev's 524 ms. Cloudflare's own benchmark has Clef beating Jev on most tasks (for example, 94.2 against 79.7 on BANKING77). Jev wins on two. These are vendor numbers, not independent ones.

OpenAI (a Decisions API in beta), Microsoft, Perplexity and AWS's Strands project all shipped their own versions within a month. When everyone copies an idea that fast, the idea is real.

My verdict

Watching, with a clear direction: the category is worth knowing about now. If you need a decision model in production today, start with Clef Flash on Workers AI. It has open weights (your exit path), published per-model prices and the same API shape. Keep Jev to experiments until it publishes a stability policy and leaves preview. Whichever you pick, measure accuracy on a labelled sample of your own traffic first.

Gotchas, with fixes

jev-latest will quietly move to a preview model. Pin jev-1.13.0 (or a named version) in production.
Vendor lock-in on a five-week-old API: wrap calls in a small adapter. Jev and Clef share a request shape, so switching is cheap.
A confidence score you don't act on is wasted. Set thresholds per question, and route low-confidence answers to a frontier model or a person.

03 Watching. High risk.

Neon Realtime by Neon (Databricks)

Live queries with no second system to keep in sync. It's free during the beta, but not in Sydney and with no row-level security yet.

The pain: To show live data (a dashboard, a feed, an order list) you either poll the database every few seconds or run a separate realtime layer, with its own permissions, and keep it in sync with Postgres.

The fix: Neon Realtime streams the result of any read-only SQL query to the browser over a WebSocket and updates it as transactions commit, straight from the Postgres you already have.

What it is

You write a read-only SELECT in your backend: joins, aggregates and window functions are all fine. After your own auth check, you "seal" it into a short-lived token. The browser subscribes with that token over a WebSocket. It gets the full result first, then batches of changes as transactions commit, applied atomically. Inside Neon, a live-query engine reads the logical replication stream and works out which subscriptions each write affects. Live queries don't hold database connections.

Before and after

Before: poll every few seconds, or run a realtime layer (a WebSocket server, Pusher, Supabase Realtime, a Durable Object) that mirrors Postgres, with its own permissions model and its own sync bugs.
After: subscribe to the SQL query itself. There's no mirror to keep in sync, and writes go through your normal path.

Side by side with Durable Objects

These do different jobs; one doesn't replace the other. For my live auction example I still pick a Durable Object per lot. It's the single referee: it processes each bid in turn and pushes the result to every watcher in order. Neon Realtime is a live view over Postgres. It's ideal for dashboards, feeds and lists, where Postgres stays the source of truth and nobody needs a referee. Neon publishes no fan-out or latency numbers yet, so a head-to-head isn't possible.

Gotchas, with fixes

There's no row-level security. Anyone holding the Realtime secret can seal any query. Authorize in your backend, take the user id from the verified session, and never expose the secret to the browser.
Sealed queries expire after 60 seconds. Renew them before they expire. The docs' scheduler renews 10 seconds early.
After a reconnect, the whole result is replaced, not resumed. Render from the new rows, and don't keep local deltas.
A fatal connection error kills every subscription on that client. Create a new client and subscribe again.
Starting a live query can wake a database that scaled to zero, and the streamed data counts as egress.

My verdict

Watching. It's a beta, its protocol is still changing, there's no row-level security, and the closest Region to Sydney is Singapore. I'll look again when it reaches Sydney and publishes its limits and post-beta pricing. Until then, Durable Objects stay my pick for anything live.

04 Worth a pilot. Medium risk.

Lambda durable functions by AWS

This week, AWS raised the limits tenfold and made the Go SDK generally available. It's now big enough for real pipelines and worth a pilot.

The pain: Retries in an SQS-to-Lambda pipeline only work if the visibility timeout, max receives and dead-letter queue are tuned just right, and a failure in step 3 re-runs steps 1 and 2.

The fix: A durable function is the workflow written as plain code. Each call is a step that's saved once it succeeds and retried with your backoff when it fails. Finished steps never run again, and waits cost nothing.

What it is, in plain words

A durable function is an ordinary Lambda written with a Durable Execution SDK. You wrap each risky call in a step. Lambda saves each step's result, and if the function crashes, times out or a step fails, it re-runs the function from the top but skips every finished step. Only the failed one is retried, with the backoff you choose. A wait pauses the whole run, for seconds or up to a year, at no compute charge.

What changed this week

13 October: the limits went up tenfold. A run can now have 30,000 operations (was 3,000), and a checkpoint can hold 1 MB (was 256 KB). That's enough for long, real pipelines.
15 October: the Go SDK is generally available, alongside Node.js, Python, Java and .NET.
Also 13 October: Temporal can now run its workers on Lambda, as a public preview (see "Looked at, skipped").

Before and after, for the SQS retry pain

Before: SQS feeds Lambda. You hand-tune the visibility timeout (at least six times the function timeout), maxReceiveCount and a dead-letter queue. A failure in step 3 redelivers the whole message, so steps 1 and 2 run again. Or you reach for Step Functions and a JSON state machine.
After: SQS still buffers, but the consumer is a durable function. Each call (enrich, write to Postgres, notify) is a step with its own retry rule. Finished steps never re-run, and a wait replaces delay queues. The dead-letter queue becomes a safety net instead of your retry mechanism.

Gotchas, with fixes

Retries are billed: each step retry counts as an operation ($8 per million operations in US East; Sydney prices aren't published). Retry only on transient errors.
A run triggered straight from SQS must finish within 15 minutes. For longer jobs, have a thin Lambda start the durable function asynchronously, and give that function its own dead-letter queue.
Replays re-run your code from the top, so Date.now(), random ids or a card charge outside a step take a different path, or run twice. Put every side effect and every random value inside a step, and make steps idempotent.
Changing step names while runs are in flight breaks replay. Invoke a version or alias, never $LATEST, in production.

My verdict

From watching to worth a pilot. With the new limits, it's the cleanest answer I've seen to the SQS retry pain, and it all stays on one AWS bill. It isn't a default yet: Sydney availability isn't confirmed, and only the Pulumi support is verified (durableConfig on aws.lambda.Function).

05 Baseline Worth a pilot. Low risk.

Aurora PostgreSQL reads Iceberg and Parquet by AWS

No extra charge, generally available in every commercial Region, and read-only. It launched on 30 September, before this report existed.

The pain: Joining live app data in Postgres with years of history in your S3 data lake means a reverse-ETL job that copies data back, or a separate Athena query stitched together in your code.

The fix: Aurora PostgreSQL now has DuckDB built in. Declare the lake's Parquet or Iceberg tables (including S3 Tables) as foreign tables, and one SQL query joins them with your live rows.

Baseline context: Launched 30 September 2026, before this week. It's here because it matters, not because it's new.

Why it's here even though it launched on 30 September

This report didn't exist on 30 September, and this launch matters to anyone with a data lake on S3. So here it is, labelled as baseline context, not this week's news. The DuckDB headlines you may have seen this week are a late rehash: AWS bought DuckLabs in August (the deal closed on 31 August), and DuckDB 2.0 still isn't out (21 October, tentatively).

What it is

Aurora PostgreSQL now has DuckDB embedded in the server. You enable the aurora_analytics extension and declare a foreign table pointing at an S3 URI (Parquet), a Glue table or an S3 Tables (Iceberg) table. Postgres can then join it with your live tables in one query, with predicate pushdown, column pruning, a local cache and Iceberg time travel. It's read-only, and there's no extra charge: you pay for the Aurora compute and the S3 requests.

Before and after

Before: a reverse-ETL job copies lake data back into Postgres, duplicated and drifting, or you run a separate Athena query and stitch the results together in application code.
After: declare the foreign table once, and one SQL statement joins this month's live orders with five years of history from the lake.

Side by side with Athena

Use Aurora for app-facing joins and enrichment: small to medium slices of the lake next to live rows, over the endpoint your app already uses. Use Athena for big scans, ad hoc analysis by many people, and writing to Iceberg. That matches my data-lake guide: this adds to Athena, it doesn't replace it.

Gotchas, with fixes

The launch blog skips a required step. Set aurora_analytics.enabled = true in a custom cluster parameter group, ideally when you create the cluster: switching parameter groups later needs a reboot.
A cluster in private subnets can't reach S3 or Glue. Add an S3 gateway endpoint and a Glue interface endpoint, which also avoids paying for NAT data processing.
Joins with local varchar(n), jsonb or low-precision timestamp columns fall back to slow scans. Cast in the query (col::text), and check EXPLAIN VERBOSE.
Analytical scans compete with your app's queries. Run them on a dedicated reader.

My verdict

Worth a pilot on any Aurora PostgreSQL 17.11+ or 18.6+ cluster that sits next to a lake. It's generally available, free to enable, and removes a whole class of ETL jobs.

06 Worth a pilot. Medium risk.

DeepSeek V4.1 Flash 1017 by DeepSeek

Close to Sonnet, not equal, for a twentieth of the price. Worth testing on your bulk workloads.

The pain: High-volume AI features (classifying, extracting, summarising, agent loops) run on a frontier model because nothing cheaper was good enough, and the bill grows with every user.

The fix: An open-weight model released on 17 October scores about 80% of Claude Sonnet 5.5 on an independent benchmark, for about 5% of the cost per task, and a dozen hosts serve it through OpenRouter.

The numbers

DeepSeek released V4.1 Flash 1017 on 17 October as open weights under the MIT licence, with a 1M-token context. On the independent Artificial Analysis Intelligence Index it scores 45, against 56 for Claude Sonnet 5.5. That's about 80% of the score, at $0.26 per index task against $5.46, about 5% of the cost.

For 1 million requests of 2,000 input and 500 output tokens, at list prices:

Model	Cost
Claude Sonnet 5.5 ($2 / $10 per million tokens)	$9,000
DeepSeek, DeepSeek's own endpoint, peak hours	$1,200
DeepSeek, DeepSeek's own endpoint, off-peak	$600
DeepSeek on DeepInfra	$343

DeepSeek tends to write more, so expect real output tokens, and the bill, to come in somewhat higher.

Where it fits

It's "close, not equal". Use it for high-volume work: classification, extraction, summarising and agent loops. Keep a frontier model for the hardest reasoning. The open weights are the other win: a dozen providers host it, so you aren't locked into one.

Gotchas, with fixes

DeepSeek's own endpoint isn't on OpenRouter's zero-data-retention list, which matters for client data. Route only to hosts that are, by setting provider: { zdr: true }.
The off-peak discount applies on DeepSeek's endpoint only. Its peak hours are Monday to Friday, 01:00–04:00 and 06:00–10:00 UTC, which is midday and evening in Sydney. Third-party hosts charge a flat rate.
Several cheap hosts cap output at 131K tokens. Check before you rely on very long outputs.
The headline benchmarks are DeepSeek's own. Trust the independent index, and better still, your own evaluation.

My verdict

Worth a pilot through OpenRouter, on a zero-data-retention host, for your bulk workloads. It's the clearest "the same job, much cheaper" story of the week. I haven't checked data residency for Australian clients.

Looked at, skipped

What else made noise this week, and why it didn't make the cut.

OpenRouter is joining Stripe by OpenRouter and Stripe
Not new: the deal was announced on 19 August, and this week's stories only re-cover a reported $7.5B price. OpenRouter says nothing changes for customers, and it stays my pick. Still, put your own proxy in front of it with a configurable base URL, so you can switch gateways if the terms ever change.
OpenRouter Private Endpoints and Armor by OpenRouter
Private Endpoints is an enterprise add-on with no published price. Armor, a beta guard on agent tool calls, adds about 300 ms per call. Neither is worth changing anything for yet.
Better Auth 1.8 beta by Better Auth
A beta with breaking changes to device-code and OAuth-provider flows, so leave it alone. The critical advisory you may have read about (GHSA-965c-763c-88jm) was published on 30 September and fixed in 1.7.7. Be on 1.7.11, never below 1.7.7.
Microsoft-Decision-1 by Microsoft
Another decision model, priced the same as Jev. It doesn't clear the "10 to 100 times better" bar I hold Microsoft to.
Gemini 4 Argon by Google
Strong, but at $2 / $10 per million tokens it costs the same as Claude Sonnet 5.5 today, and Google's pricing page says it doubles on 1 December. Not a "same but cheaper" story.
Temporal Serverless Workers on Lambda by Temporal
A public preview with no published limits or pricing. If you want durable execution on AWS, Lambda durable functions (above) keep it all on one bill.
Cloudflare Void and Ryan Dahl joining Workers by Cloudflare
Interesting strategy news for the Workers runtime, but no product change you can use this week.
AWS Well-Architected Agent by AWS
A preview agent that reviews your workloads against the Well-Architected Framework. I don't follow the framework to the letter, and an agent won't change that.
Aurora and RDS for PostgreSQL 19 RC1 by AWS
A release candidate in the preview environment only, and Postgres 19 itself slipped to November. Test your extensions when it ships, not now.
OpenCode breach report by Anomaly
A single secondary source said stored provider keys may have been exposed, and I couldn't confirm it. If you used OpenCode with saved keys, rotate them anyway.

For the geeks

Examples and code for the items above.

Lambda Web Functions: one Hono app with a shared Postgres pool

Adapted from AWS's Hono sample, with a pg pool added:

// index.js  ("type": "module"; npm i hono @hono/node-server pg)
import { serve } from '@hono/node-server';
import { Hono } from 'hono';
import pg from 'pg';

// One pool per environment, shared by up to 64-128 concurrent requests.
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL, max: 10 });

const app = new Hono();
app.get('/api/health', (c) => c.json({ status: 'ok' }));
app.get('/api/users/:id', async (c) => {
	const { rows } = await pool.query('select id, name from users where id = $1', [c.req.param('id')]);
	return rows[0] ? c.json(rows[0]) : c.json({ error: 'not found' }, 404);
});

// Lambda gives the host:port to listen on; you have 10 seconds to start listening.
const [hostname, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT ?? '127.0.0.1:8080').split(':');
serve({ fetch: app.fetch, hostname, port: Number(port) });

Decision models: triage a support request with Clef on Workers AI

From the Workers AI Clef model page:

export interface Env { AI: Ai }

export default {
	async fetch(request, env): Promise<Response> {
		const response = await env.AI.run('@cf/cloudflare/clef', {
			model: 'clef',
			state: 'Checkout has been failing for every customer for the last hour.',
			questions: {
				urgent: { type: 'noul', instructions: 'Is this support request urgent?' },
				team: {
					type: 'choice',
					instructions: 'Which team should handle this request?',
					criteria: {
						billing: 'Payments, invoices, and refunds',
						technical: 'Outages, errors, and configuration',
						sales: 'Plans and upgrades',
					},
				},
				severity: {
					type: 'score',
					instructions: 'How severe is the customer impact?',
					criteria: ['No impact', 'Minor', 'Major', 'Critical'],
				},
			},
		});
		// answers.urgent: probability · answers.team: label + probabilities · answers.severity: weighted score
		return Response.json(response);
	},
} satisfies ExportedHandler<Env>;

From the Neon Realtime quickstart:

// backend (trusted): seal a query after your own auth check
import { createRealtime } from '@neon/realtime/server';
import { drizzleAdapter } from '@neon/realtime-drizzle';

export const realtime = createRealtime({
	secret: process.env.NEON_REALTIME_SECRET!,
	db: 'neondb',
	adapter: drizzleAdapter(),
});
const sealedQuery = await realtime.seal({ query: messagesQuery(userId, channelId) }); // userId from the session

// browser: subscribe with the sealed query fetched from your backend
import { createRealtimeClient } from '@neon/realtime/client';
import { drizzleParsers } from '@neon/realtime-drizzle/client';

const client = createRealtimeClient({ url, parsers: { ...drizzleParsers } });
const subscription = client.subscribe(sealedQuery);
subscription.onChange(render); // { data, status, error }

Lambda durable functions: steps and a free wait

From the AWS getting-started guide (Node.js):

import { withDurableExecution } from '@aws/durable-execution-sdk-js';

export const handler = withDurableExecution(async (event, context) => {
	const { orderId } = event;
	const validation = await context.step(async () => ({ orderId, status: 'validated' }));
	const payment = await context.step(async () => ({ orderId, status: 'paid', amount: 99.99 }));
	await context.wait({ seconds: 10 }); // suspends the run, no compute charge
	const confirmation = await context.step(async () => ({ orderId, status: 'confirmed' }));
	return { orderId, status: 'completed', steps: [validation, payment, confirmation] };
});

Aurora: join live rows with Parquet history in one query

From the AWS launch post:

CREATE EXTENSION aurora_analytics;

CREATE FOREIGN TABLE transaction_history ()
SERVER aurora_analytics_server
OPTIONS (location 's3://my-bucket/finance/transaction_history.parquet', format 'parquet');

SELECT merchant, amount, transaction_date, 'recent' AS source
FROM recent_transactions WHERE customer_id = 'C-1001'
UNION ALL
SELECT merchant, amount, transaction_date, 'historical' AS source
FROM transaction_history
WHERE customer_id = 'C-1001' AND transaction_date >= CURRENT_DATE - INTERVAL '5 years'
ORDER BY transaction_date DESC
LIMIT 15;

DeepSeek through OpenRouter, on zero-data-retention hosts only

Using OpenRouter's OpenAI-compatible API. The provider-routing options come from its docs, and I haven't run this against the live API:

from openai import OpenAI

client = OpenAI(base_url="https://openrouter.ai/api/v1", api_key="<OPENROUTER_API_KEY>")

completion = client.chat.completions.create(
    model="deepseek/deepseek-v4.1-flash-1017",
    messages=[{"role": "user", "content": "Summarise this support ticket in one sentence."}],
    extra_body={"provider": {"zdr": True, "sort": "price"}},
)
print(completion.choices[0].message.content)

Window 12 to 18 October 2026 (UTC). Scanned the AWS What's New and News Blog feeds, the Cloudflare changelog and blog, InfoQ, Hacker News, GitHub trending, the release notes of every tool in the stack, X and Google News, plus open searches across every concern in the catalog: 92 candidates, 6 kept. Reddit blocked our crawler this week. Not exhaustive: if it matters and it's missing, tell me.

Want this stack in your AWS account?

Cloudless Labs is a Sydney consultancy. We migrate on-premises systems to AWS, build serverless apps on this stack, and coach teams to ship with Claude Code and Codex.

Lambda becomes a web server, and AI learns to just decide

This week in 30 seconds

Lambda Web Functions by AWS

What it is

Before and after

The catch for Australian clients

Gotchas, with fixes

Cost

My verdict

Decision models (Jev, and Cloudflare's Clef) by TypeSafe AI and Cloudflare

The idea, in one paragraph

Jev, the one that started it

Cloudflare's answer

My verdict

Gotchas, with fixes

Neon Realtime by Neon (Databricks)

What it is

Before and after

Side by side with Durable Objects

Gotchas, with fixes

My verdict

Lambda durable functions by AWS

What it is, in plain words

What changed this week

Before and after, for the SQS retry pain

Gotchas, with fixes

My verdict

Aurora PostgreSQL reads Iceberg and Parquet by AWS

Why it's here even though it launched on 30 September

What it is

Before and after

Side by side with Athena

Gotchas, with fixes

My verdict

DeepSeek V4.1 Flash 1017 by DeepSeek

The numbers

Where it fits

Gotchas, with fixes

My verdict

Looked at, skipped

For the geeks

Lambda Web Functions: one Hono app with a shared Postgres pool

Decision models: triage a support request with Clef on Workers AI

Neon Realtime: seal on the server, subscribe in the browser

Lambda durable functions: steps and a free wait

Aurora: join live rows with Parquet history in one query

DeepSeek through OpenRouter, on zero-data-retention hosts only

Want this stack in your AWS account?