DEV Community: DevOps Daily

Neon Is Becoming a Backend Platform, Not Just Postgres

DevOps Daily — Wed, 01 Jul 2026 15:30:52 +0000

For most of its life, Neon had a one-sentence pitch: serverless Postgres that branches like Git. You got a database that scaled to zero, forked in milliseconds, and charged you for what you used. Everything else (your compute, your file storage, your AI calls, your auth) you wired up somewhere else and pointed at the connection string.

In June 2026 that sentence got longer. Neon shipped a private preview that adds three new surfaces around the database: serverless Functions, S3-compatible Storage, and an AI Gateway for model calls. A fourth, Neon Auth, shows up in the templates. None of these is novel on its own. Functions look like Lambda, storage looks like S3, an AI gateway looks like a dozen other AI gateways. The reason it is worth a closer look is the through-line connecting them, and that through-line is the same primitive Neon already built its name on: branching.

This is an analysis of what actually shipped, what it replaces, and where it is still clearly a preview. I created a new project and deployed against it while writing this, so the specifics below are from the real thing, not the marketing page.

What shipped

Four pieces, all in private preview, all in AWS us-east-2, all for new projects only.

Neon Functions are Node.js compute deployed onto a database branch. You declare them in a neon.ts config file, write a standard Fetch-API handler (Hono is the recommended framework), and run neonctl deploy. Each branch gets its own function URL, the DATABASE_URL is injected automatically, and the function runs in the same region as the branch, so there is no cross-region hop to the database. They support streaming and long-lived connections (WebSockets, server-sent events), which is the deliberate split from request-scoped serverless: these are not for background jobs, they are for request/response and real-time work.

Neon Storage is S3-compatible object storage. Your existing AWS SDK, boto3, or aws CLI talk to it unchanged. The twist is that storage is scoped to a branch, so when you fork a database branch, its files fork with it.

Neon AI Gateway is a single credential that fronts models from Anthropic, OpenAI, Google, and a few open-source providers. The OpenAI and Anthropic SDKs work without code changes; you point them at a per-branch gateway endpoint. The published catalog lists around 25 models, priced per million tokens at what look like each provider's own list rates (Claude Haiku 4.5 at $1/$5 in/out, GPT-5 Nano at $0.05/$0.40, Gemini 2.5 Flash at $0.30/$2.50).

Neon Auth rounds it out with authentication that does not require standing up a separate identity service, used in the realtime-chat template alongside Next.js.

The through-line is branching

Take those four features and the obvious read is "Neon is cloning Supabase," or "Neon is becoming Vercel with a database." Both are partly true and both miss the point. The organizing idea is that every one of these surfaces inherits database branching.

A Neon branch already gave you an isolated copy of your data in milliseconds, with copy-on-write so it was cheap. Now that same branch gives you:

an isolated function at its own URL, running your latest code against that branch's data,
an isolated storage namespace, so files written in a preview branch never touch production objects,
an isolated AI Gateway endpoint, so model usage on a feature branch is its own thing.

That is the part you cannot easily assemble from separate vendors. You can stitch Lambda, S3, an AI gateway, and an auth provider together yourself, plenty of teams have. What you cannot easily do is make all of them fork in lockstep when you open a pull request, and then throw the whole set away when the branch merges. The preview environment stops being "a copy of the database plus a pile of shared, mutable infrastructure" and becomes a genuinely isolated copy of the backend.

If you have ever had a preview deployment write a test file into the production S3 bucket, or seen a staging job run up a bill against the same AI key as prod, you already understand why branch-scoped everything is the actual feature here.

What it replaces, and the tax it removes

The clearest way to see the value is to count the moving parts in a typical "branchable AI app" today versus on this platform. Standing up one environment the assemble-it-yourself way usually means a database, a compute host, an object store, a few model-provider keys, and an auth service, each with its own account, credential, and region to keep in sync.

That count is illustrative, not measured: your stack may have more or fewer pieces. But the direction is the real claim. Every separate service is another credential to rotate, another thing to provision per preview environment, and another place for prod and staging to accidentally share state. Collapsing that to one account with auto-injected, per-branch credentials is less a feature than the removal of a tax you have been quietly paying.

There is a second, quieter tax it removes: distance. Because functions run in the same region as the branch, the function-to-database round trip is local. A lot of "serverless Postgres is slow" folklore is really "my Lambda in one region is talking to my database in another, over a connection it has to re-establish on every cold start." Co-locating the compute with the branch sidesteps that specific problem.

Where the seams still show

This is a private preview, and it reads like one. Worth being clear-eyed about the limits before you plan anything around it.

One region, new projects only. Everything is in AWS us-east-2 and only works on projects created after the preview opened. Your existing Neon databases will not grow these features in place, which matters if you were hoping to bolt functions onto a production project.

Functions are not a job runner. They are explicitly request/response and real-time, not background jobs. Queued, retryable, cancellable work still belongs to something like QStash or Inngest. That is an honest scoping decision, but it means "move my whole backend here" is not yet on the table.
Fixed function sizing. Memory is fixed (2048 MiB at preview), so this is not a knob-for-everything compute platform yet.
Billing is half-documented. The per-model token prices are public and look like pass-through, but Neon has not publicly spelled out whether there is a markup or preview credits on the AI Gateway. For a side project that is noise; for a budget forecast it is a question to ask before you commit.
Lock-in is the real trade. The whole pitch is integration: one config file, one credential, everything branching together. That convenience is also coupling. An S3-compatible API and standard SDKs keep the exit ramps wider than a fully proprietary stack would, but a neon.ts that declares your functions, buckets, and gateway is, by design, Neon-shaped.

Who should actually care

If you run a large, already-wired backend with mature infrastructure-as-code, none of this is urgent. You have solved preview environments, even if the solution is a pile of Terraform and a shared staging bucket.

The teams this is aimed at are the ones for whom that pile is the problem. Specifically:

Anyone building agents. An agent wants a database to remember things, compute that can stream tokens without a timeout, storage for what it generates, and model access. Getting all four from one CLI, branchable together, is a genuinely shorter path than assembling them. It is not a coincidence that the flagship templates are agents and MCP servers.
Teams that live in preview environments. If every pull request should get a real, isolated backend and yours currently get a database copy plus shared everything-else, branch-scoped functions and storage close that gap.
Small teams shipping AI features. The combination of "Postgres you already use" and "model calls without managing three provider accounts" removes a couple of the most annoying setup steps.

The honest framing is that Neon is making a bet: that the database, not the compute platform, is the right center of gravity for a backend, because the database is where your state and your branching already live. Vercel is making the opposite bet from the compute side, and Supabase has been making a similar bundled-backend bet for years. Whether "everything branches with your data" is a durable advantage or a feature others copy, the next year will tell.

For now, the thing to internalize is that "Neon" no longer means "a Postgres host." It means a database with compute, storage, and model access growing out of it, all sharing the one trick Neon was already good at. If you have only ever evaluated it as a place to put a connection string, it is worth a second look on those terms.

We benchmark Neon's database side in depth in our Neon vs Supabase series, and keep a running Neon vs Supabase comparison covering architecture and pricing side by side. As these platform features leave preview, we will put them through the same treatment: real projects, real numbers, and the harness published so you can argue with our data instead of someone's vibes.

Stop Using Random UUIDs as Primary Keys: uuidv7() Lands in PostgreSQL 18

DevOps Daily — Wed, 01 Jul 2026 15:26:27 +0000

If you reach for gen_random_uuid() every time you need a primary key, you have probably never measured what it costs. On a small table, nothing. On a table with tens of millions of rows, random UUIDs turn every insert into a random write into the middle of your primary-key index, and that quietly drags down insert throughput, inflates index size, and burns through cache and WAL.

PostgreSQL 18 fixes the root cause with a native uuidv7() function. UUIDv7 is time-ordered, so new keys land at the right-hand edge of the B-tree like a sequential bigint would, while keeping the properties teams pick UUIDs for in the first place: generate them anywhere, no central sequence, no coordination. This post explains why the random version is slow, what changes with v7, the benchmark numbers on a 50-million-row table, the one real tradeoff, and how to adopt it without rewriting your schema.

TL;DR

uuidv4() (random) primary keys scatter inserts across the whole index. On large tables that means constant page splits, low page density, fragmentation, and write amplification.
PostgreSQL 18 adds uuidv7(), a time-ordered UUID per RFC 9562. New rows append at the index's right edge, like a sequential key.
In one published 50M-row benchmark, the initial bulk insert finished in about 1.8 minutes with v7 versus about 20 minutes with v4, and the index was roughly 25 percent smaller. Range scans by id ran about 3x faster.
The one real catch: a v7 value embeds its creation time, so do not hand it out as a public identifier if creation time is sensitive.
bigint is still smaller and faster than any UUID. Use uuidv7() when you actually need UUID properties, not as a reflex.

Prerequisites

PostgreSQL 18 (the uuidv7() function is built in; no extension needed)
Basic familiarity with B-tree indexes and primary keys
A schema where you are choosing or reconsidering a primary-key type
Optional: pg_stat_statements and \timing if you want to measure on your own data

Why random UUIDs are slow as primary keys

A primary key in PostgreSQL is backed by a B-tree index, and a B-tree stays sorted by key. Where a new key lands in that sorted structure is the whole story.

A bigint from a sequence always sorts after the previous one, so every insert lands at the right-hand edge of the tree. That rightmost page stays hot in memory, fills up, and splits cleanly. A random UUIDv4 has no order at all, so each insert lands at a random leaf page somewhere in the index.

UUIDv4 (random)                       UUIDv7 / bigint (ordered)
inserts scatter across the tree       inserts append at the right edge

      [ root ]                              [ root ]
     /   |   \                             /   |   \
  [p1] [p2] [p3] ...                    [p1] [p2] [p3] [hot]
   ^    ^      ^                                        ^
  write write write                              every write here
  (cold pages pulled in,                         (one hot page, stays
   split, half-empty)                             in cache, fills, splits clean)

That random-write pattern has three compounding costs on a large table:

Page splits and low density. Inserting into the middle of a full page splits it, leaving both halves partly empty. Your index ends up larger than the data it indexes and full of slack.
Cache misses. The working set is the entire index, not a hot tail. Once the index no longer fits in shared_buffers, every insert risks a random read from disk to fetch the target page.
WAL and full-page-image amplification. The first write to a page after a checkpoint logs the whole page. More distinct pages touched per second means more full-page images and more WAL.

None of this shows up at 10,000 rows. It shows up exactly when the table gets big enough to matter.

What uuidv7() changes

A UUIDv7 is laid out so the most significant bits are a timestamp. PostgreSQL 18 builds it from a 48-bit Unix millisecond timestamp, then a sub-millisecond fraction, then random bits, following RFC 9562. Because the timestamp is at the front and UUIDs sort lexically as 128-bit values, a v7 generated now always sorts after one generated a moment ago.

The result is that v7 keys behave like a sequence for index-locality purposes. Inserts append at the right edge, the hot page stays in cache, and pages fill before they split. You get the write pattern of a bigint with the generate-anywhere property of a UUID.

PostgreSQL 18 exposes three functions. The names are now explicit about the version:

-- Version 4, random. These two are equivalent.
SELECT gen_random_uuid();      -- 5b30857f-0bfa-48b5-ac0b-5c64e28078d1
SELECT uuidv4();               -- b42410ee-132f-42ee-9e4f-09a6485c95b8

-- Version 7, time-ordered. New in PostgreSQL 18.
SELECT uuidv7();               -- 019535d9-3df7-79fb-b466-fa907fa17f9e

-- Optional interval shift, handy for backfilling historical rows
-- with timestamps in the past.
SELECT uuidv7(shift => '-7 days'::interval);

One useful detail: within a single backend session, PostgreSQL guarantees each uuidv7() it generates is strictly greater than the last, by spending some of the random bits on extra clock precision. So even a tight insert loop produces monotonic keys rather than occasionally colliding on the same millisecond.

The numbers

The performance argument is not subtle. Credativ published a detailed comparison on PostgreSQL 18 using a single-column UUID primary key and 50 million rows. The initial bulk load is the headline:

The index size gap is just as real, and it widens when you insert into a table that already holds data, which is the normal case in production:

Reads benefit too. In the same benchmark, a range scan ordered by the id column ran roughly three times faster on v7 (about 113 ms versus 318 ms for a million-row ORDER BY id) and needed on the order of 100 times fewer buffer hits, because rows created near each other in time also sit near each other on disk. That locality is something a random UUID can never give you.

Two caveats on the numbers. They come from one benchmark on a synthetic single-column table, so treat the exact figures as directional rather than a promise for your workload. And the gap is smallest on tiny tables and largest on big ones, which is the whole point: this is a problem that scales with you.

uuidv7 vs uuidv4 vs bigint

uuidv7() is not automatically the right choice. It sits between the other two options.

	bigint sequence	uuidv4 (random)	uuidv7 (time-ordered)
Size	8 bytes	16 bytes	16 bytes
Insert locality	Sequential (best)	Random (worst)	Sequential
Generate without the DB	No	Yes	Yes
Reveals row count or order	Yes	No	Partially (creation time)
Leaks creation time	No	No	Yes

The short version:

Reach for bigint when a single database owns the sequence and you do not need to generate ids elsewhere. It is half the size of any UUID and the fastest option. The downside is that sequential integers leak how many rows you have and are trivially enumerable.
Reach for uuidv7() when you want UUIDs: ids generated by clients or multiple services, merged across shards, or created before a row reaches the database. It gives you that with almost none of the write penalty of v4.
Reach for uuidv4() only when you specifically need an identifier that reveals nothing, including when the row was created.

The one real catch: v7 leaks creation time

Because the timestamp sits in the high bits, anyone holding a v7 value can read roughly when it was generated. That is fine for an internal primary key. It is not fine if you expose the same value as a public identifier and the creation time is sensitive, for example a user id where signup time is private, or an order id where a competitor could infer your daily volume by diffing two ids.

Do not assume a UUID is opaque just because it looks random. A uuidv7() embeds a millisecond timestamp you can decode in seconds. If an identifier is shown to users or third parties and its creation time is sensitive, keep uuidv7() as the internal primary key and expose a separate uuidv4() (or another opaque token) externally.

This is a design decision, not a reason to avoid v7. Most primary keys never leave the backend, and for those the timestamp is a feature, not a leak.

How to adopt it

For new tables, set the column default and move on:

CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id uuid NOT NULL,
    total_cents integer NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

INSERT INTO orders (customer_id, total_cents)
VALUES (uuidv7(), 4999)
RETURNING id;

For an existing table that already uses random UUIDs, you do not need a risky rewrite. The existing rows keep their v4 values and stay scattered, but every new row inserted with a v7 default lands in order, so the index stops degrading from that point forward. Switch the default:

-- New rows get time-ordered ids; old rows are untouched.
ALTER TABLE orders ALTER COLUMN id SET DEFAULT uuidv7();

If you want the full benefit on historical data, you can rebuild the table or index during a maintenance window so the existing rows are stored in key order, but for many teams simply changing the default and letting the table grow in order is enough.

A few adoption notes:

Application-side generation still works. If your services generate ids before inserting, switch the client library to a UUIDv7 generator. Most language ecosystems now have one, and the database does not care who produced the value as long as it is a valid v7.
ORMs are catching up. Check whether your ORM lets you set a database default expression for the id column; if so, DEFAULT uuidv7() is the cleanest path. If it generates ids in application code, point it at a v7 library.
You do not need PostgreSQL 18 to start. If you are on 14 to 17, you can adopt UUIDv7 today by generating it in the application or with a small SQL function, then the upgrade to 18 just lets you drop that shim for the native function. Plenty of managed Postgres is already on 18 as well (Neon, for example, defaults new projects to Postgres 18), so you can try uuidv7() on a fresh database without upgrading anything yourself.

Key takeaways

Random UUIDv4 primary keys are a silent scaling tax: random index writes mean page splits, bloated indexes, cache misses, and extra WAL once a table gets large.
PostgreSQL 18's uuidv7() is time-ordered, so inserts append at the index edge like a sequence while keeping the generate-anywhere property of a UUID. Published benchmarks show large insert-time and index-size wins on 50M rows.
bigint is still the smallest and fastest key when one database owns the sequence; use uuidv7() when you genuinely need UUIDs, and uuidv4() only when you must hide creation time.
Adopting it is a one-line default change for new rows, with no rewrite required for existing tables. The main thing to design around is that v7 embeds a decodable timestamp, so keep it off public-facing identifiers when that matters.

Neon vs Supabase Pricing: What the Same App Costs From Launch to Scale

DevOps Daily — Fri, 26 Jun 2026 13:54:18 +0000

Pricing pages answer the question "what does a unit cost". They are conspicuously silent on the question you actually have: "what will my application cost in a year, when it has real users?" The honest answer depends on workload shape, and workload shape changes as you grow, which is why the same two platforms can each be the cheap option at different points in the same product's life.

This is part three of our Neon vs Supabase series (free tiers, operational benchmarks). Instead of benchmarking operations, we built a cost model: one application, five growth stages, priced on Neon Launch and Supabase Pro using list prices we verified against both pricing pages this week. The model is open source in the same repo as the benchmarks (npm run costs), every price carries its source, and you can change the workload assumptions and rerun it for your own product.

TLDR

There are three cost regimes, not one winner: Neon wins early (scale-to-zero means a quiet app costs almost nothing), Supabase wins the middle (a flat fee beats usage billing once the database runs hot but small), and Neon wins at scale by a wide margin.
The two crossover points sit roughly where your app stops sleeping (Supabase becomes competitive) and where your user count passes Supabase's included 100k monthly active users (Supabase stops being competitive, fast).
The scale-stage surprise: on Supabase, the database is not the bill. Metered auth MAU is. Our scale stage prices at $1,213/month on Supabase Pro, of which $975 is MAU overage; the same stage on Neon Launch is $278, because Neon Auth carries no per-MAU meter up to 1M users.
This comparison assumes you use each platform's bundled auth. If you bring your own auth provider, the picture changes substantially in Supabase's favor, and we show you where.

The application and its growth

The model prices one hypothetical B2B SaaS through five stages, with the workload dimensions both platforms bill on: average compute demand, how much of the month the database is actually active, database size, monthly active users on auth, preview branches created by CI, and egress.

Stage	Compute (avg)	Active time	DB size	MAU	Branches/mo	Egress
Launch month	0.25 CU	20%	1 GB	500	10	5 GB
First customers	0.25 CU	45%	5 GB	5k	30	25 GB
Product-market fit	0.5 CU	75%	20 GB	30k	60	100 GB
Growth	1 CU	95%	60 GB	120k	120	400 GB
Scale	2 CU	100%	200 GB	400k	200	1.5 TB

Disagree with the assumptions? Good: they are parameters, not conclusions. Clone the repo, edit the scenario, rerun. The shape of the findings survives reasonable changes to the numbers; your exact crossover points will differ.

The curves

Monthly cost of the same application as it grows — interactive version on DevOps Daily

Regime one, the quiet months. At launch, Neon costs $5 to Supabase's $26. Nothing clever: Supabase Pro is a $25 flat fee plus always-on compute, while Neon bills compute only when the database is awake, and an early-stage app sleeps most of the month. If you are pre-revenue, this gap is your hosting budget.

Regime two, the flat-fee window. By product-market fit the picture inverts: Supabase $33, Neon $49. The database now runs three-quarters of the month, so scale-to-zero stops paying, while Supabase's fixed fee covers a Small instance running around the clock with most usage inside included quotas. This is the regime Supabase's pricing is designed for, and in it, the design works. The growth stage is nearly a tie ($128 vs $120), which is itself useful information: between roughly 30k and 120k users, price should not be the deciding factor at all; pick on the operational differences instead.

Regime three, the meters. At scale the curves split violently: $278 on Neon, $1,213 on Supabase. To see why, look at where the Supabase dollars go:

Where the money goes at the scale stage (Supabase Pro, $1213.39/mo total) — interactive version on DevOps Daily

The MAU surprise

That chart is the article. At 400k monthly active users, the compute (a Medium instance, $50 after credits) and even 200 GB of storage ($24) are rounding errors next to $975 of MAU overage: Supabase Auth includes 100k monthly active users on Pro and bills $0.00325 for each one beyond. Auth, the feature that felt free when you started, becomes 80% of the bill precisely when your product succeeds.

Neon's side has no equivalent meter: Neon Auth (in beta) carries no per-MAU billing up to one million users on the paid plans, so the scale stage is honest compute and storage: $155 + $70 + $53 of always-active database, branches included.

Now the fairness flip, because this cuts both ways: the comparison above assumes you use the bundled auth. Plenty of teams run Clerk, Auth0, WorkOS, or their own auth regardless of database, and at 400k MAU those run hundreds to thousands of dollars a month on their own. If you bring your own auth, delete the MAU line from the Supabase column, and the scale stage becomes roughly $238 vs $278: a near-tie that Supabase arguably wins. The platform decision and the auth decision are one decision wearing two coats; make them together.

What the model deliberately leaves out

The PITR add-on ($100/month on Supabase per 7-day window): add it if sub-minute recovery is a requirement; part two explains what you get on each platform without it.
Replacement costs for the rest of the bundle: if you would otherwise pay for storage, realtime, or edge functions separately, Supabase's flat fee is buying more than a database. Neon announced its own storage and functions in June 2026, but they have not shipped.
Committed-use and enterprise discounts, support tiers, and the Team/Scale tiers above these plans: that comparison is coming later in this series.
Egress shape: we model it linearly; a media-heavy product will not be linear, and Supabase's $0.09/GB beyond 250 GB deserves your own modeling if that is you.

How to actually use this

Find your regime. Mostly-idle side project or pre-launch: Neon by default. Steady small production app, happy inside included quotas: Supabase's flat fee is genuinely good value. Past 100k MAU on bundled auth: do the math before the bill does it for you.
Watch the crossovers, not the platforms. The first crossover arrives when your database stops sleeping; the second when your user count crosses the included-MAU line. Both are visible in your own metrics months before they hit the invoice.
Decide auth and database together. The single biggest line in this entire analysis is an auth meter on a database platform.

Every price in the model links to its source and was verified against both pricing pages in June 2026 (prices change; the repo holds the dated record). Like the benchmarks, the model is open source and contributions are welcome: if a price moved or an assumption looks wrong, open an issue or PR and we will rerun the curves. The live dashboard carries the measured performance data this series is built on, our full Neon vs Supabase comparison lays out the architecture and feature differences side by side, and part four will close the series with something nobody has benchmarked properly yet: what it costs in AI agent tokens to build the same application on each platform.

Neon vs Supabase in Production: We Benchmarked the Operations That Page You at 3am

DevOps Daily — Thu, 25 Jun 2026 15:57:46 +0000

Free tiers are where you evaluate a database. Paid tiers are where you operate one, and operating means the unglamorous verbs: resize the compute because traffic doubled, add a read replica because the dashboard queries are hurting, branch the database for a preview environment, restore because someone ran the wrong migration. Vendor documentation describes these operations. It rarely tells you how long they take, and it almost never tells you what they cost in downtime.

So we measured them. This is part two of our Neon vs Supabase series (part one covered the free tiers), now on the plans you would actually run production on: Supabase Pro against the equivalent Neon tier. Same methodology as before: both platforms in AWS eu-central-1, timed from a client VM in the same metro, every operation run repeatedly across two separate benchmark sessions on different days, raw samples committed, and everything reproducible from the open source harness with a live dashboard tracking every session since.

TLDR

Compute resize is the starkest difference we have ever measured between two managed databases. Changing compute size on Supabase took 39 seconds of API time and caused 39 seconds of real SQL downtime per change, measured by probing the database every 250ms. The same operation on Neon: 2.4 seconds to apply, zero failed probes.
You also cannot resize Supabase twice in a row: the platform throttles consecutive compute changes for minutes ("We are still processing addon changes, please try again in 3 minutes").
Read replicas are an architecture lesson in two numbers: 8 seconds on Neon (a new compute attaches to existing shared storage) vs 181 seconds on Supabase (a full database clone), with Supabase also requiring Small compute or larger on the primary.
Branching held its free-tier shape: a Neon branch arrives carrying the parent's 100k rows in 1.7s; a Supabase branch arrives schema-only in 6.2-6.7s. Supabase's API now has a with_data flag, but every attempt returned 406 "Failed to fetch latest physical backup" on a fresh project: data branches have infrastructure prerequisites.
Under connection stampedes the platforms are twins: 50, 100, and 200 simultaneous cold connections produced near-identical wave times and zero refusals on both.

How we measured

Every number below is the median of repeated runs (10 per operation per session for management operations, 5 waves per concurrency level), collected in two independent sessions on consecutive days. The two sessions agreed within single-digit percentages on every operation, which is the property that makes medians worth publishing. The client sat 1-2ms from both platforms. Resources were created fresh and torn down after every run.

One honest note on plans: the Supabase side ran on Pro ($25/month). The Neon side ran on a Scale-plan account, but every operation measured here (branching, resize, replicas, restore) behaves identically on Launch; plan tier changes quotas and retention windows, not the mechanics we timed.

Compute resize: the 3am operation

You sized the database for launch traffic. Launch went well. Now you need the next compute size, and the question that matters is not "can the platform do it" but "what happens to my users while it does".

We resized each platform's compute up and back down, ten cycles per session, while a probe ran select 1 against the database every 250 milliseconds. Two numbers per resize: how long until the management API reported the change applied, and how long SQL actually failed.

Compute resize: API apply time vs actual SQL outage (median) — interactive version on DevOps Daily

Neon applies an autoscaling-limit change in 2.4 seconds, and across forty resize cycles in two sessions, the probe never failed once. The compute reconfigures behind the same endpoint without dropping the connection path. Supabase restarts the database to change compute: 39 seconds of apply time, and effectively all of it is real downtime; their docs say resizes are "usually applied with less than 2 minutes of downtime", and our measurements land comfortably inside that promise while still being 39 seconds of failed queries per change.

The second finding is subtler and bit us during the benchmark itself: Supabase refuses back-to-back compute changes. Issue two resizes in quick succession and the API returns "We are still processing addon changes, please try again in 3 minutes", and the project reports an unhealthy state between changes. For a production runbook this means a Supabase resize is a planned, serialized event with a maintenance-window mindset. On Neon it is closer to a config tweak.

If your workload's compute needs change often (and on serverless-adjacent platforms, that is the promise), this section is the comparison.

Branching: same story, sharper edges

Part one covered free-tier branching; the paid tiers sharpen it. A Neon branch is a copy-on-write reference to the parent's storage: it arrives carrying all data. A Supabase branch is a freshly provisioned project that replays schema and config: it arrives empty of data, on Pro as on free.

Branch to queryable: Neon copies 100k rows, Supabase copies schema only: interactive version on DevOps Daily

Medians: 1.7 seconds for a Neon branch with 100,000 rows of parent data, 6.2-6.7 seconds for a Supabase schema-only branch. Both respectable. Two asterisks worth your attention though:

The tail. In session one, nine Supabase branches took 6-8 seconds and one took 146 seconds, with nothing different about the request. Session two had no such outlier, which is exactly why we run multiple sessions. If your CI creates a branch per pull request, a 2.5-minute outlier is the kind of thing that makes a developer rerun the pipeline and file a flaky-infra ticket.

The with_data flag. Supabase's branch API accepts with_data: true, which on paper would close the data gap. In practice, every attempt on our freshly created projects failed with 406 "Failed to fetch latest physical backup": data branches require the project to already have physical backups, which fresh projects do not have and which normally arrives with the PITR add-on. For the create-test-destroy loop that makes branching valuable, data-included branches on Supabase have prerequisites that defeat the purpose today.

Read replicas: attach vs clone

Adding a read replica is where the two architectures stop being abstract diagrams and start being your wait time.

Read replica to first query: interactive version on DevOps Daily

Neon: 8 seconds median to a replica answering queries. There is nothing to copy; a read-only compute attaches to the same shared storage as the primary, so replica creation is compute provisioning, full stop. It also means no replication lag in the classic sense and no extra storage bill.

Supabase: 181 seconds median, remarkably consistent (our session-one runs landed within a 2-second band of each other), because each replica is a physical clone of the database with WAL streaming, the way RDS would do it. Two operational prerequisites we hit: the primary must run Small compute or larger (the API rejects replicas on Micro with "Read replicas require a minimum size of small"), and replica disk bills at 1.25x the primary's size.

Neither approach is wrong. Clones isolate replicas from primary storage performance; shared storage makes replicas instant and cheap. But if your scaling playbook says "add a replica when read latency climbs", one platform executes that play in seconds and the other in minutes, and the minutes version also costs a compute-size bump if you started small.

Does any of this scale with database size?

The attach-vs-clone story makes a testable prediction: copy-on-write operations should stay flat as the database grows, physical clones should not. So we reran branches and replicas at 100k, 1M, and 5M seeded rows, a 50x span.

Read replica creation as the database grows — interactive version on DevOps Daily

The prediction holds, with one nuance. Neon branches are flat to the decimal (1.73s, 1.67s, 1.67s) and so are its replicas (7.9s, 8.0s, 8.2s): there is nothing that copies data, so data size cannot matter. Supabase branches are also flat at 6.4s, but for the less flattering reason that they only copy schema. Supabase replicas are the one operation where size shows: the median grew 12% by 5M rows and p95 stretched from 182s to 234s. At a few hundred megabytes, provisioning still dominates the clone; at real production sizes, the copy takes over and that line keeps climbing. Our benchmark budget stops at 5M rows, but the direction is unambiguous, and it compounds the playbook problem above: the moment you most need a replica is the moment your database is biggest.

The connection stampede: a tie worth publishing

Serverless platforms fail in bursts: two hundred function invocations wake at once and all of them want a connection. We simulated exactly that through each platform's transaction pooler: N simultaneous cold connections, each performing connect, TLS, auth, one query, disconnect.

Connection stampede: N simultaneous cold connections through the pooler (median wave) — interactive version on DevOps Daily

Both platforms absorb a 200-connection stampede in about a second, scaling near-linearly from 50 to 200 clients, with zero refused connections at any level on either platform. Supabase's Supavisor was a hair faster at every level; the margin is noise. After the resize and replica sections, it would be easy to expect Neon to win everything; this is the result that says the comparison is about architecture, not quality. Both teams have built excellent poolers.

Restore: the operation you hope never to time

We restored Neon branches to a point 60 seconds in the past, with 100k rows of data, eight runs per session: 5.6 to 6.9 seconds median until the management API confirmed completion and SQL answered on the restored state. That is point-in-time recovery at interactive speed, and it comes included.

On Supabase, point-in-time recovery is a $100/month add-on (per 7-day retention window, Small compute minimum), so we documented it rather than benchmarked it; daily backups are included on Pro but a daily backup is a very different promise from PITR when the bad migration ran at 14:47. If sub-minute-granularity recovery matters to your operation, price the add-on into the comparison.

The finding we didn't go looking for

While rechecking our own dashboard we noticed something odd: project creation on the Supabase Pro org was wildly slower than the free-org numbers from part one. So we measured it properly, twice, a day apart.

Supabase project creation to first query, free org vs Pro org — interactive version on DevOps Daily

Free org: 7.4 seconds median to a queryable project. Pro org: 125.2 seconds on day one (20 runs) and 111.9 seconds on day two (10 runs), so this is not a one-day capacity blip. Day two also produced two provisioning failures we did not cause: one project came up with no pooler configuration, and another returned 404 on its own ref immediately after creation. Neon, measured the same morning as a control, created projects in 5.5 seconds with no failures.

We do not know why paid-org provisioning is 15x slower than free; nothing in the documentation suggests it should be. If your platform automation creates Supabase projects programmatically (per-tenant databases, ephemeral environments), budget two minutes and a retry loop, not eight seconds. We have raw samples committed for all three sessions and would genuinely welcome an explanation.

What failed, and what it taught us

A benchmark that reports only clean numbers is hiding something. Ours hit three walls worth knowing about:

Supabase's addon pipeline throttling (above) means resize benchmarks, and resize automation, must wait minutes between changes.
Supabase Management API mutations sometimes return empty response bodies, and replica setup reports no status; readiness means polling the pooler config until a READ_REPLICA entry appears. Automation against these APIs needs more defensive plumbing than Neon's operations API, which returns explicit operation objects with terminal states.
A long-running idle Postgres connection on either platform will emit asynchronous errors when the server restarts under it (compute resize, for instance). If your Node service holds connections through a Supabase resize, handle the error event on your clients or the restart will take your process down with it. Ask us how we know.
One more finding was waiting after the benchmarks ended. With every benchmark project torn down and the organization verifiably empty (GET /v1/projects and the org-scoped listing both return zero projects), downgrading the org from Pro was refused with "You still have active preview branches. Please delete all your preview branches and disable branching feature before downgrading to Free Plan." No projects exist, so no branches can: the downgrade validator appears to count orphaned branch records left behind when branches' parent projects are deleted. If you run branch-heavy ephemeral workloads on a paid org and ever plan to downgrade it, know that the exit door can be blocked by data you can no longer see or delete.

Verdict

The free-tier conclusion was "pick on shape, not speed". The production-tier conclusion is sharper: the operational gap is real, and it favors Neon almost everywhere it exists. Resize without downtime vs a 39-second outage with a minutes-long cooldown; replicas in 8 seconds vs 3 minutes with compute prerequisites; branches with data vs without; included interactive PITR vs a $100/month add-on. The one place the platforms tie (connection stampedes) is the one place most teams assumed serverless Postgres would struggle, and neither does.

What this verdict does not say: Supabase Pro still bundles auth, storage, realtime, and edge functions that Neon does not have today (announced, not shipped), and part one's conclusion stands: teams shipping a v1 product buy real velocity with that bundle. But if the database is the load-bearing component of your operation and you expect to resize, replicate, branch, and occasionally restore it, the operational benchmarks have a clear winner.

Every number above links to raw committed samples, the live dashboard updates with every benchmark session, and the harness is open source: if you see something off in the methodology or get different numbers, open an issue or a pull request, corrections are welcome and credited. For the architectural side by side rather than the timings, our full Neon vs Supabase comparison covers pricing models, PITR, and the bundled features in one place. Part three prices all of this against a growing application, including the cost crossover points nobody talks about.

Hetzner Doubled Its Prices Again. The AI Memory Crunch Is Why

DevOps Daily — Tue, 23 Jun 2026 12:25:30 +0000

If you run anything on Hetzner, you have probably already seen the notice. As of 08:00 CEST on June 15, 2026, Hetzner adjusted its prices again, and this round is the steepest yet: new cloud and dedicated server orders are up by an average of about 99% in Germany, 158% in its US locations, and 78% in Singapore, according to heise. Some line items more than tripled.

For a host whose entire brand is "absurdly cheap European iron," a near-doubling is a shock. But the interesting part for anyone who runs infrastructure is not the number. It is the reason behind it, because that reason is going to show up in your bills too, whether or not you host on Hetzner and whether or not you do anything with AI.

What actually changed

The adjustment applies to new orders and cloud rescales from June 15 onward. If you have an existing machine, you keep your current price until you reorder or resize it. Orders placed before the cutoff but delivered after still get the old price. Web hosting, managed and Exchange servers, IP addresses, storage boxes, and load balancers were left out of this round.

A few representative changes, taken from Hetzner's own price tables and heise's reporting:

Server	Before	After	Change
CAX11 (ARM, DE/FI)	€4.49/mo	€5.99/mo	+33%
CCX13 (dedicated vCPU, DE/FI)	€15.99/mo	€42.99/mo	+169%
CPX41 (US region)	€38.99/mo	€120.49/mo	+209%

Two patterns are worth pulling out of that table. The ARM line (CAX) took by far the smallest hit. The x86 dedicated-vCPU lines, the ones that come with more memory attached, took the largest. And US capacity rose far more than European, which tracks with where new hardware is hardest to get right now.

This is also not a one-off. By several outlets' count it is the third price adjustment Hetzner has made in 2026, after a round on April 1 that raised cloud servers 30 to 43%, object storage 30 to 53%, and, most tellingly, memory add-ons by around 575%. The "again" in everyone's reaction is earned.

The real story is in the memory market

Hetzner's stated reason is "extremely high procurement costs for new hardware." That is true, and it undersells how unusual the moment is. The component market is in the middle of what the industry is openly calling an AI supercycle, and the prices are genuinely historic.

The numbers behind the headlines, from Tom's Hardware, IEEE Spectrum, and TrendForce data:

DRAM and NAND prices rose between 50% and 200% in the first half of 2026, with DRAM up roughly 171% year over year.
AI data centers are projected to consume around 70% of high-end DRAM output in 2026, an inversion of who the memory makers used to build for.
Samsung, SK hynix, and Micron have all redirected capacity toward high-bandwidth memory (HBM) and advanced DDR5 for AI accelerators. Micron's entire 2026 HBM output is reportedly already committed, which leaves less fab capacity for ordinary server DRAM.
Hard drives are reportedly sold out for the year, and analysts expect tight allocation and elevated pricing to persist into 2027.

Server memory and storage are not a rounding error in a machine's bill of materials, they are most of it. When DRAM nearly doubles year over year and high-capacity drives are on allocation, the cost of building a new server rises sharply, and that 575% jump on Hetzner's memory add-ons back in April suddenly makes sense. A host running on thin margins cannot absorb that. It passes through.

Why Hetzner shows it first

It is tempting to read this as a Hetzner problem and conclude that the hyperscalers are safer. The opposite is closer to the truth. Hetzner is a leading indicator, not an outlier.

Hetzner sells close to cost. It buys hardware, racks it, and rents it with little margin to cushion a shock, so when component prices spike, the increase reaches customers in weeks. AWS, Google Cloud, and Azure buy in enormous volume on long contracts, sit on far higher margins, and wrap everything in committed-use discounts and multi-year enterprise agreements. That hides a cost shock for a while. It does not prevent it. The same DRAM and the same drives go into their racks too, and the bill arrives later, as quietly worse renewal terms, thinner discounts, pricier memory-optimized instances, and instance families that stop getting cheaper the way they used to. If a near-cost provider just went up 99%, the providers selling the same silicon at a markup are not immune. They are just slower to show it.

Is Hetzner still worth it?

Mostly, yes. Even after this increase, Hetzner remains dramatically cheaper than the hyperscalers for raw compute and bandwidth. A doubling of a number that started at a fraction of the AWS equivalent is still a fraction of the AWS equivalent. To put numbers on it, here is a comparably shaped box (around 2 vCPU and 8 GB) across three providers:

Even after more than doubling, the Hetzner box is still cheaper than the same shape on DigitalOcean and well under AWS on demand. What changed is the size of the gap: before June 15 that machine was roughly a quarter of the AWS price, and now it is closer to two thirds. The discount is real, it is just no longer the runaway it used to be, and a committed-use plan on AWS would narrow it further. The moat shrank, it did not close, and the egress story (where Hetzner includes generous traffic and the hyperscalers bill roughly $0.09 per GB after a small allowance) did not change at all. For a bandwidth-heavy service, that egress line can still dwarf the compute difference.

So the answer is not to rage-quit to a more expensive provider out of spite. It is to re-run the numbers you have probably not looked at since you set them, because the assumptions underneath them just moved.

What to actually do about it

Protect your grandfathered machines. Existing servers keep their old price until you reorder or rescale. That means a casual resize now reprices the whole machine at the new rate. Before you bump a server up a tier, check what it will cost after the change, not before. If you were about to tear down and recreate something, that is now a price increase you are choosing.
Treat memory as the cost center it has become. The line item that exploded is RAM. Audit your over-provisioned instances, the ones sized for a peak that never comes, because every spare gigabyte is now meaningfully more expensive. Right-sizing memory was always good hygiene; this is the quarter it pays for itself.
Look hard at ARM. Hetzner's ARM line took a third of the increase the x86 lines did. If your stack runs on ARM, or could with a rebuild of your images, you dodge a large part of this and usually get better price-performance anyway. The same is true on the hyperscalers with Graviton and equivalents.
Re-run your cost model and budget for hardware inflation everywhere. This is not contained to one host or one quarter. Price your colo refresh, your cloud renewals, and yes, the RAM in your next batch of laptops, against a market that analysts expect to stay tight into 2027. If you build cost models, raise the memory and storage line and leave it raised.
Do not over-correct. Migrating providers has its own large costs in engineering time and risk. The right move for most teams is to measure, right-size, and renegotiate, not to flee. Panic migrations during a price shock are how you trade a 99% line-item increase for a 100% project you did not need.

The bigger signal

Strip away the Hetzner specifics and here is what is left: the AI build-out is now large enough to move the price of the components every other computing workload depends on. You do not have to train a model, run inference, or ship a single AI feature to pay for the boom. If your service needs memory and disks, and all of them do, you are bidding for the same supply that the AI data centers are buying 70% of, and they are bidding harder.

Hetzner is just the first invoice to say so out loud. The rest will follow in their own time and their own quieter language. Plan your next year of infrastructure spend as if memory is expensive and scarce, because for the foreseeable future, it is.

Neon vs Supabase Free Tiers: We Benchmarked Both So You Don't Have To

DevOps Daily — Mon, 22 Jun 2026 18:56:30 +0000

Originally published on DevOps Daily. The charts below are static snapshots; the live, interactive versions and the open source benchmark harness are on the original.

Pick any "Neon vs Supabase" thread on the internet and you will find the same spec-sheet ping pong: one side quotes storage limits, the other quotes monthly active users, and nobody has actually timed anything. Both platforms hand out free Postgres, both claim to be fast, and both free tiers have sharp edges that only show up when you run real operations against them.

So we ran real operations against them. 320 timed samples across nine operation types, both platforms in the same AWS region (eu-central-1, Frankfurt), measured from a client VM in the same metro so network distance could not put a thumb on the scale. Every raw sample, the harness that produced it, and a live dashboard are public, so you can check the math or rerun the whole thing yourself: explore the live results dashboard or read the harness at The-DevOps-Daily/serverless-postgres-benchmarks.

This is the free tier piece. Paid-tier operations (read replicas, compute resizing, Supabase branching) get their own article once those runs land.

TLDR

Query latency is a tie. Every connection path on both platforms lands at a 25 to 30 ms median for a full connect + TLS + auth + query cycle from a same-region client. Do not pick either platform for single-query speed.
Project creation is closer than you think. Neon: 5.7 s median to a queryable database. Supabase: 7.4 s. Both have outliers above 11 s.
The idle behavior is the real difference. Neon free databases scale to zero after 5 minutes and wake automatically in about 570 ms. Supabase free projects pause after 7 days of inactivity and stay down until you log in and restore them by hand.
Branching only exists on one side. Neon free includes copy-on-write branches that arrive carrying the parent's data, queryable in 2.2 s. Supabase branching requires a paid plan and starts without data.
Networking will surprise you. Supabase free-tier direct connections are IPv6-only. From an IPv4 client (most CI runners, many VPSes, most home networks) you must use their pooler, and the TLS chain is signed by Supabase's own CA.

How we measured

The harness is a small TypeScript runner that drives each platform's management API plus a regular pg connection. The rules:

Both platforms in aws eu-central-1, measured from a 2 vCPU VM in Frankfurt (1 to 2 ms from both).
Every operation runs repeatedly: 50 runs for latency paths, 20 for project creation and cold starts, 10 for branching. Reports use median and p95, never single runs.
Latency samples use a cold connection each time: connect, TLS handshake, auth, select 1, disconnect. That is what a serverless function pays per invocation without a warm pool, and it is a fairer test than hammering one warm session.
Every resource is created fresh, named bench-*, and deleted after the run.
Raw samples are committed to the repo with region, plan, and client metadata. The numbers below link to data, not to memory.

Free plans on both sides, as of June 2026.

Query latency: stop arguing about it

Five different connection paths, 50 cold-connection cycles each:

Query latency: cold connection, select 1 (median, 50 runs each) — interactive version on DevOps Daily

That is a 5 ms spread across ten thousand-ish kilometers of marketing. At equal network distance, the free tiers are latency-equivalent for a single query. The spread between the fastest and slowest path on the same platform is bigger than the spread between platforms.

The percentile view makes the tails visible too. Every one of the 250 samples, ranked:

Query latency percentiles (50 cold connections per path) — interactive version on DevOps Daily

What this means in practice: latency should not be on your decision sheet at all. Region placement matters about 10x more than vendor choice, because every millisecond of client-to-region distance gets added to each of these numbers.

Project creation: both are fast now

Time from the management API call to the first successful select 1, 20 runs each:

Platform	Median	p95	Range
Neon	5.7 s	8.8 s	3.5 s to 13.6 s
Supabase	7.4 s	11.8 s	6.5 s to 11.9 s

Two things stood out. First, both are genuinely fast: a complete, queryable Postgres in single-digit seconds. Supabase used to take minutes to provision a project; that reputation is outdated. Second, neither is consistent: Neon's fastest run was 3.5 s and its slowest 13.6 s, nearly a 4x spread, so do not build automation that assumes the median.

Project creation: API call to first successful query — interactive version on DevOps Daily

If your workflow creates databases programmatically (per-tenant databases, ephemeral test environments, agent-driven tooling), both free tiers can technically do it, but the caps differ wildly: Neon allows up to 100 projects on the free plan, Supabase allows 2 active projects per organization. For anything that creates databases in a loop, that single line of the spec sheet decides for you before any benchmark does.

Idle behavior: a nap versus a coma

This is the section that should actually drive your decision for side projects, and it is the one spec sheets describe worst.

Neon free compute always scales to zero after 5 minutes of inactivity. You cannot turn that off on the free plan. The flip side: it wakes automatically on the next connection. We suspended and woke a database 20 times:

Wake query (first query against suspended compute): 568 ms median, 1.06 s p95, worst case 1.55 s.

Neon cold start: first query against suspended compute — interactive version on DevOps Daily

Neon's docs say cold starts are "typically a few hundred milliseconds" with 500 ms as the usual ceiling. Measured from a same-region client, reality is a bit slower: our median sat just above their typical ceiling, and the p95 crossed a full second. Not bad, just not quite the brochure. For a hobby app behind a page load, an occasional extra half second on the first request after a quiet stretch is invisible. For a latency-sensitive API that gets sparse traffic, it is a real consideration.

Supabase free compute never naps; your project runs a dedicated instance around the clock, so there are no cold starts at all. Instead, after 7 days without activity, the whole project is paused. A paused project does not wake on connection. You log into the dashboard and restore it manually, which takes on the order of minutes, and until you do, every connection fails outright.

So the trade is: Neon costs you ~570 ms after every 5 quiet minutes but never needs you; Supabase costs you nothing while active but a manual rescue if you ever leave it alone for a week. For a demo you show twice a month, that 7-day pause is the difference between "works when the customer clicks" and "dead link in your portfolio."

Branching: only one of them brings the data

Database branching is the headline feature of serverless Postgres, and on free tiers it is not a comparison, because only Neon has it there. We branched a project carrying 100,000 seeded rows, 10 times:

Writable branch, parent's full dataset included, queryable: 2.2 s median, 3.2 s p95.

One honest nuance the marketing skips: the copy-on-write storage operation itself is effectively instant, but a usable branch needs its own compute endpoint, and provisioning that is where the 2 seconds go. "Branches in milliseconds" is true at the storage layer and false at the connection string. What you actually get is a full writable copy of a database, with data, in about the time it takes to read this sentence, which is still excellent and still the same primitive that makes per-PR preview databases and agent test loops practical.

Supabase shipped Branching 2.0 in 2025 (Git optional, branch from the dashboard or API), but it requires a paid plan, each branch bills as its own compute, and branches copy schema and config without production data. We will measure it properly in the paid-tier article.

The networking fine print nobody tells you

Three things we hit while building the harness that will absolutely hit you too:

1. Supabase free direct connections are IPv6-only. db.<ref>.supabase.co has no A record, only AAAA. If your client is IPv4-only, and that includes most CI runners, many cloud VMs by default, and most home ISPs, you cannot reach the direct host at all. You connect through Supavisor instead: session mode on port 5432, transaction mode on 6543. Both pooler paths carry IPv4. (A dedicated IPv4 address for direct connections exists as a paid add-on.) Neon's endpoints answer on both stacks.

2. The Supabase pooler hostname varies per project. Our first project landed on aws-1-eu-central-1.pooler.supabase.com while the documented examples reference aws-0-.... Both exist. Do not hardcode the pooler host from a tutorial; read your project's connection info from the dashboard or the Management API.

3. Supabase database TLS chains to Supabase's own CA. The certs are not signed by a public authority, so a client that verifies certificates (which should be all of them) needs their root certificate. And if you use node-postgres, there is a trap inside the trap: when your connection string contains sslmode=require, pg silently ignores the ssl options object where you so carefully loaded that CA file, and verification fails with self-signed certificate in certificate chain. Drop sslmode from the URL and configure TLS exclusively through the ssl option. That one cost us an hour; it is yours for free.

None of these are dealbreakers. All three are the kind of thing you want to know on a Tuesday afternoon rather than discover during a Friday deploy.

The limits, side by side

The measured behavior above, plus the caps that matter, as of June 2026:

	Neon free	Supabase free
Database storage	0.5 GB per project	500 MB
Projects	up to 100	2 active
Compute	100 CU-hours/project/month, autoscaling to 2 CU	dedicated Nano instance, always on
Idle behavior	scales to zero after 5 min, auto-wakes in ~570 ms	project pauses after 7 days, manual restore
Branching	10 branches/project, data included, ~2.2 s	not available
Restore window	6 hours	none (daily backups start on Pro)
Extras		Auth (50K MAU), storage (1 GB), edge functions (500K), realtime
Direct connection	IPv4 + IPv6	IPv6 only (pooler for IPv4)

Which free tier should you pick?

The latency tie makes this refreshingly simple: pick on shape, not speed.

Pick Neon's free tier when the database is the product. Side projects with irregular traffic (auto-wake beats manual restore), anything that needs many databases (100 projects vs 2), CI and preview environments (branching with data is free-tier-exclusive), and agent or automation workflows that create and destroy databases programmatically.

Pick Supabase's free tier when you are shipping an app, not a database. The bundled auth, storage, realtime, and auto-generated APIs replace three or four other free tiers you would otherwise stitch together, and 50K monthly active users of free auth is genuinely hard to beat. Just put a calendar reminder somewhere if the project might go quiet for a week.

One forward-looking note: in June 2026 Neon announced S3-compatible object storage that branches with the database, serverless functions, and an AI gateway, all marked coming soon. If those ship, the bundled-stack gap narrows; we will rerun this comparison when they do.

And if you are still torn, the structural differences run deeper than the free tiers: we maintain a full Neon vs Supabase comparison covering architecture, pricing models, PITR, and the paid features side by side.

Where the series goes next

This post is part one. The free tiers are where you start, but the interesting differences show up when money and production traffic enter the picture, so we kept going:

Part two: operational benchmarks times the operations that page you: compute resize (and its downtime), branching at scale, read replicas, point-in-time restore, and 200-connection stampedes, on the paid tiers.
Part three: scaling costs prices the same application through five growth stages on both platforms, with an open source cost model you can rerun on your own workload.

Run it yourself

Every number in this post is the median of committed raw samples. The live dashboard tracks every benchmark session (the charts there update as new runs land, including a latency-over-time view), and the harness behind it is about 600 lines of TypeScript: The-DevOps-Daily/serverless-postgres-benchmarks. Bring your own API keys, npm run bench, and argue with our data instead of someone's vibes.

These benchmarks are fully open source, and contributions are welcome. If you spot something off in the methodology, know a fairer way to measure an operation, or get different numbers from another region or another month, open an issue or send a pull request to the repo. The whole point of publishing the harness and every raw sample is that this comparison can be checked, challenged, and improved by anyone, instead of being remembered as a vibe.

Secrets Management Best Practices with HashiCorp Vault

DevOps Daily — Mon, 22 Jun 2026 10:55:34 +0000

A database password leaks. Maybe it was committed to a private repo three years ago, maybe it sat in a CI log, maybe a contractor copied it into a Slack DM. You do not know, because that password has been valid the entire time and nobody rotated it. Now you are in an incident channel at 2am trying to figure out the blast radius of a credential that every service, every old laptop, and every backup job has used since 2023.

This is the problem HashiCorp Vault solves, and it is not the problem most teams use it for. Most teams install Vault, run it in dev mode, dump a pile of static key-value secrets into it, and call it done. That gives you an encrypted password store with a nicer API. Useful, but it leaves the worst part untouched: secrets that live forever and that no human can fully account for.

The real win with Vault is making secrets short-lived and generated on demand, so a leak has an expiry date measured in hours instead of years. This post shows how to run Vault for that: a production server that survives reboots, machine authentication that does not depend on root tokens, dynamic database credentials, and encryption as a service. Every command here is one you can run.

TLDR

Never run vault server -dev for anything real. It is in-memory and unsealed, so a restart wipes every secret.
Use auto-unseal (AWS KMS, GCP KMS, or another Vault) so a reboot does not need five humans with key shares.
Authenticate machines with AppRole, not long-lived root or service tokens.
Use dynamic secrets for databases. Vault creates a unique DB user per request with a short TTL and deletes it when the lease ends.
Use the transit engine for encryption as a service so your apps never touch the encryption keys.
Write least-privilege policies, turn on the audit log, and revoke leases when something goes wrong.

Prerequisites

A Linux host (or VM) where you can install the Vault binary
Vault 1.15 or newer (vault version to check)
A PostgreSQL database you can point Vault at for the dynamic secrets section
An AWS account with a KMS key if you want auto-unseal (optional but recommended)
Basic comfort with the command line and HCL config files

Stop running Vault in dev mode

Dev mode is the trap. You run one command and get a working Vault:

vault server -dev

==> Vault server configuration:
             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
              Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: inmem

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key.

Read that warning. Storage: inmem means every secret lives in RAM and disappears on restart. tls: disabled means traffic is plaintext. It starts unsealed, so anyone who reaches port 8200 owns it. Dev mode is for trying commands on your laptop, nothing else.

A production server needs three things dev mode skips: persistent storage, TLS, and a seal. Here is a real config.hcl using integrated Raft storage and AWS KMS auto-unseal:

# /etc/vault.d/vault.hcl
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

# Auto-unseal: Vault asks KMS to decrypt its root key on boot.
# No more gathering humans with key shares after every restart.
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abc-12345"
}

api_addr     = "https://vault-1.internal:8200"
cluster_addr = "https://vault-1.internal:8201"
ui           = true

Start it and initialize once:

vault server -config=/etc/vault.d/vault.hcl &

export VAULT_ADDR="https://vault-1.internal:8200"
vault operator init -recovery-shares=5 -recovery-threshold=3

Recovery Key 1: vR2k9... (give to a different person than key 2)
Recovery Key 2: 8Lp4m...
Recovery Key 3: qW7nZ...
Recovery Key 4: 3xF8t...
Recovery Key 5: hT1bY...

Initial Root Token: hvs.CAESIJ...

Success! Vault is initialized

Recovery key initialized with 5 key shares and a key threshold of 3.

Because of auto-unseal you get recovery keys instead of unseal keys. Vault unseals itself on boot using KMS, and the recovery keys are only for emergencies like regenerating the root token. Split them across different people and store them offline. Never keep all of them in one place.

Now use that root token once to set up authentication and policies, then throw it away. Root tokens are for break-glass moments, not daily use.

vault login hvs.CAESIJ...

If you ever see this, your Vault restarted and could not reach its seal:

$ vault kv get secret/payments/stripe
Error making API request.
URL: GET https://vault-1.internal:8200/v1/secret/data/payments/stripe
Code: 503. Errors:
* Vault is sealed

A sealed Vault answers nothing. That is the whole point. Auto-unseal exists so this state heals itself instead of paging you.

Authenticate machines with AppRole, not tokens

A common mistake: generate a long-lived token, paste it into an app's environment, and forget it exists. Now you have the same forever-credential problem one layer up. If that token leaks, it works until someone notices.

For machines, use AppRole. The app proves its identity with a role_id (think username, not very secret) and a secret_id (think password, short-lived and delivered separately), and gets back a token scoped to exactly what it needs.

vault auth enable approle

# Create a role for the payments service.
vault write auth/approle/role/payments-api \
    token_policies="payments-api" \
    token_ttl=1h \
    token_max_ttl=4h \
    secret_id_ttl=24h \
    secret_id_num_uses=1

# role_id is stable and tied to the role.
vault read auth/approle/role/payments-api/role-id

Key        Value
---        -----
role_id    7b1c4e2a-9f3d-4a8e-b6c1-2d5f8e0a1b3c

The secret_id is the part that needs care. Generate it just before the app starts and hand it over once. With secret_id_num_uses=1 it works exactly one time, so a leaked secret_id in a log is already useless.

vault write -f auth/approle/role/payments-api/secret-id

Key                   Value
---                   -----
secret_id             d8a3...e91f
secret_id_accessor    4c2b...77a0
secret_id_ttl         24h

The app logs in with both and gets a short-lived token:

vault write auth/approle/login \
    role_id="7b1c4e2a-9f3d-4a8e-b6c1-2d5f8e0a1b3c" \
    secret_id="d8a3...e91f"

Key                  Value
---                  -----
token                hvs.CAESI...
token_duration       1h
token_renewable      true
token_policies       ["default" "payments-api"]

That token dies in an hour unless the app renews it. The pattern that delivers the secret_id securely (a sidecar, a cloud instance identity, or Vault Agent) is its own topic, but the rule is simple: the role_id can live in config, the secret_id should be freshly minted and single-use.

Dynamic database credentials

This is the feature that changes how you think about secrets. Instead of one shared database password that every service knows, Vault creates a brand new database user for each request, with a short TTL, and deletes it when the lease expires.

Enable the database engine and point it at PostgreSQL:

vault secrets enable database

vault write database/config/orders-db \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="orders-readonly" \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/orders?sslmode=require" \
    username="vault-admin" \
    password="$ROOT_DB_PASSWORD"

The vault-admin account is the only static credential, and it is a privileged account Vault uses to create and drop other users. Now define a role that says what a generated user is allowed to do:

vault write database/roles/orders-readonly \
    db_name="orders-db" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
      GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Ask for credentials:

vault read database/creds/orders-readonly

Key                Value
---                -----
lease_id           database/creds/orders-readonly/Qm9iY...
lease_duration     1h
lease_renewable    true
password           A1a-9Zx2Kp4Lq7Rt0Vn3
username           v-approle-orders-rea-x7Qd2bN9

That username did not exist a second ago. Run the command again and you get a different user with a different password. Each service instance, each request if you want, gets its own credentials. When the lease ends, Vault runs the revocation statement and the user is gone from PostgreSQL.

Here is why this matters in numbers. A static password sits valid until a human rotates it, which in practice means months or years. A dynamic credential with a one-hour TTL is useless to an attacker an hour after it leaks.

The shrink in exposure window is the entire reason to run Vault. If you take one thing from this post, make it this section.

Encryption as a service with the transit engine

Sometimes you do not want to store a secret, you want to encrypt application data: a customer's tax ID, a token, a column in your database. The wrong move is to ship an AES key to every app and hope nobody loses it. The transit engine keeps the key inside Vault and exposes encrypt and decrypt operations. Your app sends plaintext and gets ciphertext back. It never sees the key.

vault secrets enable transit
vault write -f transit/keys/orders-pii

Encrypt some data (transit takes base64 input):

vault write transit/encrypt/orders-pii \
    plaintext=$(echo -n "4111-1111-1111-1111" | base64)

Key            Value
---            -----
ciphertext     vault:v1:8SDd4HCQ9p7Hf2bxN0kZ...
key_version    1

Store vault:v1:8SDd... in your database. To read it back:

vault write transit/decrypt/orders-pii \
    ciphertext="vault:v1:8SDd4HCQ9p7Hf2bxN0kZ..."

Key          Value
---          -----
plaintext    NDExMS0xMTExLTExMTEtMTExMQ==

Base64-decode that and you are back to the card number. The v1 prefix is the key version, which means you can rotate the key with vault write -f transit/keys/orders-pii/rotate and old ciphertext still decrypts while new writes use the fresh key. No key ever leaves Vault, so an app compromise leaks data the app could already see, not the key that protects all of it.

Least-privilege policies and the audit log

Tokens are only as safe as the policy attached to them. The payments-api policy referenced earlier should grant exactly what the service needs and nothing more:

# payments-api.hcl
# Read dynamic DB creds for the orders database.
path "database/creds/orders-readonly" {
  capabilities = ["read"]
}

# Encrypt and decrypt PII, but not manage or export the key.
path "transit/encrypt/orders-pii" {
  capabilities = ["update"]
}
path "transit/decrypt/orders-pii" {
  capabilities = ["update"]
}

vault policy write payments-api payments-api.hcl

Notice what is missing. No database/creds/orders-admin, no transit/keys/* management, no wildcard paths. If the payments token leaks, the attacker can read orders and decrypt PII for an hour, and that is the ceiling. When a request asks for something outside the policy, Vault refuses:

$ vault read database/creds/orders-admin
Error reading database/creds/orders-admin: Error making API request.
URL: GET https://vault-1.internal:8200/v1/database/creds/orders-admin
Code: 403. Errors:
* 1 error occurred:
    * permission denied

Turn on the audit log before you put anything real in Vault. It records every request and response (secrets are HMAC'd, not stored in clear) so you can answer "who read this secret and when" during an incident:

vault audit enable file file_path=/var/log/vault/audit.log

And when you do have an incident, dynamic secrets give you a clean kill switch. Revoke every credential a database role ever issued in one command:

vault lease revoke -prefix database/creds/orders-readonly

All revocation operations queued successfully!

Every dynamic user that role created gets dropped from the database. Try doing that with a shared password that lives in forty places.

Where to go next

You now have the shape of a real Vault setup: a sealed, persistent server; AppRole for machines; dynamic database credentials; transit for encryption; tight policies; and an audit trail. The static KV store is still there when you need it, but it should be the exception, not the default.

Concrete next steps:

Replace one static database password with a dynamic role this week. Pick a low-risk read-only service and cut over. Seeing credentials expire on their own is what makes the model click.
Stand up a 3-node Raft cluster, not a single server. One Vault node is a single point of failure for every secret you own. Run vault operator raft list-peers to confirm the cluster.
Deploy Vault Agent to handle AppRole login and token renewal so your apps read a rendered file or env var instead of calling the Vault API directly.
Set short TTLs and test revocation. Run vault lease revoke -prefix against a staging role and confirm the users vanish from your database. Know the command works before you need it at 2am.
Ship the audit log to your SIEM so secret access shows up next to the rest of your security telemetry.

Start with step one. Turning a single forever-password into a one-hour credential is the smallest change that removes the largest class of secret leaks you have.

10 GitHub Repositories That Will Actually Teach You DevOps in 2026

DevOps Daily — Tue, 05 May 2026 18:11:07 +0000

There are roughly a thousand "top DevOps repos" listicles, and most of them are the same five awesome-lists in a different order. The problem with awesome-lists is that they are link directories. They tell you where to look, not what to do. If you want to actually get better at DevOps, you need a different shape of repo: ones with exercises, opinionated learning paths, hands-on demos, and source you can read and learn from.

So here are ten GitHub repositories that have moved real engineers from "I have heard of Kubernetes" to "I run it in production." We will start with the one we maintain on this site, then walk through the rest in order of star count, with notes on who each one is for and how to get the most out of it.

TLDR

#	Repo	Stars	Best for
1	The-DevOps-Daily/devops-daily	1k+	Tutorials, exercises, and quizzes across the stack
2	nilbuild/developer-roadmap	354k	Visual roadmap to plan your learning
3	bregman-arie/devops-exercises	82k	Interview prep and practice questions
4	kelseyhightower/kubernetes-the-hard-way	48k	Building Kubernetes from scratch
5	MichaelCade/90DaysOfDevOps	29k	A structured 90-day plan
6	milanm/DevOps-Roadmap	19k	Roadmap with linked study resources
7	ramitsurana/awesome-kubernetes	16k	Curated Kubernetes deep-dive material
8	dastergon/awesome-sre	13k	SRE-specific reading list
9	stefanprodan/podinfo	6k	A real microservice to deploy with GitOps
10	wmariuss/awesome-devops	4k	Broader DevOps tooling and practices

Star counts are pulled fresh from the GitHub API as of May 2026.

1. The-DevOps-Daily/devops-daily

github.com/The-DevOps-Daily/devops-daily. the source for everything you read on this site, fully open source.

We did not put ourselves at the top because we own the site. We put ourselves at the top because the way the repo is structured is a fast loop: every blog post, exercise, quiz, flashcard, checklist, and interview question is a markdown or JSON file you can read, fork, and PR into. If you find a typo, a broken command, or an outdated CLI flag, you can fix it. If you have a better explanation of how kubelet eviction works, you can add a card to the relevant flashcard deck.

How to use it:

Browse the content/ directory. Pick a topic you want to get better at and run through the exercise.
Use the quizzes for spaced retrieval. Repeat until you stop getting things wrong.
Submit a PR when you find something to improve. The maintainers (us) review fast and merge most of the time.

Best for engineers who learn by doing, contributing, and seeing the underlying source of every lesson.

2. nilbuild/developer-roadmap

github.com/nilbuild/developer-roadmap. 354k stars. Originally kamranahmedse/developer-roadmap, now under the nilbuild org. The DevOps roadmap is at roadmap.sh/devops.

This is a visual map of the skills, tools, and concepts that make up a DevOps career. It is the single best document on the internet for answering "what should I learn next?" without reinventing your own learning plan from scratch.

How to use it:

Open the DevOps roadmap. Identify the area you are weakest in.
Click any node to get a short explanation, links, and a checklist.
Mark items as you go. The site keeps your progress in localStorage if you do not sign up.

Best for people who feel scattered and want a single picture of the field.

3. bregman-arie/devops-exercises

github.com/bregman-arie/devops-exercises. 82k stars. Maintained by Arie Bregman, ex-Red Hat.

This repository is the reason a lot of engineers passed their DevOps interviews. It is hundreds of practical questions and exercises across Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, and more. Each topic has a mix of explanation questions ("What is X and when do you use it?") and hands-on exercises ("Write the Terraform module that does X").

How to use it:

Pick a topic. Try to answer the questions out loud or in writing without looking at the answers.
Star the ones you got wrong. Come back to them in a week.
Use it as a barometer. If you can answer most of the Kubernetes section without help, you know your Kubernetes is solid.

Best for interview preparation and finding gaps in your knowledge.

4. kelseyhightower/kubernetes-the-hard-way

github.com/kelseyhightower/kubernetes-the-hard-way. 48k stars. The repo description is honest: "Bootstrap Kubernetes the hard way. No scripts."

If you have only ever used gcloud container clusters create or eksctl, you have used Kubernetes. You have not learned it. This walkthrough has you stand up a control plane and worker nodes by hand, with TLS certificates you generated yourself, etcd you configured yourself, and a kubelet you registered yourself.

It is also a primary reason Kelsey Hightower has the reputation he has, which is its own kind of education.

How to use it:

Block out a weekend. The full walkthrough takes 6 to 10 hours the first time.
Do not copy commands. Type them. Read what they do before you run them.
When something breaks (and it will), debug it. That is the entire point.

Best for engineers who want a deep mental model of Kubernetes internals.

5. MichaelCade/90DaysOfDevOps

github.com/MichaelCade/90DaysOfDevOps. 29k stars. Three years of community-curated 90-day plans.

This started as one engineer's public learning project: 90 days, one DevOps topic per day, write what you learned. It exploded, and is now a structured tour through Linux, networking, programming, containers, Kubernetes, IaC, observability, databases, and serverless across three different yearly cohorts. The format is one folder per day with notes, diagrams, and links.

How to use it:

Treat it as a TV series, not a textbook. Watch one "episode" a day for 90 days.
Skip topics you already know. Spend extra time on the ones that feel uncomfortable.
Read previous cohorts' notes when you finish a day. The 2022, 2023, and 2024 versions cover slightly different angles on the same material.

Best for engineers early in their career who want a forced curriculum.

6. milanm/DevOps-Roadmap

github.com/milanm/DevOps-Roadmap. 19k stars. A different style of roadmap from #2.

Where the nilbuild roadmap is a visual node graph, this one is a long markdown document with curated links, books, courses, and YouTube videos for every step of the path. It is heavier on resources, lighter on the conceptual map.

How to use it:

Read the introduction. Identify which "phase" of the roadmap you are at.
Pick one resource per concept. Do not read all five linked resources for the same topic. Pick the format that matches how you learn best.
Use the prompts at the end of each section as a checklist before moving on.

Best for self-taught engineers building their own curriculum.

7. ramitsurana/awesome-kubernetes

github.com/ramitsurana/awesome-kubernetes. 16k stars. The most thorough Kubernetes-specific awesome-list.

If your day job is Kubernetes-heavy and you want to specialize, this is the link directory you want. It has sections for everything: storage, networking, monitoring, security, multi-cluster, GitOps, service mesh, FinOps. Each link is annotated.

How to use it:

Bookmark the page. Use it as a research starting point when you need to evaluate tools in a category.
Watch the commit log. New tools get added regularly, so it doubles as a "what is happening in Kubernetes" feed.

Best for Kubernetes-track engineers and platform teams researching tools.

8. dastergon/awesome-sre

github.com/dastergon/awesome-sre. 13k stars. The SRE-flavored cousin.

DevOps and SRE overlap, but the SRE side weights toward reliability theory, incident response, observability, and the social engineering of running production systems. This repo is the curated reading list for that side: books (Google's SRE book, Charity Majors' work), papers, postmortems, blog posts, conference talks, training courses.

How to use it:

Read at least one published postmortem a week. The "Postmortems" section is gold.
The conference talks list is more useful than most paid SRE courses.
Pair it with kelseyhightower/kubernetes-the-hard-way if your SRE work is on a Kubernetes platform.

Best for engineers moving into SRE or platform-engineering roles.

9. stefanprodan/podinfo

github.com/stefanprodan/podinfo. 6k stars. A small Go web app that exists to be deployed.

This one is different from the others. podinfo is not a learning resource in the read-and-take-notes sense. It is a real microservice (Go, REST + gRPC, metrics, tracing, health checks) that is purpose-built to be the demo target in tutorials. It is what every Flux, Argo CD, Linkerd, Istio, and Cilium tutorial uses when they need a service to deploy. If you want to actually try a GitOps tool end-to-end, you build the platform, point it at podinfo's helm chart, and ship.

How to use it:

Stand up a kind or k3d cluster locally.
Install Flux or Argo CD and point it at the podinfo chart.
Roll out a canary. Add Linkerd. Add Prometheus. Each thing you add lets you exercise a different platform skill on a service that already works.

Best for engineers who learn by deploying, not reading.

10. wmariuss/awesome-devops

github.com/wmariuss/awesome-devops. 4k stars. Smaller than awesome-kubernetes, broader in scope.

This is the everything-DevOps awesome list: chaos engineering, configuration management, container orchestration, log management, monitoring, package management, secret management, service discovery. The size of the list is approachable, which is its main strength. You can scroll the whole thing in 15 minutes and have a real mental map of the DevOps tooling landscape.

How to use it:

Read the section headings before clicking any links. The taxonomy itself is a learning aid.
When evaluating a new category of tool (say, you have to pick a secret manager), use this as your starting set rather than Googling.

Best for engineers who want a manageable map of the whole DevOps tools world.

How to Actually Use a List Like This

Lists are starting points, not learning plans. The mistake people make is to star all ten repos and never come back. Avoid that:

Pick exactly one starting repo today. If you have no plan, start with #2 (the roadmap) to get one. If you have a plan, start with #4 (kubernetes-the-hard-way) to deepen it. If you are interview-prepping, start with #3 (devops-exercises).
Block calendar time. "I will learn DevOps in my spare time" does not work. "I will spend Thursdays from 7 to 9 PM on the kubernetes-the-hard-way walkthrough" works.
Build something. Pick one of the awesome-list categories you do not understand (say, "service mesh") and use podinfo (#9) plus a tool from the list to build a working setup. You will learn more in two hours of building than two weeks of reading.
Teach what you learned. Write a blog post. Submit a PR to #1 with a flashcard you made. Give a brown-bag at work. Teaching is the fastest way to find the gaps in what you thought you knew.

Bookmark this page and come back when you finish one repo. The list is not going anywhere.

Key Takeaways

Awesome-lists are link directories, not learning plans. Pair them with hands-on repos like #1, #4, and #9.
Star counts are not the same as quality, but they are a decent first filter. Anything above 5k stars in this space has been read by enough people to be roughly trustworthy.
The single best learning loop is read → build → teach. Most engineers do step one, skip step two, and never reach step three. The repos in this list are picked to support all three.
Start one. Finish one. Do not collect ten tabs and never close any of them.
Contribute back. Every repo in this list takes PRs. Even small ones (typo fixes, broken-link fixes) count. They also get you GitHub history that future employers can see.

If we missed a repo you think belongs here, open an issue on our repo and tell us which one. We update this list when something deserves to be on it.

Claude Code Hidden Features You Probably Missed

DevOps Daily — Wed, 01 Apr 2026 17:21:58 +0000

Most people use Claude Code to write code, fix bugs, and maybe generate a commit message. That's fine, but you're leaving a lot on the table.

Boris Cherny, the creator of Claude Code, recently shared a thread on X about features that even daily users tend to overlook. Some of these genuinely changed how I work. Here's a rundown of the ones worth knowing about.

TLDR

Claude Code has mobile sessions, automated scheduling, voice input, parallel agents, git worktrees, hooks, and a browser extension. Most people use about 20% of what it can do.

Move Your Session Anywhere with /teleport

You can start a session on your laptop and pick it up on your phone. Or move it to the web. The /teleport command transfers your full session context between devices.

The reverse also works. If you're reviewing something on your phone during a commute, you can /teleport it back to your terminal when you sit down.

There's also /remote-control which lets you connect to a running session from another device without transferring it.

# On your laptop
/teleport

# On your phone or web - enter the code to pick up the session

This is useful when you kick off a long-running task on your workstation and want to check progress from your phone.

Automate Repetitive Tasks with /loop and /schedule

This one is a genuine workflow changer. You can tell Claude Code to run a task on a recurring schedule for up to a week.

# Review PRs every 30 minutes
/loop 30m review open PRs and post comments

# Run a health check every hour
/schedule every 1h check if the staging environment is healthy

Think about what you do repeatedly: reviewing PRs, checking CI status, monitoring deployments, updating dependencies. You can automate all of it without writing a single script.

Some practical examples:

Review all open PRs every morning at 9 AM
Monitor a Slack channel for feedback and create GitHub issues
Run your test suite after every push and report failures
Check for dependency updates weekly

Hooks for Deterministic Automation

Hooks let you run code at specific points in Claude Code's lifecycle. Unlike the AI-driven /loop command, hooks are deterministic - they always run the same way.

You configure them in your settings and they fire on events like:

Session start - set up your environment, load context
Before bash commands - validate or log commands before execution
On permission requests - auto-approve specific patterns
Continuous operation - keep Claude running without manual intervention

This is powerful for teams. You can enforce standards (like running linters before every commit) without relying on each engineer to remember.

Git Worktrees for Parallel Sessions

If you've ever wanted Claude to work on two different branches at the same time, worktrees make this possible. Each session gets its own isolated copy of the repo.

# Start a session in a worktree
claude --worktree

Why this matters: you can have Claude refactoring module A while simultaneously building feature B. Neither session interferes with the other.

This pairs well with /batch, which fans out work across dozens of parallel agents. Need to update 50 files? /batch can process them concurrently instead of one at a time.

Voice Input with /voice

You can dictate to Claude instead of typing. This sounds gimmicky until you try it for longer explanations.

/voice

It's particularly useful for:

Explaining complex requirements ("I need a migration that handles both the old and new schema formats, with a rollback path if...")
Code reviews ("Look at the authentication flow in this PR and tell me if...")
Brainstorming ("What's the best way to structure this API given these constraints...")

Typing detailed prompts takes time. Talking is faster for anything longer than a few sentences.

The Chrome Extension for Frontend Work

Claude Code has a Chrome extension that lets the AI see what your app looks like in the browser. Instead of describing UI bugs, Claude can verify its own output visually.

This closes the feedback loop for frontend work. Claude makes a change, checks the browser, adjusts if something looks off. You stop being the human screenshot tool.

/branch and --fork-session for Experiments

Want to try two different approaches to the same problem? /branch creates a copy of your current session so you can explore a different path without losing your progress.

# Fork the current session
/branch

# Or fork when starting
claude --fork-session <session-id>

This is like git branches but for your AI conversation. Try approach A in one branch, approach B in another, then pick the winner.

/btw for Side Questions

When Claude is working on a long task, you might have an unrelated question. Instead of interrupting the main task, /btw lets you ask a side question.

/btw what's the difference between SIGTERM and SIGKILL?

Claude answers your side question and goes right back to what it was doing. No context switching, no lost progress.

--bare for SDK Speed

If you're using Claude Code in scripts or CI pipelines, the --bare flag skips loading plugins and extra features, making startup up to 10x faster.

claude --bare -p "generate a migration for adding user roles"

This matters when you're calling Claude from automation scripts where every second counts.

--add-dir for Multi-Repo Work

Working across multiple repositories? You can give Claude access to all of them in a single session.

claude --add-dir ~/projects/api --add-dir ~/projects/frontend

Now Claude can see your API schema and your frontend code at the same time. No more copying types between repos or explaining your API structure manually.

Custom Agents with --agent

You can create custom agent configurations with their own system prompts and tool permissions.

claude --agent reviewer    # Uses your custom reviewer agent config
claude --agent deployer    # Uses your custom deployer agent config

Define these in your .claude/agents/ directory. Each agent can have different instructions, different tool access, and different behaviors. A code reviewer agent doesn't need write access. A deployment agent doesn't need to browse the web.

What This Means for DevOps

These features shift Claude Code from "AI code assistant" to "AI DevOps team member." The combination of scheduling, hooks, parallel sessions, and multi-repo access means you can automate workflows that previously required custom tooling.

Here's a realistic DevOps setup:

/schedule reviews all PRs every morning
Hooks enforce linting and security scanning on every session
Worktrees let you debug production while shipping features
--add-dir gives Claude access to your infra and app repos simultaneously
/loop monitors your staging environment and alerts you on issues

The key insight from Boris's thread: "There is no one right way to use Claude Code." The tool is intentionally flexible. Experiment with these features and build the workflow that fits your team.

Try It Out

If you haven't updated Claude Code recently, run:

claude update

Many of these features are recent additions. The mobile app, scheduling, and hooks in particular have been added in the last few months.

For more DevOps tools and guides, check out our exercises and quizzes to sharpen your skills.

This post was inspired by Boris Cherny's thread on X. Boris is the creator of Claude Code at Anthropic.

🎄 Advent of DevOps: 25 Days to Level Up Your DevOps Game!

DevOps Daily — Sun, 30 Nov 2025 22:00:00 +0000

Hey DevOps enthusiasts! 👋

Remember how exciting advent calendars were as a kid? Each day bringing a new surprise behind those little doors? Well, we're bringing that same excitement to the DevOps world, but instead of chocolate (sorry! 🍫), you're getting something even better: real-world DevOps skills that will make you a better engineer.

🎁 What is Advent of DevOps?

Think "Advent of Code" meets real-world DevOps challenges. Starting December 1st, we're releasing 25 daily hands-on challenges that cover everything you need to know to thrive in modern DevOps environments.

Each day unlocks a new practical challenge focusing on tools and techniques you'll actually use in production. No theory-heavy lectures, no boring slides—just pure, hands-on learning that you can apply immediately.

🚀 What's Inside?

Here's a taste of what you'll tackle over 25 days:

🐳 Containerization & Orchestration
⚙️ CI/CD & Automation
🏗️ Infrastructure as Code
🔒 Security & Observability
☁️ Cloud & Scaling

💡 Why Join?

🎯 Real-World Skills: Every challenge is based on actual scenarios you'll face in production

📈 Progressive Learning: Start easy, level up gradually. Whether you're a beginner or seasoned pro, there's something for you

🎮 Fun & Engaging: Gamified progress tracking makes learning addictive (in a good way!)

🌟 Community-Driven: Share solutions, learn from others, and grow together

⏰ Learn at Your Pace: Can't keep up daily? No problem! All challenges remain available year-round

🎄 How It Works

Pick Your Challenge: Start with Day 1 or jump to what interests you most
Get Hands-On: Each challenge includes clear tasks, starter code, and success criteria
Build & Learn: Complete the challenge at your own pace
Share & Celebrate: Post your wins and solutions with the community
Level Up: Review reference solutions and explanations to deepen your understanding

Each challenge includes:

✅ Clear task description
🎯 Success criteria
🔧 Starter code (when applicable)
💡 Solution & explanation
🔗 Additional resources

🌟 Join the Community

This isn't just about solo learning—it's about growing together!

Share your progress:

Follow us on X/Twitter: @thedevopsdaily
Use hashtag: #AdventOfDevOps
Share on LinkedIn, dev.to, wherever you hang out!

Contribute:

Found a cool solution? Share it!
Have ideas for challenges? We're open-source!
Check out our GitHub repo and contribute

🎯 Ready to Start?

Don't wait for December 1st to check it out—head over to the page now and get familiar with what's coming:

👉 devops-daily.com/advent-of-devops

Mark your calendar 📅, set your reminders ⏰, and get ready to transform your DevOps skills one day at a time!

🤔 Who Should Join?

DevOps Engineers looking to sharpen their skills
Developers wanting to understand the ops side better
System Administrators transitioning to DevOps
Students & Career Changers building practical experience
Anyone curious about modern infrastructure practices

No gatekeeping here, if you're interested in DevOps, you're welcome! 🙌

🎊 Let's Make This December Special

Learning doesn't have to be boring. It doesn't have to be stressful. And it definitely doesn't have to be lonely.

This December, join hundreds (thousands?) of DevOps practitioners around the world in leveling up together. One challenge at a time, one skill at a time, one day at a time.

See you on December 1st! 🎄✨

P.S. - Can't wait? Start exploring the challenges now at devops-daily.com/advent-of-devops. They're already live and ready for early birds! 🐦

P.P.S. - This is completely free, open-source, and community-driven. No paywalls, no upsells, just pure learning. If you find value, give us a star on GitHub and spread the word! ⭐

Follow DevOps Daily:

🐦 X/Twitter: @thedevopsdaily
💻 GitHub: The-DevOps-Daily/devops-daily
🌐 Website: devops-daily.com

Happy DevOps-ing! 🚀

Building a DDoS Attack Simulator to Understand Defense Strategies

DevOps Daily — Fri, 21 Nov 2025 09:53:22 +0000

I created an educational content piece for DevOps Daily and realized something: most explanations of DDoS attacks are either too abstract or too technical. We talk about "request floods" and "mitigation strategies," but it's hard to visualize what's actually happening.

So I built an interactive simulator to help bridge that gap.

The Problem with Learning About DDoS 📚

When you're reading about DDoS protection, you see phrases like "distributes load across multiple servers" or "rate limiting prevents abuse." But what does that actually mean when thousands of requests are hitting your infrastructure?

I wanted something that would help people - especially those newer to infrastructure work - actually see these concepts in action.

What the Simulator Does 🎮

You can try it here: devops-daily.com/games/ddos-simulator

It lets you simulate three common attack types:

HTTP Flood 🌊 - overwhelming with legitimate-looking requests
SYN Flood 🔄 - exploiting TCP handshake mechanics
UDP Flood 📦 - connectionless packet storms

The interesting part is watching how different defense mechanisms respond. You can toggle:

Firewall 🛡️ - blocks about 30% based on signatures
Load Balancer ⚖️ - reduces impact by 50%
Auto Rate Limit 🚦 - blocks high-frequency traffic

What I Learned Building It 💡

A few things became clear while working on this:

Attack intensity matters less than you'd think. The attack type and your defense configuration matter way more. A moderate SYN flood with no defenses is worse than an intense HTTP flood with proper rate limiting.

Single defenses aren't enough. This is obvious in theory, but seeing it play out makes it concrete. A firewall alone, or a load balancer alone, only gets you so far.

Visualization helps understanding. Watching the server health bar drop while packets animate across the screen creates an intuition that documentation doesn't.

Who Might Find This Useful ⚙️

If you're:

Learning about infrastructure security
Trying to explain DDoS concepts to your team
Deciding what protections to implement
Just curious how attacks and defenses interact

It might be helpful to play around with it for a bit.

What's Next 🚀

I'm planning to add more waves with additional attack vectors and defense mechanisms. Things like:

Application-layer attacks
CDN protection
Anycast routing
More realistic traffic patterns

If you have thoughts on what would be useful to include, I'd be interested to hear them.

The goal here is education, not creating chaos. Understanding how attacks work helps you build better defenses. 🛡️

If you try it out, let me know what you think or if anything is unclear.

Right-Sizing Kubernetes Resources with VPA and Karpenter

DevOps Daily — Fri, 22 Aug 2025 17:02:04 +0000

TLDR

Setting CPU and memory requests too high in Kubernetes wastes money and reduces cluster efficiency. This guide shows you how to identify overprovisioned workloads, use Vertical Pod Autoscaler (VPA) to right-size your pods, and implement Karpenter for smarter node scaling. You'll also learn to monitor costs and validate your improvements with real metrics.

When you set resource requests too conservatively in Kubernetes, your cluster reserves more capacity than workloads actually need. This leads to underutilized nodes and higher cloud bills. The problem gets worse at scale - imagine 200 pods each requesting 2 CPU cores but only using 200m. That's 400 reserved cores when actual demand is closer to 40 cores.

The solution involves right-sizing both your pods and nodes. You'll use monitoring data to understand actual usage, apply VPA to adjust pod requests automatically, and leverage Karpenter to provision nodes that match your workload requirements.

Prerequisites

Before you start, make sure you have:

A Kubernetes cluster (version 1.20 or higher) with metrics-server installed
kubectl configured with admin access to your cluster
Prometheus and Grafana deployed for monitoring (or similar observability stack)
Basic understanding of Kubernetes resource requests and limits

You'll also need the ability to install cluster-wide components like VPA and Karpenter.

Identifying Overprovisioned Workloads

The first step is understanding how your current workloads use resources compared to what they request. You can start with kubectl to get a quick snapshot of resource usage across your cluster.

# Check current resource usage for all nodes
kubectl top nodes

# View pod resource usage across all namespaces
kubectl top pods --all-namespaces --sort-by=cpu

# Get detailed resource requests vs usage for a specific namespace
kubectl describe nodes | grep -A 15 "Allocated resources"

These commands show you the gap between requested and actual resource usage. If you see pods consistently using 50Mi of memory while requesting 1Gi, or using 100m CPU while requesting 1000m, those are prime candidates for right-sizing.

For deeper analysis, you'll want historical data from Prometheus. Here are some key queries to run in your Grafana dashboard:

# CPU utilization percentage (actual usage vs requests)
(rate(container_cpu_usage_seconds_total{container!=""}[5m]) * 100) /
(container_spec_cpu_quota{container!=""} / container_spec_cpu_period{container!=""})

# Memory utilization percentage
(container_memory_working_set_bytes{container!=""} * 100) /
container_spec_memory_limit_bytes{container!=""}

# Top 10 pods with the highest request-to-usage ratio (biggest waste)
topk(10,
  (container_spec_cpu_quota{container!=""} / container_spec_cpu_period{container!=""}) /
  rate(container_cpu_usage_seconds_total{container!=""}[5m])
)

Run these queries over a 2-week period to account for traffic variations and identify consistent patterns. Workloads running at 10-20% utilization with stable traffic are good candidates for optimization.

Installing and Configuring VPA

Vertical Pod Autoscaler analyzes your workloads and recommends optimal CPU and memory values. Start by installing VPA in your cluster.

# Clone the VPA repository
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler

# Deploy VPA components
./hack/vpa-up.sh

This script installs three main components: the VPA recommender (analyzes usage), the updater (applies changes), and the admission controller (validates recommendations).

Next, create a VPA configuration for a workload you want to optimize. Start with recommendation mode to see suggested values before making changes.

# vpa-web-service.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-service-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: 'apps/v1'
    kind: Deployment
    name: web-service
  updatePolicy:
    updateMode: 'Off' # Only provide recommendations, don't auto-update
  resourcePolicy:
    containerPolicies:
      - containerName: web-app
        # Set boundaries to prevent extreme recommendations
        maxAllowed:
          cpu: '2'
          memory: '4Gi'
        minAllowed:
          cpu: '100m'
          memory: '128Mi'
        controlledResources: ['cpu', 'memory']

Apply the VPA configuration and wait for recommendations to generate:

kubectl apply -f vpa-web-service.yaml

# Wait a few minutes, then check recommendations
kubectl describe vpa web-service-vpa -n production

The output shows recommended values for CPU and memory under the Status section. VPA typically suggests values based on the 90th percentile of usage over the past 8 days, which provides a safety buffer while eliminating waste.

Applying VPA Recommendations Safely

Once you have solid recommendations, you can apply them gradually. Start with non-critical workloads and monitor for any issues.

# Update your deployment with VPA recommendations
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-service
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-service
  template:
    metadata:
      labels:
        app: web-service
    spec:
      containers:
        - name: web-app
          image: nginx:1.21
          resources:
            requests:
              cpu: '250m' # Reduced from 1000m based on VPA recommendation
              memory: '512Mi' # Reduced from 2Gi based on VPA recommendation
            limits:
              cpu: '500m' # Set limits 2x requests for burst capacity
              memory: '1Gi'

After updating requests, monitor your workloads for at least a week. Watch for:

Increased pod restarts or OOMKilled events
Higher response times or error rates
Pods getting evicted under memory pressure

If everything runs smoothly, you can switch VPA to automatic mode:

# Update VPA to automatically apply changes
kubectl patch vpa web-service-vpa -n production --type='merge' -p='{"spec":{"updatePolicy":{"updateMode":"Auto"}}}'

In Auto mode, VPA will restart pods when it detects they need different resource allocations. Make sure you have proper PodDisruptionBudgets in place to maintain availability during updates.

Setting Up Karpenter for Node Optimization

While VPA optimizes individual pods, Karpenter optimizes your entire node infrastructure. Instead of fixed node groups, Karpenter provisions nodes dynamically based on your workload requirements.

First, install Karpenter in your cluster. The exact steps depend on your cloud provider, but here's the process for AWS EKS:

# Install Karpenter using Helm
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "0.32.0" \
  --namespace "karpenter" \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueueName=${CLUSTER_NAME}" \
  --wait

Next, create a NodePool that defines what types of nodes Karpenter can provision:

# karpenter-nodepool.yaml
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: general-purpose
spec:
  # Template for nodes Karpenter will create
  template:
    metadata:
      labels:
        node-type: general-purpose
    spec:
      # Instance requirements - Karpenter will pick the best fit
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ['amd64']
        - key: karpenter.sh/capacity-type
          operator: In
          values: ['spot', 'on-demand'] # Allow both for cost optimization
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ['m6i.large', 'm6i.xlarge', 'm6i.2xlarge', 'r6i.large', 'r6i.xlarge']

      # Node configuration
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1beta1
        kind: EC2NodeClass
        name: general-purpose

      # Taints to control which pods can schedule here
      taints:
        - key: karpenter.sh/unschedulable
          value: 'true'
          effect: NoSchedule

  # Scaling and disruption policies
  limits:
    cpu: 1000 # Maximum CPU across all nodes in this pool
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s

Create the corresponding EC2NodeClass for AWS-specific configuration:

# karpenter-nodeclass.yaml
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
  name: general-purpose
spec:
  # AMI and instance configuration
  amiFamily: AL2
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: '${CLUSTER_NAME}'
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: '${CLUSTER_NAME}'

  # Instance store configuration
  userData: |
    #!/bin/bash
    /etc/eks/bootstrap.sh ${CLUSTER_NAME}

  # Tags for cost tracking
  tags:
    Team: platform
    Environment: production

Apply both configurations:

kubectl apply -f karpenter-nodepool.yaml
kubectl apply -f karpenter-nodeclass.yaml

Karpenter will now monitor unschedulable pods and provision appropriately-sized nodes. When you deploy workloads with right-sized resource requests (thanks to VPA), Karpenter will select smaller, more cost-effective instances.

Monitoring Cost Impact

To validate your optimizations, you need visibility into resource costs. Kubecost provides detailed insights into how much each workload costs and how much capacity you're wasting.

Install Kubecost in your cluster:

# Add the Kubecost Helm repository
helm repo add kubecost https://kubecost.github.io/cost-analyzer/

# Install Kubecost with Prometheus integration
helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set kubecostToken="your-token-here" \
  --set prometheus.server.global.external_labels.cluster_id="${CLUSTER_NAME}"

Access the Kubecost UI by port-forwarding:

kubectl port-forward -n kubecost deployment/kubecost-cost-analyzer 9090:9090

In the Kubecost dashboard, focus on these key metrics:

Efficiency scores: Shows the percentage of requested resources actually being used
Idle costs: Money spent on provisioned but unused resources
Right-sizing recommendations: Suggestions for adjusting requests and limits
Namespace costs: Helps identify which teams or applications drive costs

Track these metrics before and after implementing VPA and Karpenter to quantify your savings.

Real-World Optimization Example

Let's walk through optimizing a typical microservice deployment. You start with a Node.js API that was conservatively configured:

# Before optimization
resources:
  requests:
    cpu: '1000m'
    memory: '2Gi'
  limits:
    cpu: '2000m'
    memory: '4Gi'

After running this workload for two weeks, your monitoring shows:

Average CPU usage: 150m (15% of requests)
Average memory usage: 400Mi (20% of requests)
Peak CPU usage: 300m
Peak memory usage: 800Mi

Based on this data, VPA recommends:

# VPA recommendations (with safety buffer)
resources:
  requests:
    cpu: '200m' # Covers 99th percentile usage
    memory: '512Mi' # Accounts for memory spikes
  limits:
    cpu: '400m' # 2x requests for burst capacity
    memory: '1Gi' # Prevents OOM while allowing growth

The cost impact for 20 replicas of this service:

Before: 20 CPU cores, 40Gi memory requested
After: 4 CPU cores, 10Gi memory requested
Savings: 80% reduction in resource allocation

With Karpenter managing nodes, this workload now runs on smaller instances, further reducing costs by eliminating the need for oversized nodes.

Setting Resource Quotas and Guardrails

As you roll out right-sizing across your organization, implement quotas to prevent teams from reverting to oversized requests:

# namespace-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: backend-team-quota
  namespace: backend
spec:
  hard:
    requests.cpu: '50' # Total CPU requests across all pods
    requests.memory: '100Gi' # Total memory requests
    limits.cpu: '100' # Total CPU limits
    limits.memory: '200Gi' # Total memory limits
    pods: '100' # Maximum number of pods

You can also create LimitRanges to enforce reasonable defaults:

# limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: pod-limits
  namespace: backend
spec:
  limits:
    - type: Container
      default: # Default limits if not specified
        cpu: '500m'
        memory: '1Gi'
      defaultRequest: # Default requests if not specified
        cpu: '100m'
        memory: '256Mi'
      max: # Maximum allowed values
        cpu: '4'
        memory: '8Gi'
      min: # Minimum required values
        cpu: '50m'
        memory: '64Mi'

These guardrails help maintain optimization gains while giving teams flexibility within reasonable bounds.

Troubleshooting Common Issues

When implementing VPA and Karpenter, you might encounter some challenges. Here are solutions to the most common problems:

VPA recommendations seem too aggressive: VPA sometimes suggests very low values during low-traffic periods. Check that your monitoring data covers representative traffic patterns. You can also adjust the VPA algorithm:

spec:
  resourcePolicy:
    containerPolicies:
      - containerName: web-app
        controlledValues: RequestsOnly # Only adjust requests, leave limits alone
        mode: Auto

Karpenter nodes aren't scaling down: This usually happens when pods can't be evicted. Check for:

# Look for pods without PodDisruptionBudgets
kubectl get pods --all-namespaces -o wide | grep -v Terminating

# Check for pods using local storage or host networking
kubectl get pods --all-namespaces -o yaml | grep -A 5 hostNetwork

# Verify PodDisruptionBudgets allow eviction
kubectl get pdb --all-namespaces

Pods getting OOMKilled after VPA optimization: This indicates VPA recommendations were too low. Temporarily increase memory requests and check for memory leaks in your application:

# Check recent OOM events
kubectl get events --sort-by=.metadata.creationTimestamp | grep OOMKilled

# Monitor memory usage patterns
kubectl top pods --sort-by=memory --all-namespaces

You can make VPA more conservative by setting higher safety margins:

spec:
  resourcePolicy:
    containerPolicies:
      - containerName: web-app
        maxAllowed:
          memory: '2Gi' # Set a reasonable upper bound

Next Steps

Now that you have VPA and Karpenter working together, consider these additional optimizations:

Horizontal Pod Autoscaling: Combine with VPA to handle both vertical and horizontal scaling
Cluster Autoscaler tuning: If using multiple node provisioners, configure them to work together
Cost alerts: Set up notifications when resource costs exceed thresholds
Regular reviews: Schedule monthly reviews of VPA recommendations and cost reports

You can also explore more advanced Karpenter features like multiple NodePools for different workload types (CPU-intensive, memory-intensive, GPU workloads) and spot instance strategies for non-critical workloads.

The key is to treat right-sizing as an ongoing process. As your applications evolve and traffic patterns change, continue monitoring and adjusting to maintain optimal resource utilization.