A certificate-trust failure that takes more than a browser update to fix, a second TypeScript compiler, and the SQL that sharded Postgres can now run.
Picked from 60 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Weak keys on eight eMudhra intermediate certificates let attackers forge certificates for any site. story 1 ↓
Cloudflare patched its own systems in about 26 hours. Your origin servers and custom trust stores still need your own updates. story 1 ↓
Cloudflare and VoidZero ported the TypeScript compiler to Rust as "tsrs", claiming up to 8x faster checking than Go-based TypeScript 7.0. story 2 ↓
tsrs also reports about 70% less memory with the same worker count. These are early benchmarks, and it must keep pace with Microsoft's codebase. story 2 ↓
PlanetScale's sharded Postgres, Neki, now handles cross-shard UPDATE and MERGE, supports pg_dump, and offers $50 instances. story 3 ↓
Neki's distributed INSERT ... SELECT got 76x faster, one of over 650 changes merged in its first month of preview. story 3 ↓
1/3Cloudflare· Christopher Patton· Oct 20
Weak keys on eight eMudhra intermediate certificates let attackers forge any site
The private keys behind eight eMudhra intermediate certificates were compromised, so anyone could forge a trusted certificate for any domain. Cloudflare patched its own services in about a day and says customers must update their own trust settings.
Why it matters · Certificate trust is spread across operating systems, language runtimes, libraries and container images, and this incident shows how hard it is to revoke trust quickly outside browsers.
Know this first
Context from the editor, not the article · 32 sec
1 · Intermediate certificates
Browsers and operating systems trust a short list of root certificate authorities (CAs). Roots sign intermediate certificates, and intermediates sign the certificates websites use. Anyone holding an intermediate's private key can issue a certificate for any domain, and clients will accept it as genuine.
2 · Trust stores
A trust store is the list of CA certificates a piece of software accepts. Browsers, operating systems, language runtimes such as Java and Python's certifi, and container base images often each ship their own. Updating one leaves the others unchanged.
3 · Revocation
2/3Cloudflare· Boshen Chen· Oct 20
Cloudflare and VoidZero port the TypeScript compiler to Rust as "tsrs"
Cloudflare, VoidZero and Owner.com are building tsrs, a line-by-line Rust port of the TypeScript compiler that tracks Microsoft's Go version. They say it type-checks up to 8x faster, uses about 70% less memory, and runs well in WebAssembly.
Why it matters · It's a case study in keeping a second implementation in sync with someone else's moving codebase, and in why the choice between garbage collection and Rust-style memory management matters for WebAssembly.
Know this first
Context from the editor, not the article · 29 sec
1 · What the TypeScript compiler does
tsc parses TypeScript, checks every type and reports diagnostics (errors and warnings). On large codebases this type checking takes much of the edit-and-build loop. Faster checking means shorter waits in CI pipelines and editors.
2 · TypeScript 7 is a Go port
Microsoft's TypeScript team rewrote the compiler from TypeScript/JavaScript into Go and shipped it as TypeScript 7. They reported roughly 10x faster checking and much lower memory use. It is the only port of the compiler so far that has succeeded.
3 · WebAssembly and garbage collection
3/3PlanetScale· Nick Van Wiggeren· Oct 20
PlanetScale's sharded Postgres, Neki, runs more SQL a month into preview
PlanetScale's Neki, a system that splits Postgres across many servers, has added read-only replicas, $50-a-month instances and Azure support. More multi-server SQL now runs unchanged, and bulk inserts are up to 76x faster.
Why it matters · Postgres has no built-in horizontal sharding, so the hard part is which ordinary SQL a sharding layer can run correctly across shards, and that list is growing.
Know this first
Context from the editor, not the article · 34 sec
1 · What sharding means
Sharding splits one logical database across many servers. Each server, or shard, holds a subset of rows, usually chosen by a key such as customer ID. Writes scale out, but queries touching rows on several shards need a coordinating layer to split, run and merge them.
2 · PlanetScale and Neki
PlanetScale is a hosted database company best known for running Vitess, the sharding system for MySQL built at YouTube. Neki is its sharded Postgres product. It opened to a public "platform preview" about a month before this post and is not yet production-ready.
3 · Metal instances
PlanetScale's "Metal" tier runs database nodes on NVMe SSDs attached directly to the machine, not on network-attached block storage such as AWS EBS. Local disks have lower latency, but data survives a node loss only because it is replicated to other nodes.
Revocation means withdrawing trust from a certificate before it expires. The classic tools are certificate revocation lists (CRLs) and OCSP lookups, but many non-browser clients check neither. Chrome instead pushes a compact, frequently updated blocklist called a CRLSet.
Image: Cloudflare
On October 19, 2026, Cloudflare learned that the private keys for eight 1 from eMudhra, an Indian certificate authority (CA), had been compromised. Browsers, operating systems and Cloudflare's own systems all trusted these certificates. Anyone holding one of those keys can create a certificate for any domain that clients will accept, and use it to impersonate servers and read or change traffic in transit. The post says the keys were "weak" but doesn't say how. Cloudflare says it found no exploitation on its services.
What broke
The problem is authentication, not encryption. 2 (Transport Layer Security, the protocol behind HTTPS) is still encrypting traffic correctly. What broke is the check that a certificate chains up to something trusted. That trust is spread across many places: OS certificate bundles, language runtimes, HTTP libraries, container base images and custom configurations. Each has to be updated separately, and running processes often need a restart before they notice.
Cloudflare's response
Cloudflare fixed outbound connections first, such as proxies connecting to customers' origin servers and services calling external APIs. In a forged-certificate attack, the client is the one that gets fooled. At the same time, it updated shared 3 and base images so dependent services could inherit the fix. Applications with bundled stores were handled one by one.
Oct 20, 02:00 UTC:4, Cloudflare's device client, updated on all platforms except the iOS Cloudflare One Agent, which is waiting on app review.
19:20 UTC: CDN and server-side 5 mitigations fully deployed, about 26 hours after Cloudflare learned of the problem.
Cloudflare says work is ongoing.
What customers should do
The post's advice is "look beneath the SDK": an SDK upgrade may not touch the library or runtime that actually checks certificates. Upgrade patched packages, including indirect dependencies, using a list kept by Mozilla's Dennis Jackson. Then rebuild images and restart services. Don't silence the certificate errors that follow by turning off verification. A passing browser or curl test proves nothing about an application that uses a different verifier, so test through the application's own TLS path.
The bigger lesson
Browsers fixed the problem almost instantly because they have quick-revocation channels like Chrome's 6, a revocation list Chrome downloads in the background. Most other software ships a static trust file. Patton points to projects like 7 that would push revocations and 8 keys to trust stores continuously. Certificate transparency is a set of public logs of every certificate CAs issue.
On October 19, 2026, at about 17:00 UTC, Cloudflare learned that the private keys for eight 1 issued by eMudhra, an Indian certificate authority, had been compromised. Browsers, operating systems and Cloudflare's own systems all trusted these certificates. The post says the keys "themselves are weak" but doesn't explain how. The result is clear, though: an attacker can mint a certificate for any domain that clients will accept, then use it to impersonate servers and read or change traffic in transit.
Christopher Patton's post covers how Cloudflare responded, what customers need to do, and what the incident says about how trust is distributed today. Cloudflare says its security review found no active exploitation on its services.
Why this is hard to fix
2 (Transport Layer Security, the protocol behind HTTPS) does two jobs: it encrypts traffic, and it authenticates the server. The encryption is fine here. The broken part is authentication. A client trusts a server's certificate if it chains up to a CA in the client's 3, and eight trusted links in those chains are now forgeable.
Removing them should be simple, but there is no single trust store. A typical service might check certificates through any of these:
the operating system's CA bundle
a language runtime's own bundle, such as Java's cacerts or Python's certifi
an HTTP library with built-in roots
a store copied into a container base image when it was built
a custom trust configuration someone wrote years ago
Each one has to be updated separately. Then the running process has to pick up the change through a reload, restart or redeploy, because many programs read their trust store only once, at startup.
What Cloudflare did
Cloudflare first fixed the services where forged certificates would do the most damage: those that use public certificates to authenticate remote endpoints. These include proxies connecting to customers' origin servers and applications calling external APIs. In a forged-certificate attack, the client is the victim. Anything Cloudflare connects out to could be impersonated.
At the same time, it updated shared foundations such as common trust stores and base images. That gave every service inheriting trust from them one fix to pick up. Each update was paired with the reloads, restarts and image deployments needed to make it take effect. Applications with bundled or custom trust stores were assessed and fixed one by one.
The timeline:
From awareness to full CDN deployment took about 26 hours. WARP is Cloudflare's device client, also sold as the 1.1.1.1 app. cloudflared is the daemon that connects private servers to Cloudflare without opening inbound ports. Zero Trust is Cloudflare's access-control product line, and Gateway is its filtering proxy. Cloudflare says Gateway users with an up-to-date client are protected automatically. The company also says remediation is still going on, with "much work still to be done."
What customers have to do
The post's main advice to developers is to "look beneath the SDK." An API client's SDK often hands certificate checks off to an HTTP library, the runtime or the OS. Upgrading the SDK alone may change nothing. The post recommends:
Upgrade affected packages, including indirect dependencies, using a crowdsourced list of patched packages kept by Mozilla's Dennis Jackson. Check the full dependency tree.
Rebuild container images, since trust stores get baked in when an image is built.
Reload, restart or redeploy so running processes actually load the new trust data.
Don't fix the certificate errors that appear after patching by turning verification off. That throws away the protection the patch was meant to restore.
The post also warns about testing. Jackson's test site offers browser checks and instructions for non-browser clients, but a result only covers the verification path you tested. A passing browser test says nothing about a background service. A passing curl test says nothing about an application that uses a different verifier. The only meaningful check runs through the application's own TLS path.
Origin servers are the main exposure customers have to handle themselves. Cloudflare can fix its proxies, but it can't fix the software customers run.
Why browsers had it easy
Patton points out that the damage was uneven. Browser vendors fixed the problem almost immediately. That's partly because each has only one application to update, but mainly because browsers have quick-revocation channels such as Chrome's 6. A CRLSet is a compact list of revoked certificates that Chrome downloads in the background, separate from browser updates. Distrusting a compromised intermediate means publishing a new list.
Most non-browser software has nothing like this. Its trust store is a static file that ships with a package or image and changes only when someone upgrades and redeploys. Cloudflare says it uses a quick-revocation mechanism for some of its products. It wants that model used more widely and points to projects like 7, which treat a trust store as data that is updated continuously. That data would include revocations and 8 keys, the public keys of the public logs where CAs record every certificate they issue. A static list of root CAs is not enough.
What the post leaves open
The post doesn't explain how the keys were weak, how the compromise was found, whether forged certificates exist in the wild, or what eMudhra or the root programs have done in response. It doesn't say which Cloudflare products use quick revocation or why the rest don't. It also gives no count of affected internal services or how much of the remediation is finished.
Remember
Upgrading an SDK may not change certificate checks; the real verifier may be a library, runtime or OS bundle.
Trust stores get baked into images and loaded at startup, so a fix needs rebuilds and restarts.
Browsers revoked trust fast through push channels like CRLSets; most server-side software has nothing similar.
WebAssembly (Wasm) is a portable bytecode that runs in browsers and sandboxes. A garbage-collected language like Go has to ship its own collector inside the Wasm binary. Rust frees memory at compile-time-known points, so it needs no runtime collector.
Cloudflare Workers
Cloudflare's serverless platform. It runs JavaScript and Wasm code in lightweight isolates at the network edge.
Benchmark chart: tsrs against TypeScript 7.0 and 7.1 beta, same worker count, comparing speed and memory.1 / 2
Cloudflare and 1, the company behind the Vite build tool, are working with Owner.com on tsrs, a Rust port of the TypeScript compiler. It is being developed inside 2, a set of fast JavaScript tools written in Rust. An experimental build is on npm (npx tsrs).
The authors stress that tsrs is not a fork. Microsoft's TypeScript team keeps control of the language, and tsrs tries to copy the official compiler's behaviour exactly.
The hard part: staying identical
A type checker has no short spec. TypeScript means whatever the reference compiler does, edge cases included. The TypeScript team sometimes prototypes a feature for years before settling on how to build it. A port that drifts "will eventually fall apart and become incompatible." According to the post, only one port has ever succeeded: Microsoft's own rewrite from TypeScript to Go, shipped as TypeScript 7.
Numbers
With the same number of 3 (parallel checking threads), tsrs is reported up to 8x faster and to use about 70% less memory than TypeScript 7.0. TypeScript 7.1 beta is already up to 2.5x faster than 7.0, partly from optimizations contributed back from tsrs, so the gap to the newest Go compiler is smaller. The authors say they matched TypeScript's default settings because other ports have advertised speedups measured on bigger machines. tsrs's own default adapts to the machine and is faster still, at the cost of more memory. No benchmark codebases or absolute times are given, so treat these as early, vendor-reported results.
Why Rust over Go
The main reason is 4 (Wasm), a portable bytecode for browsers and sandboxes. A Go program compiled to Wasm carries Go's garbage collector with it. Rust has no runtime collector, so a Rust Wasm module shares memory with its host more directly and uses less of it. That matters to Cloudflare, which runs code in Workers, its serverless platform. Small footprints let whole build toolchains run in sandboxes, in browsers, or on embedded devices.
The post also admits why this is happening now: AI models can do large ports in days, and many TypeScript ports have appeared as a result.
Keeping in sync
tsrs will merge with tsc-rs, a separate Rust port associated with Theo Browne. The aim is full coverage, including the 5 that editors rely on. Cloudflare plans the same sync process it uses for 6, its Next.js reimplementation. Every day, automated agents review upstream changes. Every night, the upstream test suite runs against the port, and agents propose fixes for any failures. Known differences, such as the order diagnostics are printed in, are supposed to shrink before a stable release.
Open questions: whether Oxc's planned refactoring will make line-by-line syncing harder, and whether the speedups hold up on real projects.
Cloudflare and 1, the company behind the Vite build tool and the 2 toolchain, have announced tsrs. It is a Rust port of the TypeScript compiler, built together with Max Schwenk of Owner.com. The project lives inside Oxc, a collection of fast JavaScript tools written in Rust: a parser, a linter (Oxlint), a formatter (Oxfmt) and more. The team says it is working "in close collaboration with the TypeScript team". An experimental build is on npm (npm install tsrs, then npx tsrs).
The post states plainly that tsrs is not a fork. Microsoft's TypeScript team keeps sole control of the language, and tsrs aims to reproduce the official implementation's behaviour exactly.
Why a port is hard to keep correct
A type checker has no short spec to implement against. TypeScript's semantics are effectively whatever the reference compiler does, including its inference heuristics, the order it resolves things in, and its edge cases. The post notes that the TypeScript team sometimes spends years prototyping a feature before choosing an implementation. A port that drifts even a little from those decisions "will eventually fall apart and become incompatible." The same problem shows up anywhere a second implementation chases a reference one, such as an alternative SQL engine copying PostgreSQL's quirks. The hard part is not the first translation but the ongoing work of tracking a moving upstream.
That is why the authors say earlier ports by others failed. The only success so far is the TypeScript team's own move from TypeScript to Go, released as TypeScript 7.
The numbers
The headline claim: with the same number of 3 (parallel threads checking different parts of the program), tsrs is up to 8x faster and uses about 70% less memory than TypeScript 7.0. The post also says TypeScript 7.1 beta is up to 2.5x faster than 7.0, and that some of those gains were contributed upstream from tsrs. So the gap between tsrs and the latest Go compiler is smaller than 8x. The post doesn't give a tsrs-versus-7.1 figure in the text; it is in the chart.
The authors address benchmark skepticism head-on. Other TypeScript ports, they say, have advertised speedups measured on bigger machines or with non-default settings. They say they worked with the TypeScript team so that both sides of their comparison use the same configuration. A second chart shows tsrs's default adaptive configuration, which sizes itself to the machine. It is faster again but uses more memory.
Caveats: the article names no benchmark codebases, gives no absolute times or hardware, and "up to" marks the best case, not a typical one. Treat these as early, vendor-reported results.
Why Rust, if Go already gave 10x?
The authors' main argument is 4, not raw speed. Compile Go to Wasm and the Go garbage collector and runtime go into the binary, sitting on top of a heap the host can't easily share. Rust has no runtime collector. Memory is freed at points the compiler knows about, so a Wasm module written in Rust can hand data back and forth with its host (a browser, or a Cloudflare Worker) more directly and with a smaller footprint. Cloudflare recently added native Rust support in Workers, its serverless platform, through an Emscripten target for 5, the tool that generates glue between Rust and JavaScript.
Cloudflare's argument is about scale. Run build and deploy pipelines over and over in small sandboxes, and memory per instance decides how many fit on a machine and where they can run at all. The authors see full development environments running sandboxed on Cloudflare, client-side in a browser, or on embedded and IoT devices. They also tie this to AI agents running toolchains in sandboxes. That is Cloudflare's product motive, not a technical claim the post tests.
The post also says frankly why this is happening now. Frontier AI models can do large ports "almost independently in a matter of days," and Rust and C++ ports of TypeScript have multiplied as a result. They range from faithful ports to "slopforks" to complete re-architectures.
How they plan to stay in sync
Maintenance is the part that matters most for correctness. The plan has three parts:
Consolidate. tsrs will merge with tsc-rs, a separate Rust port associated with Theo Browne, into one package. The goal is full feature coverage, including the Language Server Protocol (LSP, the interface editors use for completions and errors) and content mappers.
Track upstream continuously, copying the process Cloudflare uses for 6, its reimplementation of the Next.js web framework. Each morning an automated agent reviews upstream changes and opens tracking issues for anything that might matter. Each night the upstream test suite runs against the port to regenerate a compatibility matrix. When a test fails, agents find the matching code in both codebases, build a reproduction, port the relevant tests and propose a fix. In other words, the upstream test suite serves as the spec, and divergence is measured every day.
The authors admit tsrs is not identical yet. For example, it prints diagnostics in a different order. They aim to reduce such differences to a minimum before a stable release.
What's next and what's open
Near-term, Cloudflare wants tsrs inside its own Rust toolchain, for example for type-aware lint rules in Oxlint. These are rules that need full type information, which today usually means calling the TypeScript compiler from JavaScript. The Oxc team is already refactoring the ported code for speed, memory use and maintainability.
That refactoring sits in tension with the faithfulness goal. The more tsrs's internals move away from the Go code, the harder line-by-line syncing gets. The post doesn't say how they'll balance the two. Other open questions: how close an agent-driven nightly sync can really get to bug-for-bug compatibility with an upstream that changes constantly; whether the speedup survives on real-world projects; and how the TypeScript team, now optimizing its own memory use, will close the gap. The post presents that as collaboration, not competition.
Remember
Against TypeScript 7.1 beta, which is already up to 2.5x faster than 7.0, the 8x headline shrinks.
The case for Rust is mostly WebAssembly: there is no garbage collector to bundle, so memory per sandbox is smaller.
Correctness depends on running the upstream test suite against the port every night, effectively using it as the spec.
Large memory pages (typically 2 MB) that reduce the overhead of translating memory addresses for big shared-memory buffers.
Image: PlanetScale
PlanetScale has published its first progress report on Neki, its 1 Postgres, about a month into a public preview. Neki isn't yet called production-ready. The team says it has merged more than 650 changes since launch, mostly in the query layer.
Why the query layer matters
Postgres can't split a table across machines by itself. A sharded Postgres spreads rows across several shards, each running Postgres, and puts a coordinating router in front. Queries that touch one shard are simple. Queries that join, update or check conditions across shards must be split up, run and recombined without changing what the SQL means. Every construct the router can't handle is a rewrite a customer has to make before migrating.
PlanetScale says these now work:
cross-shard UPDATE ... FROM, DELETE ... USING and MERGE (writes driven by joins with other tables)
INSERT ... SELECT ... ON CONFLICT (upserts fed by a query)
The post doesn't say how these work across shards or what isolation cross-shard writes get. Teams checking correctness will need to test their own queries.
Tools and visibility
COPY ... TO STDOUT now works on sharded tables. Because pg_dump, the standard Postgres export tool, reads data through COPY, ordinary backup and export tools can now pull data out of Neki. A new EXPLAIN (NEKI_PG_PLAN) shows the distributed plan alongside each shard's own Postgres plan, in standard EXPLAIN format that viewers like pgAdmin and explain.depesz.com can display. That helps answer whether a slow query is slow because of routing or because one shard chose a bad plan.
Numbers
Distributed INSERT ... SELECT is about 76x faster than at launch, and COPY ingest about 5x faster. No absolute throughput or test setup is given, and a 76x gain mostly says the launch version had a very slow path.
Product additions
Read-only replicas per shard, aimed at serving users around the world
Smaller "3" nodes on directly attached NVMe disks, from $50/month, with 1/8 vCPU, 1 GB RAM and 10 GB of disk
Azure regions, alongside AWS and Google Cloud
A huge_pages setting, which backs Postgres shared memory with large memory pages and needs a restart
Terraform and command-line management for extensions and router parameters
This is a changelog meant to bring in evaluators. Still, it shows where the effort in a sharded Postgres goes: making ordinary SQL and existing tools work, more than storage.
PlanetScale has published its first progress report on Neki, its 1 Postgres. Neki has been in public "platform preview" for about a month and isn't yet called production-ready. The update covers two areas. The first is product features: read-only replicas, smaller and cheaper instances, Azure regions and tooling. The second, more interesting to engineers, is the query layer, the part that decides how much ordinary Postgres SQL runs correctly once the data is split across machines. The team says it has merged more than 650 changes since the preview opened.
Why the query layer is the hard part
Postgres has no built-in horizontal sharding. A sharded Postgres spreads a table's rows across several shards, here each running Postgres, and puts a coordinating layer in front. In Neki that layer includes a component PlanetScale calls the 2. Queries that touch a single shard are easy: the router sends them to the right shard and passes the answer back. The trouble is everything else.
Take a correlated EXISTS, a subquery that runs once per outer row and refers to that row: "find orders where there exists a refund for the same order." If orders and refunds are sharded on the same key, each shard can answer for its own rows. If they aren't, the router has to fetch rows from other shards, or rewrite the query, while keeping exactly the semantics Postgres would produce on one machine. Writes are harder still. UPDATE ... FROM and DELETE ... USING change rows in one table based on a join with another, and MERGE inserts, updates or deletes depending on whether rows match. When the joined rows sit on different shards, each of these turns into a distributed read-then-write. Every construct a sharding layer can't handle is a rewrite the customer has to make before migrating, so the list of supported SQL decides how hard adoption is.
What now works
According to PlanetScale, the following are now supported:
The post doesn't explain how any of these are implemented across shards. It doesn't say how LISTEN/NOTIFY fans out across shards, what isolation a cross-shard MERGE gets, or which places "almost anywhere" leaves out. Readers judging correctness will need the documentation or their own tests.
Getting data out, and seeing how queries run
COPY ... TO STDOUT now works on sharded tables in text, CSV and binary formats. That matters more than it sounds: pg_dump, the standard Postgres backup and export tool, reads table data through COPY. With it working, the usual export tools can read a sharded Neki database without a custom exporter. That makes leaving, or keeping logical backups, a normal operation.
For debugging, EXPLAIN (NEKI_PG_PLAN) prints Neki's distributed plan alongside the plan Postgres actually ran on each shard. The output follows Postgres's own EXPLAIN format, so existing plan viewers such as pgAdmin, DBeaver, explain.dalibo.com and explain.depesz.com can display it. This addresses a common pain with distributed databases: when a query is slow, you need to know whether the cause is the routing and merging, or one shard choosing a bad local plan.
Performance numbers
PlanetScale gives two measurements against the launch build. Distributed INSERT ... SELECT is about 76x faster, and COPY ingest is roughly 5x faster. No absolute throughput, data sizes or hardware are given. A 76x gain mostly says the launch version had a very slow path, perhaps funnelling rows through the router one at a time; the post doesn't say what changed.
Product additions
What to make of it
This is a vendor changelog, written partly to bring in evaluation customers. It is still a useful signal of where the hard work in a sharded Postgres lies. Little of the engineering effort described goes into storage or replication. Most of it goes into widening SQL coverage and making the system look like plain Postgres to existing tools. PlanetScale positions Neki for teams that expect to need sharding, online schema changes or upgrades without downtime. A careful evaluator should test their own queries, check isolation behaviour for cross-shard writes, and wait for the production-ready label.
Remember
For a sharded Postgres, how much SQL runs correctly across shards decides how hard migration is, more than storage does.
COPY support on sharded tables lets standard pg_dump exports work, so you don't need a custom exporter.
The speedups (76x, 5x) are relative to the launch build, with no absolute numbers or test setup given.
materialized views, which store a query's result as a table
exception handlers in 3, Postgres's procedural language
Read-only replicas per shard. Customers with global users wanted these so reads can be served closer to users. The post doesn't discuss replication lag or what consistency readers of a replica should expect.
Smaller 4 nodes, from $50/month. The smallest has 1/8 of a virtual CPU, 1 GB of RAM and 10 GB of NVMe disk attached directly to the machine. This lowers the cost of trying Neki, not of running it at scale.
Azure. Neki and Postgres databases can now be created in Azure regions, alongside AWS and Google Cloud.
Huge pages. Setting huge_pages to on makes Postgres back its shared memory with large memory pages (typically 2 MB, against the default 4 KB). That reduces the overhead of translating memory addresses on hosts with big buffer caches. It's available on supported cluster sizes and needs a restart.
Tooling. Extensions can be enabled by name through Terraform or the pscale command-line tool. Terraform provider v1.13.0 manages Neki router parameters. CLI v0.346.0 adds a "requires update" column showing which configuration changes are still waiting to be applied.
