DEV Community: Amaresh Pelleti

Ollama Model Library, By the Numbers

Amaresh Pelleti — Sun, 06 Sep 2026 14:21:50 +0000

Someone asks "what's the best Ollama model" in a Discord or a Reddit thread almost every day. The answer usually comes from memory, or a single favorite. So we pulled the actual data instead. Every model in the Ollama model library, its pull count, its capability tags, and when it was last updated. Current as of September 5, 2026 — the library changes weekly, so treat these counts as a snapshot, not a permanent ranking.

What's in the Ollama model library right now

The Ollama model library holds 239 models as of this pull. That spans general chat models, embeddings, vision models, and a growing "cloud" category that runs on Ollama's hosted infrastructure instead of your GPU. Combined, every model in the library has been pulled just over 1.04 billion times.

That total tells you less than it looks like it should. Pulls aren't spread evenly. A handful of general-purpose chat models account for most of it. The long tail of specialized or older models barely registers.

Where Ollama model library pulls actually concentrate

The top 10 models by pull count account for 56.4% of all pulls in the entire library. Meta's Llama family and DeepSeek's reasoning models lead by a wide margin:

Rank	Model	Pulls	Capabilities
1	`llama3.1`	119.2M	tools
2	`deepseek-r1`	92.4M	tools, thinking
3	`nomic-embed-text`	84.6M	embedding
4	`llama3.2`	82.4M	tools
5	`gemma3`	40.1M	vision
6	`qwen2.5`	39.3M	tools
7	`qwen3`	36.3M	tools, thinking
8	`mistral`	33.3M	tools
9	`gemma2`	31.8M	text only
10	`llama3`	25.2M	text only

Here's the thing about that list: it's mostly older releases. llama3.1 and llama3.2 alone outpull every newer Llama version combined. llama3 — several generations behind — still sits at 25.2M pulls. That's because pull counts accumulate over a model's lifetime. An older model with a long track record will always look bigger than a newer one that's objectively better. Don't read this table as "what to use today." Read it as "what people have been defaulting to."

nomic-embed-text at #3 breaks the chat-model pattern. It's a pure embedding model. Its position this high says a lot about how much RAG and semantic-search tooling runs on Ollama underneath the chat interfaces people actually see.

How many Ollama models actually support tool calling

If you're building an agent, this number matters more than pull count. Only 93 of 239 models (38.9%) carry the tools capability tag. The rest either don't support structured tool calling, or Ollama hasn't tagged them for it.

The full capability breakdown across the library:

Tools (function calling): 93 models — 38.9%
Thinking (extended reasoning): 42 models — 17.6%
Vision: 38 models — 15.9%
Cloud (hosted, not local): 18 models — 7.5%
Embedding: 12 models — 5.0%
No special tag (plain text completion): 118 models — 49.4%

These overlap — a model like gemma4 carries vision, tools, thinking, and cloud tags at once. But the practical read is simple. Half the library is plain text completion. If your use case needs tool calling specifically, you're choosing from under 40% of what's listed. Check a model's tags on its library page before you build around it, not after.

Why the Ollama model library carries 7,359 tag variants

Across all 239 models, there are 7,359 individual tags. Each one is a different quantization, parameter size, or context configuration of the same base model. That averages out to roughly 30.8 variants per model, though it's lopsided — llama3.1 alone carries 93 tags, while a narrow embedding model might have 3.

This ties into the same issue covered in the Ollama vs LM Studio comparison. Ollama's model names default to a specific quantization, usually Q4_K_M, a 4-bit quant, without making that choice obvious on the model card. With 30+ tagged variants per model on average, "the model" isn't one thing — it's a family. The tag you don't specify is a decision Ollama makes for you. If you're benchmarking against another tool, pin the exact tag (ollama pull llama3.1:8b-instruct-q8_0, for example) instead of the bare model name.

How much of the Ollama model library is still maintained

Freshness in the library skews old. Of the 239 models:

174 (72.8%) were last updated over a year ago
51 (21.3%) were updated sometime this year
9 (3.8%) were updated this month
5 (2.1%) were updated this week

Nearly three-quarters of the library hasn't been touched in over a year. That's not automatically a red flag. A model's weights don't need updates the way a CLI tool does, and a good 2024 model is often still a good model. But it does mean the library is mostly an archive with a small, actively-tended front section. If a model card shows no update in over a year, and a same-family successor has recent activity, the successor is usually the safer default.

What this means if you're picking a model to run

Two practical takeaways come out of this data. First, pull count is a popularity signal, not a quality signal. It rewards models that have been available the longest. That's why year-old Llama releases still outrank newer, often better models. Cross-check pull count against a model's actual release date before treating it as a recommendation.

Second, the capability tags are the fastest filter for narrowing 239 models down to the ones that fit your use case. Building an agent? Filter to the 93 tools-tagged models first. Need a local embedding model for RAG? nomic-embed-text and mxbai-embed-large are the two with real usage behind them. For everything else — running the model once you've picked it — the hardware requirements guide and the Ollama API guide cover the setup.

Frequently Asked Questions

Q: How many models are in the Ollama library?
A: 239 models as of September 5, 2026. The Ollama model library is updated regularly, so this number changes — check ollama.com/library directly for the current count.

Q: What is the most popular model in the Ollama library?
A: llama3.1, with 119.2 million pulls, ahead of deepseek-r1 at 92.4 million and nomic-embed-text at 84.6 million. All three are well over a year old, which is typical — pull counts accumulate over time and favor established models.

Q: How many Ollama models support function calling?
A: 93 of 239 models (38.9%) carry the tools capability tag, which indicates support for structured function calling. Check the individual model's page on ollama.com to confirm before building an agent around it.

Q: Why does Ollama have so many tags for one model?
A: Each tag is a different quantization, parameter size, or configuration of the same base model. The library averages about 30.8 tags per model, and the untagged default usually points to a 4-bit quantization rather than the highest-quality version available.

Quick Summary:
– 239 models in the Ollama model library as of September 5, 2026, with 1.04 billion cumulative pulls.
– The top 10 models account for 56.4% of all pulls — usage concentrates hard in a handful of established releases.
– Only 38.9% of models carry the tools (function-calling) tag; 49.4% have no special capability tag at all.
– The library averages 30.8 tag variants per model, so the untagged default is a quantization choice you're making without realizing it.
– 72.8% of models haven't been updated in over a year — the library is mostly an archive with a small active front section.

If you've picked a model from this list and need to know whether your hardware can run it, the Ollama hardware requirements guide breaks down RAM and VRAM by model size. And if local hardware runs out before your model does, the Ollama Cloud pricing and limits guide covers the hosted tier.

Ollama API: A Practical Guide with Examples

Amaresh Pelleti — Fri, 04 Sep 2026 11:35:17 +0000

Every Ollama install runs a local HTTP server on port 11434, and that server is the real interface to the models. The ollama run command is a thin client on top of it. Once you know the two main endpoints, the streaming format, and the options object, you can wire a local model into any application.

There is also an OpenAI-compatible route, so existing code that talks to OpenAI can point at Ollama with a base-URL change.

How the Ollama API works

The Ollama API is a plain REST API served at http://localhost:11434. You send JSON with POST, and by default you get a stream of newline-delimited JSON objects back. No API key is required for local access.

Endpoint	Method	Purpose
`/api/generate`	POST	Single-prompt text completion
`/api/chat`	POST	Multi-turn chat with message history and tools
`/api/embed`	POST	Generate embeddings
`/api/tags`	GET	List installed models
`/api/ps`	GET	List models currently loaded in memory
`/api/pull`	POST	Download a model

Check the server with curl http://localhost:11434/api/version.

Generating text: /api/generate and /api/chat

Use /api/generate for a single prompt with no history:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.1",
  "prompt": "Summarize in one sentence: Ollama serves a local HTTP API on port 11434.",
  "stream": false
}'

Use /api/chat for turn-by-turn context or tool calling. Pass a messages array with role values of system, user, assistant, or tool, and send the whole history on each request:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [
    {"role": "system", "content": "You answer in one short sentence."},
    {"role": "user", "content": "What is the KV cache?"}
  ],
  "stream": false
}'

For application code, /api/chat is the better default even for single questions.

Streaming and response metrics

By default stream is true, and Ollama returns one JSON object per chunk. The final chunk has "done": true plus timing data:

{"model":"llama3.1","response":"","done":true,
 "total_duration":4883583458,"prompt_eval_count":26,
 "eval_count":298,"eval_duration":3789981000}

All durations are in nanoseconds. Tokens per second is eval_count / eval_duration * 1e9. Set "stream": false for a single response object.

Setting model options

The options object tunes sampling and context per request:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "Name three container runtimes."}],
  "stream": false,
  "options": {"temperature": 0.2, "num_ctx": 8192, "num_predict": 200, "seed": 42, "stop": ["\n\n"]}
}'

temperature — lower is more deterministic
num_ctx — context window in tokens for this request
num_predict — cap on generated tokens
seed — with temperature: 0, gives repeatable output
stop — strings that end generation

Setting num_ctx above what your hardware holds forces a partial CPU offload. Confirm with ollama ps.

Structured JSON output from the Ollama API

Set format to "json" for any valid JSON, or pass a JSON schema object to force a shape:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "List two Linux distros with release years. Respond in JSON."}],
  "stream": false,
  "format": {
    "type": "object",
    "properties": {
      "distros": {"type": "array", "items": {
        "type": "object",
        "properties": {"name": {"type": "string"}, "year": {"type": "integer"}},
        "required": ["name", "year"]
      }}
    },
    "required": ["distros"]
  }
}'

Keep the word "JSON" in the prompt and use a low temperature.

Tool calling with the Ollama API

/api/chat supports function calling through a tools array. The model replies with a tool_calls entry instead of text when it decides to use one:

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "What is the weather in Toronto?"}],
  "stream": false,
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "Get the current weather for a city",
      "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}
    }
  }]
}'

Run the function, then send the result back as a message with "role": "tool". Tool support depends on the model.

Calling the Ollama API from Python

Install with pip install ollama.

from ollama import chat

response = chat(model='llama3.1', messages=[
    {'role': 'user', 'content': 'Why is the sky blue?'},
])
print(response.message.content)

Streaming:

from ollama import chat

stream = chat(model='llama3.1',
    messages=[{'role': 'user', 'content': 'Explain the KV cache in two sentences.'}],
    stream=True)
for chunk in stream:
    print(chunk['message']['content'], end='', flush=True)

Remote host:

from ollama import Client
client = Client(host='http://192.168.1.50:11434')

There is an AsyncClient with the same methods, plus embed(), list(), ps(), and pull().

The OpenAI-compatible endpoint

Ollama serves an OpenAI-style API at http://localhost:11434/v1 with /v1/chat/completions, /v1/completions, /v1/embeddings, and /v1/models:

from openai import OpenAI

client = OpenAI(base_url='http://localhost:11434/v1', api_key='ollama')
response = client.chat.completions.create(
    model='llama3.1',
    messages=[{'role': 'user', 'content': 'Hello'}],
)
print(response.choices[0].message.content)

The api_key is required by the SDK but ignored by Ollama. Use /v1 for compatibility and /api for full features.

Securing the Ollama API for remote access

The Ollama API has no built-in authentication. Anyone who can reach port 11434 can use, pull, or delete your models. Keep it bound to 127.0.0.1 and put a reverse proxy in front with auth and TLS:

server {
    listen 443 ssl;
    server_name ollama.example.com;
    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
        auth_basic "Ollama";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

Setting OLLAMA_HOST=0.0.0.0 without a proxy puts an unauthenticated model server on the open network. Only do that inside a private network or behind an IP-restricted firewall.

Frequently Asked Questions

Q: What port does the Ollama API use?
A: Port 11434 on 127.0.0.1 by default. Change it with OLLAMA_HOST, for example OLLAMA_HOST=0.0.0.0:11434.

Q: Does the Ollama API need an API key?
A: No, not for local use. Ollama's hosted cloud models use a key; self-hosted remote access should sit behind a reverse proxy that adds authentication.

Q: What is the difference between /api/generate and /api/chat?
A: /api/generate takes a single prompt string. /api/chat takes a messages array with roles and supports tool calling. Use /api/chat for application code.

Q: How do I get JSON output from the Ollama API?
A: Set format to "json" or to a JSON schema object. Keep the word "JSON" in your prompt and use a low temperature.

Q: Can I use the OpenAI Python SDK with Ollama?
A: Yes. Point base_url at http://localhost:11434/v1 and pass any non-empty api_key.

Ollama Hardware Requirements: RAM, VRAM and GPU

Amaresh Pelleti — Fri, 04 Sep 2026 11:33:50 +0000

Ollama runs a model by loading its weights into memory. So the size of the model file is the number that decides what hardware you need. For example, a 4-bit 8B model is about 5 GB on disk. It needs roughly that much free memory plus overhead to run. But push to a 70B model and you are looking at 40 GB or more. This guide gives the real numbers by model size, explains GPU versus CPU, and covers the setting most people miss: context length.

The Ollama hardware requirements come down to one formula. Memory needed is roughly the model file size, plus 1 to 2 GB of overhead, plus the KV cache for your context window. Everything below is that formula applied.

What are the Ollama hardware requirements?

The baseline is simple. First, you need enough free RAM or VRAM to hold the model file plus about 20% headroom. Ollama's model tags like llama3.1 or gemma3 default to Q4_K_M, a 4-bit quantization, so the download sizes on ollama.com are already compressed.

The official README sets the baseline: at least 8 GB of RAM for 7B models, 16 GB for 13B models, and 32 GB for 33B models. That holds up in practice for 4-bit quants at a modest context length. However, larger context windows and running multiple models at once push those numbers higher.

Storage matters too. Models live in ~/.ollama/models, or /usr/share/ollama/.ollama/models on a Linux service install. A single 70B model is about 40 GB on disk. So it is easy to fill a drive if you pull several large models to compare them.

Ollama hardware requirements by model size

These figures assume the default 4-bit quantization and a small-to-moderate context window. Add memory for larger context (see below).

Model size	Approx. file size (Q4)	Minimum RAM (CPU)	Comfortable GPU VRAM	Example GPU
1B–3B	0.7–2 GB	8 GB	4 GB	Most modern GPUs, integrated graphics
7B–8B	4.5–5 GB	8 GB	6–8 GB	RTX 3060, RTX 4060
12B–14B	7–9 GB	16 GB	12 GB	RTX 3060 12GB, RTX 4070
27B–32B	16–20 GB	32 GB	24 GB	RTX 3090, RTX 4090
70B	40–43 GB	64 GB	48 GB	RTX 6000 Ada, 2× RTX 3090
120B+ / MoE	65 GB and up	128 GB+	80 GB+	A100, H100, multi-GPU

Planning to serve a model to more than one request at a time? Then multiply the context memory by the number of parallel slots. Ollama's OLLAMA_NUM_PARALLEL controls that count, and each slot needs its own slice of KV cache. For a broader look at which models are worth running, see the best open-source LLMs roundup.

Do you need a GPU to run Ollama?

No. Ollama runs on CPU alone, and a 7B model on a modern multi-core CPU with fast RAM produces a few tokens per second. That is usable for scripts and batch jobs but slow for interactive chat.

A GPU changes the experience. When a compatible GPU fits the whole model in VRAM, Ollama loads every layer there. So inference is often 10 to 30 times faster than CPU. But when the model does not fit, Ollama does a partial offload. It puts as many layers as possible on the GPU and runs the rest on the CPU. That works, however speed drops sharply because every token now waits on the slow path.

⚠️ Note: a partial offload can be slower than pure CPU in some cases because of the constant copying between GPU and system RAM. If ollama ps shows a CPU/GPU split, either use a smaller model or a smaller quantization so the whole thing fits in VRAM.

For CPU-only inference, RAM bandwidth is the bottleneck, not core count. DDR5 and dual-channel memory help more than extra cores. The DigitalOcean droplet setup guide shows CPU-only sizing for a cloud server.

Which GPUs does Ollama support?

Ollama supports three GPU paths, and the requirements differ:

NVIDIA: compute capability 5.0 and higher, with driver 550 or newer (570+ for the oldest supported cards). This covers everything from the GTX 900 series through the RTX 50 series, and you can confirm a card on the NVIDIA CUDA GPUs list. NVIDIA is the most tested path.
AMD: on Linux, ROCm v7 drivers are required. Supported cards include the Radeon RX 9000 and RX 7000 series, parts of the RX 6000 series, Radeon PRO W-series, and Instinct accelerators. Windows support is narrower.
Apple Silicon: Ollama uses the Metal API on M-series Macs with no extra setup. Unified memory means the GPU can address most of system RAM (more on this below).

To limit Ollama to specific GPUs, set CUDA_VISIBLE_DEVICES (NVIDIA) or ROCR_VISIBLE_DEVICES (AMD) to the device UUIDs. Set CUDA_VISIBLE_DEVICES=-1 to force CPU-only mode. The full compatibility table is in the official GPU documentation.

How context length changes Ollama hardware requirements

Context length is the setting that quietly breaks memory planning. The KV cache holds the attention state for every token in the context window, and it grows with both the window size and the model size. A large context can add several gigabytes on top of the model weights.

Recent Ollama versions set the default context length based on available VRAM rather than a fixed value:

Under 24 GB VRAM: 4K tokens
24–48 GB VRAM: 32K tokens
48 GB or more: 256K tokens

You override this with OLLAMA_CONTEXT_LENGTH on the server or num_ctx per request:

OLLAMA_CONTEXT_LENGTH=16384 ollama serve

Two settings reduce the cost. First, enabling flash attention with OLLAMA_FLASH_ATTENTION=1 cuts KV cache memory as context grows. Also, you can cap context per request instead of raising the server default for every model. So if you need long context for agents or coding tools, budget for it in your VRAM math from the start. Running a model across a cluster is a different problem, covered in the deploy an LLM on Kubernetes guide.

How to check if Ollama is using your GPU

Run ollama ps while a model is loaded. The PROCESSOR column tells you exactly where the model is running:

$ ollama ps
NAME               ID              SIZE     PROCESSOR    UNTIL
llama3.1:8b        365c0bd3c000    6.7 GB   100% GPU     4 minutes from now

100% GPU means the whole model is in VRAM. 100% CPU means no GPU acceleration. A split like 35%/65% CPU/GPU means partial offload, and that is your signal to drop to a smaller model or quant.

If you expect GPU use and see CPU, work through three checks. First, confirm the driver meets the minimum version. Then check that nvidia-smi or rocminfo sees the card. Finally, make sure another process is not already holding the VRAM.

Apple Silicon: unified memory changes the math

On an M-series Mac, the CPU and GPU share one pool of memory, so there is no separate VRAM number. A MacBook with 64 GB of unified memory can run models that would need a 48 GB workstation GPU on a PC. This makes high-memory Macs one of the most cost-effective ways to run 70B models locally.

The catch is that macOS reserves part of that memory for the system. By default the GPU can use roughly 65 to 75 percent of total RAM. That is usually fine. But if a large model fails to load on a Mac that seems to have enough memory, the wired memory limit is the likely cause.

Frequently Asked Questions

Q: What are the minimum Ollama hardware requirements?
A: A machine with 8 GB of RAM runs small models (1B–3B) and quantized 7B models on CPU. For a smooth experience with 7B models, use 16 GB of RAM or a GPU with 6–8 GB of VRAM. No GPU is required, but one makes inference 10 to 30 times faster.

Q: How much VRAM do I need for a 70B model in Ollama?
A: About 40 to 43 GB for the 4-bit weights, plus a few GB for context. A single 48 GB GPU or two 24 GB GPUs handles it. On CPU, plan for 64 GB of system RAM and expect slow output.

Q: Can Ollama run on a server with no GPU?
A: Yes. CPU-only inference works for any model that fits in RAM. Expect a few tokens per second for 7B models. Fast, dual-channel DDR5 memory matters more than the number of CPU cores.

Q: Why is my model running on CPU when I have a GPU?
A: Common causes are a driver below the minimum version, too little free VRAM, another process holding VRAM, or an unsupported card. Run ollama ps to confirm, then nvidia-smi to check the card and driver.

Q: Does a bigger context window need more memory?
A: Yes. The KV cache scales with context length and model size and can add several GB. Enable OLLAMA_FLASH_ATTENTION=1 to reduce it, and only raise OLLAMA_CONTEXT_LENGTH as far as your hardware allows.

Quick Summary:

Memory needed ≈ model file size + 1–2 GB overhead + KV cache for your context window.
Official minimums: 8 GB RAM for 7B, 16 GB for 13B, 32 GB for 33B, all at 4-bit quantization.
A 70B model needs about 40–43 GB of VRAM or 64 GB of system RAM.
No GPU is required, but a GPU that fits the whole model is 10–30× faster than CPU; a partial CPU/GPU split is much slower.
NVIDIA needs compute capability 5.0+ and driver 550+; AMD needs ROCm v7 on Linux; Apple Silicon uses unified memory and punches above its price for large models.
Run ollama ps and read the PROCESSOR column to confirm where a model is actually running.

So once you have matched the Ollama hardware requirements to your model, the rest is setup. But if local hardware caps out below the model you need, compare the hosted tier in the Ollama Cloud pricing and limits guide.

Ollama vs LM Studio: Which One Should You Use

Amaresh Pelleti — Fri, 04 Sep 2026 11:33:04 +0000

Ollama vs LM Studio is a choice most people run into within a week of trying local models. Both tools run open-weight language models on your own machine, pull from the same pool of GGUF model files, and expose an OpenAI-compatible API. The real split is how you work: from a terminal and scripts, or from a window with a chat box. This comparison covers the differences in interface, licensing, platform support, and performance. Then it gives a verdict for the two most common situations.

The short version: pick Ollama if you are wiring a model into a server, a container, or your own code. Pick LM Studio if you want to browse, download, and chat with models from a desktop app. They also run side by side without conflict, which is a valid answer too.

Ollama vs LM Studio at a glance

Here is how the two tools line up on the decisions that actually matter.

Factor	Ollama	LM Studio
Primary interface	Command line, plus a basic desktop app	Full desktop GUI with chat
License	Open source (MIT)	Proprietary, free for personal and commercial use
Platforms	macOS, Windows, Linux	macOS (Apple Silicon + Intel), Windows (x64/ARM64), Linux (x64)
Model source	`ollama.com` library, plus GGUF import	Hugging Face browser built into the app
API	Native REST on `:11434`, plus OpenAI-compatible `/v1`	OpenAI- and Anthropic-compatible on `:1234`
Inference engine	llama.cpp-based, plus a newer native engine for some models	llama.cpp and Apple MLX
Headless / server mode	Built in (`ollama serve`, systemd unit)	`lms` CLI and a headless daemon
Document RAG	Not built in	Built into the app
Best for	Servers, automation, embedding in apps	Desktop experimentation, non-CLI users

Both tools use llama.cpp under the hood for GGUF models, so raw token throughput on the same model and quantization is close. The differences are in packaging, not the core math.

What Ollama does best

Ollama is built to run as a service. After install, it starts a background server on port 11434 and stays out of the way. So you pull a model with ollama pull llama3.1, then call it from any language over HTTP. That design makes it the default choice for anything programmatic.

On Linux, the install script sets up a systemd unit so the server survives reboots:

curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl enable --now ollama

You configure it with environment variables through systemctl edit ollama — bind address, model directory, how long a model stays in memory, how many run at once. There is an official Docker image, so dropping Ollama into a container stack is a few lines of Compose. The Ollama on a DigitalOcean droplet walkthrough shows the full server setup.

Ollama is also open source under the MIT license. That matters if you need to vendor it, audit it, or ship it inside a product without checking terms.

What LM Studio does best

LM Studio is the better tool for exploring models. The app has a Hugging Face search built in. You can find a model, read its card, check quantization options with size estimates, and download it without leaving the window. The chat interface shows tokens per second, lets you edit the system prompt live, and keeps conversation history.

It ships two inference engines: llama.cpp on every platform, and Apple MLX on Apple Silicon. For MLX-format models on an M-series Mac, that path is often faster than the llama.cpp build. Ollama does not use MLX.

LM Studio also has built-in document chat. You attach PDFs or text files and the app handles the retrieval step, which Ollama leaves to you. Since July 2025, LM Studio is free for use at work with no form to fill out, though it stays closed source.

For teams that want a GUI, the LM Studio and Ollama setup guide covers installing both on the same machine.

Ollama vs LM Studio: performance and model support

On the same GGUF file and quantization level, expect similar speed from both tools, because both call llama.cpp. The practical performance gaps come from three things:

Apple MLX: LM Studio can run MLX-optimized models on Apple Silicon, which often beats the GGUF path on the same Mac. This is LM Studio's clearest speed advantage.
Model loading defaults: Ollama keeps a model in memory for 5 minutes after the last request by default, then unloads it. A cold request after that pays the load cost again. You change this with OLLAMA_KEEP_ALIVE.
Context length defaults: recent Ollama versions set the default context window based on available VRAM rather than a fixed 4096 tokens. Check ollama ps to confirm a model is on the GPU and not partly on CPU.

Model availability is close to even. Ollama's ollama.com/library is curated and versioned. LM Studio pulls from all of Hugging Face, so obscure or brand-new quants show up there first. Both let you load your own GGUF files.

⚠️ Note: Ollama's model names like llama3.1 default to a 4-bit quantization (Q4_K_M). If you compare it against a Q8 model in LM Studio, you are measuring quantization, not the tools.

Ollama vs LM Studio: which one should you use?

Use Ollama if you are building something. That covers a backend service, a CLI tool, a RAG pipeline, a coding assistant in your editor, or anything running in Docker or on a Linux box. Ollama's always-on server and clean REST API are the right fit. The Ollama Cloud free vs Pro limits guide covers the hosted option when local hardware runs out.

Use LM Studio if you want to work with models directly. Comparing outputs across models, testing prompts, chatting with a local model, or running quick document Q&A all go faster in the GUI. It also helps on a Mac, where the MLX engine speeds up supported models. You never touch a terminal.

For most developers, the honest answer is both. In practice, that means LM Studio on your workstation for testing and model discovery, but Ollama on your server for the actual application. They do not conflict — different ports, different jobs.

Can you run both together?

Yes. Ollama listens on 11434 and LM Studio on 1234, so there is no port clash. A common setup is LM Studio on a laptop for prototyping and Ollama on a home server or VPS for anything that needs to stay up. Both expose an OpenAI-compatible endpoint, so pointing your code from one to the other is a base-URL change.

The one resource they share is your GPU. Running a large model in both at once will exhaust VRAM. Load models in one tool at a time unless you have headroom to spare.

Frequently Asked Questions

Q: Is Ollama or LM Studio faster?
A: On the same model file and quantization, they perform about the same because both use llama.cpp. LM Studio is faster for MLX-format models on Apple Silicon Macs, since it supports Apple's MLX engine and Ollama does not.

Q: Is LM Studio free for commercial use?
A: Yes. Since July 2025, LM Studio is free for both personal and work use with no license form required. It remains closed source, and some enterprise features are paid.

Q: Can I use LM Studio models in Ollama?
A: Both tools run GGUF files. A model downloaded by LM Studio imports into Ollama with a Modelfile that points at the .gguf path. Any GGUF from Hugging Face works in both.

Q: Does Ollama have a GUI?
A: Ollama ships a basic desktop app for chatting with models, added in 2025. It is far simpler than LM Studio's interface and has no model browser or document RAG.

Q: Which one is better for a server?
A: Ollama. It runs as a background service with a systemd unit, has an official Docker image, and is configured through environment variables. LM Studio can run headless with its daemon, but Ollama is built for that job.

Quick Summary:

Ollama is open source, CLI-first, and built to run as a background API server — the pick for servers, containers, and code.
LM Studio is a closed-source but free desktop GUI with a Hugging Face model browser, live chat, and built-in document RAG — the pick for hands-on experimentation.
Both use llama.cpp, so token speed is similar; LM Studio adds Apple MLX for faster inference on Apple Silicon.
Ollama serves on port 11434, LM Studio on 1234 — they run side by side without conflict.
Ollama defaults to 4-bit (Q4_K_M) quantization; match quant levels before comparing output quality.

The Ollama vs LM Studio decision really is that simple: Ollama for anything a program calls, LM Studio for anything you click. If you are deciding where to run models once local hardware is maxed out, read the Ollama Cloud pricing and limits breakdown next.

Docker Desktop Licensing Cost: Pay or Switch?

Amaresh Pelleti — Thu, 03 Sep 2026 11:56:20 +0000

Docker Desktop is free until your company crosses 250 employees or $10 million in annual revenue — then every developer running it owes a paid subscription, and at the Business tier that is $288 per seat per year with no annual discount. For a 200-developer engineering org that is $57,600 a year for a tool most people forget is even installed.

This is the cost math nobody runs before the renewal quote lands — the kind of line item FinOps reviews tend to catch a year too late. Here is the real Docker Desktop licensing cost at different team sizes, what the free alternatives cost once you count migration time, and where the line is that makes switching worth it.

When does Docker Desktop require a paid subscription?

The rule is in Section 3.2 of the Docker Subscription Service Agreement. Docker Desktop use without a paid subscription is restricted to:

Read the operators carefully:

The two thresholds inside clause (ii) are joined by and. You stay free only if you are under 250 employees and under $10M revenue. Cross either one and clause (ii) no longer applies to you.
A 40-person startup that raised a round and is now doing $12M ARR needs to pay. A 300-person company doing $4M does too.
This covers Docker Desktop specifically — the macOS/Windows application and its bundled Linux VM. Docker Engine (dockerd) on a Linux host is Apache 2.0 and always free. So is the docker CLI itself.
Docker Hub pull limits are a separate policy with separate thresholds. This article is only about the Desktop subscription.

Enforcement is contractual, not technical. Docker Desktop will not stop working if you are out of compliance. But it phones home, Docker has sent true-up invoices before, and an unlicensed deployment is exactly the kind of thing that surfaces during acquisition due diligence or a SOC 2 audit.

Docker Desktop licensing cost: the 2026 price tiers

Docker raised prices on December 10, 2024 — Pro went up about 80%, Team about 67%. Current per-seat pricing:

Plan	Monthly	Annual (per month)	Annual (per year)	Seat cap
Personal	$0	$0	$0	1
Pro	$11	$9	$108	1
Team	$16	$15	$180	100
Business	$24	$24	$288	unlimited

Two things to note. Team caps at 100 seats. Any org that needs more than 100 licenses is on Business, whether it wants the SSO and hardened-image features or not. And Business has no annual discount — $24/month is the only price, $288/year.

Prices verified against docker.com/pricing in September 2026. Docker's last change was December 2024; check the current figures before you budget.

The real Docker Desktop licensing cost by team size

"Seats" here means people who actually launch Docker Desktop, not total headcount. In most orgs that is the backend, platform, and QA engineers plus some data folks — call it 30-60% of an R&D team.

Docker Desktop seats	Docker Team (annual)	Docker Business	OrbStack Pro	Podman / Rancher / Colima
10	$1,800	$2,880	$960	$0
50	$9,000	$14,400	$4,800	$0
100	$18,000	$28,800	$9,600	$0
200	— (over cap)	$57,600	$19,200	$0
500	—	$144,000	$48,000	$0

OrbStack Pro is $8/user/month or $96/year for commercial use, but it is macOS only — a mixed Mac/Windows/Linux fleet cannot standardize on it. Podman Desktop, Rancher Desktop, and Colima are open source with no company-size clause: $0 at any scale, on any OS.

What the free alternatives actually cost

The sticker price of Podman Desktop is zero. The switch is not.

Migration engineering time. Budget per developer:

1-2 hours if your workflow is docker build / docker run / docker compose up on standard images. Podman and nerdctl are near drop-in; alias docker=podman covers most of it.
4-8 hours if you have Compose files using build secrets, custom networks, depends_on health conditions, or host networking; if devs script against the Docker socket; or if you rely on Docker Desktop's file-sharing performance tuning on macOS.
Days, not hours if you have Testcontainers-based test suites, dev containers wired to the Docker API, or bespoke Docker Desktop extensions.

Platform team time. Updating onboarding docs, the README, CI base images, and the internal setup script — figure 1-2 weeks of one engineer for a mid-size org, more if you support multiple OSes.

A worked example — 50 seats:

Switching cost: 50 devs x 4 hours x $75/hr loaded ≈ $15,000, plus ~60 hours of platform time ≈ $4,500. Call it ~$20,000 one-time.
Docker Business for 50 seats: $14,400/year.
Payback: ~1.4 years. After that it is $14,400/year saved, every year.

The bigger the team, the faster it pays back. The switching cost scales with team size, but so does the license you are avoiding. Past 100 seats you are forced onto Business anyway. At 200 seats the switch pays back in well under a year.

For a 10-person team, the math flips: ~$5,000 to switch versus $1,800-$2,880/year. Only worth it if you were going to grow past 50 soon, or if you want off the licensing-risk treadmill entirely.

The honest trade-offs

Switching is not free of downside:

Podman on macOS/Windows runs a Linux VM, just like Docker Desktop did. Its file-sync performance for large bind mounts has historically been a notch behind. Test your actual repo before committing.
Docker Desktop's GUI for inspecting containers, images, and volumes is genuinely good. Podman Desktop has closed most of the gap; Rancher Desktop's is more basic.
Testcontainers officially supports Podman now, but expect to set DOCKER_HOST and TESTCONTAINERS_RYUK_DISABLED and debug a few CI runs.
Docker Business features you would lose — Hardened Docker Desktop, registry access management, SSO enforcement on the desktop app. If you bought Business for the compliance controls rather than just the right to run it, an alternative does not replace that.
OrbStack is the least-effort paid switch: it is Docker-socket-compatible, noticeably faster and lighter than Docker Desktop, and $96/seat/year undercuts Business by two thirds. But macOS only.

For a deeper feature-by-feature look at the leading alternative, see our Docker vs Podman comparison.

The verdict

Under 250 employees and under $10M revenue: Docker Desktop is free. Do nothing. Revisit if you raise a large round or an acquisition is on the table.
Over a threshold, fewer than ~30 seats: pay for Docker Team ($180/seat/year). Not worth the disruption yet.
Over a threshold, 30-100 seats: run the payback math. A switch to Podman or Rancher Desktop typically pays back in 1-2 years and removes the licensing-risk line item permanently. All-Mac shops should price OrbStack Pro first — it is the cheapest low-effort option.
Over 100 seats: you are on Docker Business at $288/seat/year with no discount. The switch is close to a no-brainer here. At 200 seats you are choosing between $57,600 a year forever and a one-time project that costs less than a single year of it.

Whatever you decide, decide it deliberately. The worst outcome on Docker Desktop licensing cost is the one you never chose. That is finding out during an audit that 180 engineers have run Docker Desktop unlicensed for two years, then paying the back bill at list price. If cost control across the stack is the real goal, the same logic applies to Kubernetes spend and every other per-seat developer tool.

Docker Compose Recreates Containers After 5.5 Upgrade

Amaresh Pelleti — Wed, 02 Sep 2026 11:51:56 +0000

Docker Compose recreates containers you didn't touch the first time you run docker compose up after upgrading to 5.5. That's expected, not a bug. Compose 5.5 overhauls image digest reconciliation — the logic that decides whether an existing container matches what your docker-compose.yml currently describes. The release notes say it plainly: "existing containers may be recreated the first time you run compose up after upgrading, as image digests are re-evaluated using the new logic."

It's a one-time event, not a recurring problem. But if you weren't expecting it, a mass container restart looks like an incident. Here's what actually changed, why it happened once and won't again, and what else shipped in the same release.

Why Docker Compose Recreates Containers on the First Upgrade Run

Compose decides whether to recreate a container by comparing a hash of its current configuration against what's already running, and image digests are part of that hash. Version 5.5 changes how those digests get evaluated — more accurately, according to the release notes, which is the whole point of the change. But "more accurate" means containers created under the old evaluation logic look different from what the new logic expects, even if nothing in your compose file actually changed.

So on your first compose up after upgrading, Compose reconciles every service against the new digest logic. Anything that reads as "different" gets recreated once. After that first pass, your containers are baselined against the new logic and stay put on subsequent runs, the same way Compose has always behaved for unchanged services.

The Recurring Complaint Behind the Overhaul

This overhaul didn't come out of nowhere. Complaints about containers getting recreated on compose up when nothing changed have followed the v2 rewrite from the start. A 2023 GitHub issue documents the pattern exactly: a user changed one service's image tag, ran compose up -d again with zero further changes, and watched Compose recreate every dependent container anyway — "I did NOT make any changes here, I simply ran compose up again, and again it recreated the containers!"

That specific bug was a v2.16 regression, and Docker fixed it within weeks in v2.17.0. It also involved config-hash comparison generally, not digest reconciliation specifically. But it's the same category of problem, and it kept resurfacing in new forms: Compose's decision about whether a container needs recreating didn't match what a human expected, and each occurrence got a one-off fix. The 5.5 overhaul reads like Docker rebuilding that logic instead of patching around it again.

What Else Shipped in Docker Compose 5.5

The digest change is the headline, but a few other fixes matter if you run Compose in CI or with build-heavy setups.

compose pull now honors pull_policy refresh windows — daily, weekly, and every_N settings actually control when Compose re-pulls an image, instead of pulling on every invocation regardless of policy.
Build-only services skip pulling a default image reference they were never going to use, which was previously wasted network time on every up.
Compose stopped pruning every dangling image in a project on cleanup, a behavior that was too aggressive for anyone sharing base images across services.
The file watcher now skips unreadable directories instead of failing the entire watch session, and Compose tolerates containers whose image record has gone missing instead of erroring out.

None of these force a workflow change on their own. They're the kind of fixes you only notice once they stop happening. If you're still deciding between Compose-managed Docker and a daemonless alternative, the Docker vs Podman comparison is worth reading before you standardize either way.

[IMAGE: articles/images/2026-08-25-docker-compose-recreates-containers-diagram.png | alt: "image digest reconciliation flow in Compose 5.5, from compose up to a stable container state"]

What to Check Before You Upgrade

Expect one restart cycle, not zero. If your services hold in-memory state or long-lived connections, plan the first post-upgrade compose up like a deploy, not a routine command.
Check pull_policy settings if you rely on scheduled pulls. The refresh-window fix means daily/weekly/every_N now actually gate pulls — if you were working around the old always-pull behavior with a wrapper script, that workaround may now be redundant or conflicting.
Run docker compose config --hash "*" before and after upgrading to see exactly which services Compose considers changed, so the recreation isn't a surprise mid-deploy.
Don't run the upgrade for the first time against production. Because the recreation is real, not cosmetic, test it against staging first if your containers have any startup cost or connection-draining behavior worth protecting.

⚠️ Important: if any service uses restart: always alongside a health check with a short grace period, a mass recreation event can trigger cascading restart attempts before dependent services are back up. Stagger the upgrade across environments rather than rolling every host to 5.5 at once. The Docker errors and fixes guide covers what a cascading restart loop looks like if you want to recognize it fast.

Verdict: Should You Upgrade?

Yes, for most setups. The one-time recreation is a known, explained side effect, not a regression, and the underlying fix addresses a category of complaint that's followed Compose v2 for years. Teams running build-only services or relying on pull_policy refresh windows get a direct, measurable improvement, not just a bug fix.

The exception is anything with strict uptime requirements and no rolling-deploy story for Compose-managed services — for those, schedule the upgrade like you would a dependency bump that touches container lifecycle, with a maintenance window and a rollback plan, rather than pulling 5.5 straight into a production host. If you're layering Compose on top of a base you're still learning, the Docker beginner's guide and the Docker best practices guide are worth a read before you change upgrade habits on production systems.

Frequently Asked Questions

Q: Will Docker Compose keep recreating my containers every time I run compose up?
A: No. The recreation happens once, on your first compose up after upgrading to 5.5, while Compose re-evaluates image digests under the new logic. After that first pass, unchanged services stay running exactly as before.

Q: Do I need to change my docker-compose.yml to avoid the recreation?
A: No changes are required. The recreation is triggered by the new digest evaluation logic itself, not by anything in your compose file. There's no configuration flag to skip it.

Q: Does the pull_policy refresh window change affect existing daily/weekly settings?
A: It makes them work as documented. Before 5.5, compose pull didn't reliably respect those refresh windows; now it does, so a pull that was firing more often than intended should slow down to match your configured policy.

Q: Is this related to the old "Compose v2 recreates containers for no reason" complaints?
A: It's the same category of problem — Compose deciding a container needs recreating when a human wouldn't expect it — but a different specific mechanism. This overhaul targets digest evaluation, not general config-hash comparison.

Quick Summary

Docker Compose 5.5 overhauls image digest reconciliation, and existing containers get recreated once on the first compose up after upgrading
After that first pass, Compose behaves normally — unchanged services stay running on subsequent runs
compose pull now actually honors pull_policy refresh windows (daily, weekly, every_N), which previously didn't reliably apply
Build-only services no longer pull an unused default image reference, and Compose no longer prunes every dangling image in a project on cleanup
Test the upgrade in staging first if any service has real startup cost, in-memory state, or strict health-check timing

Run docker compose config --hash "*" before you upgrade so you know in advance which services Compose considers changed. Docker Compose recreates containers exactly once during this transition, and treating that first post-upgrade compose up like a deploy rather than a routine command is the difference between a known side effect and an incident.

CKA vs CKAD vs CKS: Which Cert to Take First

Amaresh Pelleti — Tue, 01 Sep 2026 18:04:27 +0000

Three Kubernetes certifications exist, and each one tests a different job. The CKA is for people who run clusters. The CKAD is for people who deploy apps onto them. Securing those clusters is what the CKS covers. When you are choosing, CKA vs CKAD vs CKS comes down to your actual role, not which exam sounds hardest.

This guide covers what each exam tests, the format, the cost, the big 2025 CKA changes, and how long prep really takes.

[IMAGE: articles/images/2026-08-28-cka-vs-ckad-vs-cks-featured.png | alt: "CKA vs CKAD vs CKS Kubernetes certification comparison"]

CKA vs CKAD vs CKS: what's the difference?

Cluster operations are the CKA's focus: installation, upgrades, networking, storage, and fixing broken nodes. The CKAD is about application delivery, so it covers pod design, config, health probes, and multi-container patterns. Security hardening drives the CKS, which means RBAC, network policies, supply-chain checks, and runtime detection. All three are hands-on, run from a terminal, and use the same Kubernetes version. The CKS also requires a passed CKA first.

Here is the split by curriculum weight, taken from the current CNCF certification pages.

Exam	Who it's for	Heaviest domains	Prerequisite
CKA	Cluster admins, SREs, platform engineers	Troubleshooting 30%, Cluster architecture 25%, Services & networking 20%	None
CKAD	Backend and app developers shipping to Kubernetes	App environment, config & security 25%, Design & build 20%, Deployment 20%	None
CKS	Security engineers, platform teams with a security remit	Microservice vulnerabilities 20%, Supply chain 20%, Monitoring & runtime 20%	Passed CKA

The CKA and CKAD overlap on services and networking. Past that, they pull apart. A developer rarely drains a node, and an admin rarely writes a readiness probe from scratch.

CKA vs CKAD vs CKS: which one should you take first?

Take the CKA first if you run infrastructure, and take the CKAD first if you write application code. Most people should start with the CKA. It is the broadest of the three, it has no prerequisite, and it is the one hiring managers recognize. The CKS is not a starting point, because you must pass the CKA before you can attempt it.

Platform or DevOps engineer: take the CKA. It maps to what you already do, and it unlocks the CKS later.

Backend developer: take the CKAD. Your time goes into manifests and rollouts, not etcd backups.

Security is your job title: CKA, then CKS right after. Budget for both from the start.

Verdict: the CKA is the default answer for anyone unsure. It carries the most weight on a resume and opens the most doors, the CKS included. Our guide to DevOps certifications shows how these sit next to the AWS and Azure tracks.

CKA vs CKAD vs CKS exam format, scoring, and rules

Every exam is a two-hour, online-proctored, performance-based test taken from a command line. There is no multiple choice. You solve real tasks on a live cluster: create resources, fix broken configs, and verify your work. The Linux Foundation delivers all three through PSI's "Bridge" proctoring platform with the PSI Secure Browser, so you need a quiet room, a clear desk, and a webcam ID check.

Passing scores are fixed:

CKA: 66%
CKAD: 66%
CKS: 67%

The Linux Foundation does not publish an official task count for any of the three exams. The Killer.sh simulator bundled with each exam runs 17 questions, and test-takers generally report a similar number on the real exam. Time management matters more than raw knowledge here, because each task is weighted and partial credit is common.

Every exam is open-book, but only for a fixed list of sites. During the CKA and CKAD you may open kubernetes.io/docs, kubernetes.io/blog, and helm.sh/docs, and the CKA also allows gateway-api.sigs.k8s.io. The CKS adds falco.org/docs, etcd.io/docs, docs.cilium.io, istio.io/latest/docs/, the NGINX Ingress controller docs, and the Kubernetes SIGs bom docs. You can use the search on kubernetes.io/docs, but you cannot open an external search result. The full list lives on the allowed-resources page. Practice navigating the docs fast, because tab-hunting mid-exam burns minutes you do not have.

⚠️ Note: certifications earned on or after April 1, 2024 are valid for 2 years (older ones keep their 3-year term). Renew by retaking and passing the current exam before yours expires.

What the CKA, CKAD, and CKS certifications cost

Each exam costs $445 on its own. The Linux Foundation also sells two bundles: exam plus a THRIVE-ONE annual subscription for $625, or exam plus the matching instructor course (LFS258 for CKA, LFD259 for CKAD, LFS260 for CKS) for $645. Every purchase includes one free retake and a 12-month window to schedule and sit the exam.

Purchase	Price (USD)	Includes
Exam only	$445	Two attempts (one retake), two Killer.sh simulator sessions
Exam + THRIVE-ONE	$625	The above, plus a year of Linux Foundation training access
Exam + course	$645	The above, plus the official prep course

Wait for a sale. The Linux Foundation runs discount codes on certification bundles regularly, especially around Black Friday, CyberMonday, and KubeCon. Check for an active coupon before you buy — paying full price when one exists is the most common money mistake with these exams. Your enrollment does not expire for a year, so buy on sale and schedule later.

What changed in the CKA exam in 2025

The CKA changed on February 18, 2025. The five domains and their weights stayed the same. The competencies inside them were reworked. The official program-changes page confirms what got added: Gateway API (GatewayClass, Gateway, HTTPRoute), Helm and Kustomize for installing cluster components, and CRDs and operators. Troubleshooting is the single heaviest domain at 30%.

For prep, that means three things. First, you have to know Helm basics and Kustomize overlays, not just raw manifests. Second, Gateway API is now testable alongside Ingress, so learn both. Third, the troubleshooting weight rewards speed at reading logs, describing resources, and checking kubectl get events before you change anything. CNCF versions the curriculum per Kubernetes release (currently v1.35), so download the current curriculum PDF from the CNCF curriculum repo before you book.

If you studied from a pre-2025 course, your material has no Gateway API, Helm, Kustomize, or CRD coverage at all.

[IMAGE: articles/images/2026-08-28-cka-vs-ckad-vs-cks-diagram.png | alt: "Study path from fundamentals through the Killer.sh simulator to booking the Kubernetes exam"]

How long CKA, CKAD, and CKS preparation takes

There is no official prep-time guidance. Real numbers swing widely with how much Kubernetes you already run day to day. Community reports cluster around 40 to 60 hours for the CKA from a working knowledge of Kubernetes, and 20 to 30 hours for the CKAD once you hold the CKA. One engineer who passed the CKAD in January 2026 logged about 20 hours, having taken the CKA the same month. A candidate preparing for the CKA around a full-time job reported 38 to 44 hours over roughly six weeks. Treat these as rough anchors, not targets.

The CKS usually needs less raw prep time — community estimates land around 25 to 35 hours — but only because it assumes everything the CKA already taught you. Do not book it until CKA reflexes are automatic.

Two things decide pass or fail beyond knowledge:

kubectl speed. Use imperative commands such as kubectl run --dry-run=client -o yaml, and set up aliases and shell autocompletion in the first two minutes of the exam.
Remote-desktop fluency. The exam console has its own copy-paste behavior. Practice it in Killer.sh until it is muscle memory, because fighting the clipboard mid-task has failed people who knew the material cold.

A study path for your first Kubernetes exam

This path works for the CKA or the CKAD. Swap the course for CKS once your CKA is done.

Learn the fundamentals first. If pods, deployments, and services still feel fuzzy, start with our Kubernetes guide and the kubectl commands reference before any exam prep.
Take one structured course. KodeKloud and the official Linux Foundation courses both track the current curriculum. Pick one, then finish it.
Do every lab twice. Hands-on repetition beats re-watching videos. Rebuild each scenario from an empty cluster.
Practice RBAC and network policies by hand. Both show up across all three exams and trip people who only read about them.
Sit both Killer.sh sessions. The simulator is harder than the real exam by design. Score above the pass line on the second attempt before you book.
Book the real exam within a week of your second simulator. Skills fade fast once you stop drilling.

For the CKS specifically, add hands-on time with Falco for runtime security, Trivy image scanning, and pod security standards.

Frequently Asked Questions

Q: Is CKA or CKAD harder?
A: Most people find the CKA harder. It covers more ground, its troubleshooting section is unpredictable, and it now includes Helm, Kustomize, and Gateway API. The CKAD is narrower and more forgiving on time. Someone who already holds the CKA can usually pass the CKAD with about 20 hours of focused prep.

Q: Do I need the CKA before the CKS?
A: Yes. The official rule is that you must have taken and passed the CKA before attempting the CKS. There is no such prerequisite for the CKA or the CKAD, which you can take in any order.

Q: How long are the certifications valid?
A: Certifications earned on or after April 1, 2024 are valid for two years. Older certifications keep their original three-year term. You renew by passing the current version of the exam before your certification expires.

Q: Can I use the Kubernetes documentation during the exam?
A: Yes, but only specific sites. The CKA and CKAD allow kubernetes.io/docs, kubernetes.io/blog, and helm.sh/docs. The CKS allows several more, including the Falco, Cilium, and etcd docs. You can search within those domains, but you cannot open an external search result.

Q: Which certification helps most with getting hired?
A: The CKA. It is the most widely recognized of the three and it maps to the largest number of job descriptions. The CKAD matters for developer roles specifically, and the CKS is a specialist add-on that means little without the CKA behind it.

Quick Summary:

The CKA is for cluster operators, the CKAD for app developers, and the CKS for security engineers; start with the CKA unless you only write application code.
All three are two-hour, performance-based, command-line exams on the same Kubernetes version, delivered through PSI Bridge.
Passing scores are 66% for the CKA and CKAD and 67% for the CKS; each exam is $445 with one free retake, and bundles run $625 to $645.
The CKA competencies were revised on February 18, 2025 to add Gateway API, Helm, Kustomize, and CRDs; troubleshooting is the heaviest domain at 30%.
Budget 40 to 60 hours for the CKA and 20 to 30 for the CKAD after it, and buy during a Linux Foundation sale rather than at full price.

Still deciding between CKA vs CKAD vs CKS? Default to the CKA, set up kubectl autocompletion and imperative-command aliases today, and use them for every task this week so they are automatic on exam day.

Database Provisioning Is Now an AI Agent's Job

Amaresh Pelleti — Tue, 01 Sep 2026 10:58:46 +0000

When Neon's serverless Postgres platform hit general availability in 2024, roughly 30% of new databases on it were created by AI agents instead of humans. By the time Databricks acquired Neon in May 2025 — reportedly for about $1 billion — that number had passed 80%, and Databricks' January 2026 State of AI Agents report says it's still above that line. Database provisioning used to mean a ticket, a Terraform apply, and a wait. Now it's something an agent does mid-task, without asking anyone.

This isn't a vector-search story. It's a plumbing story. The part of the stack that decides how fast a database can appear, fork, and disappear again is being rebuilt around agents instead of people. That changes a few things about how you should design access to your own databases.

From 30% to 80%: Database Provisioning Is Now Automated

Databricks cited this shift as a direct reason for acquiring Neon. OLTP databases are a market built on tools designed decades before anything called an "agent" wrote a line of SQL. Per Databricks' 2026 State of AI Agents report, which draws on telemetry from over 20,000 organizations, 97% of database branches on the platform now get created through natural-language agent requests instead of a human running a CLI command. Multi-agent workflow usage on Databricks grew 327% between June and October 2025 alone.

That growth is why provisioning speed suddenly matters. A developer opening a ticket can tolerate a 10-minute wait for a new database. An agent mid-task cannot. It's spinning up an isolated environment to test a schema change, and it either gets a database in under a second or the whole workflow stalls.

Why Database Provisioning Had to Get Faster for Agents

Neon's pitch has always been instant, isolated Postgres instances instead of a shared staging database everyone fights over. Databricks CEO Ali Ghodsi put the agent version of that problem bluntly to TechCrunch: "Because these agents are super fast. They just spin up lots of databases, much faster than humans can, but you don't want to go bankrupt doing that." Copy-on-write branching lets them try a change against real production data and throw it away if it's wrong, without touching the primary environment.

That's a different requirement than the one traditional provisioning tools were built for. Terraform, CloudFormation, and RDS snapshots all assume a human is planning ahead. An agent making a database decision inside a single tool call needs infrastructure fast enough that provisioning stops being a step it has to plan around at all.

How Lakebase Handles Database Provisioning in Under 500ms

Databricks rebuilt Neon's internals under the name Lakebase. The architecture is why the speed claim holds up. It decouples compute from storage and moves storage onto object storage. Then it adds two components to make that fast enough for a database.

Safekeepers, built on the Paxos consensus algorithm, handle low-latency writes. Page servers compensate for object storage's latency by serving reads quickly, without losing transactional consistency.

The result, per Databricks' Data + AI Summit 2026 keynote: branch creation lands under 500 milliseconds, new-instance creation under a second. The platform handles 12 million database launches a day in production. A newer addition, Lakebase Search, adds hybrid vector and full-text retrieval with 32x index compression, and can index over a billion vectors — it now ships as lakebase_vector and lakebase_text extensions you install with a plain CREATE EXTENSION. That folds search into the same provisioning layer instead of bolting it on as a separate service.

[IMAGE: articles/images/2026-08-25-database-provisioning-ai-agents-diagram.png | alt: "database provisioning pipeline showing an AI agent request flowing through safekeepers and page servers to a new branch"]

Tiger Data's Agentic Postgres Takes a Different Approach

Neon isn't the only vendor rebuilding around this. Tiger Data — the company behind TimescaleDB — shipped Agentic Postgres on a storage layer it calls Fluid Storage. It's built for zero-copy forks of production data in seconds. An agent can spin up a full copy of production, benchmark a new index against it, and discard the fork without ever touching the live database.

Search is where Tiger Data diverges from Neon. Instead of leaning on pgvector alone, Agentic Postgres pairs pgvectorscale for higher-throughput vector indexing with a new pg_textsearch extension. That extension implements BM25 ranked keyword search, aimed squarely at hybrid retrieval for agent workflows. It also ships an MCP server, so an agent can provision and configure a database from a plain-language prompt instead of a schema migration script. Tiger Data has since opened a free tier for it, which makes it cheap to test the fork-per-agent pattern before committing.

Two well-funded companies independently reached the same conclusion. The bottleneck for agent-driven work isn't query speed. It's how fast you can hand an agent its own disposable copy of the database. That's a specific, testable claim, not a marketing line.

Where Database Provisioning Breaks: pgvector and Branching Limits

None of this is friction-free. pgvector runs entirely on CPU — there's no GPU offload. And the memory math gets unforgiving at scale: 50 million vectors at 768 dimensions is roughly 150GB of raw vector data alone, before the HNSW index built on top of it, which in practice can more than double the total footprint. Where the ceiling sits depends on your hardware and recall target, but if your agents run concurrent vector search over embedding sets in the tens of millions, memory and CPU — not provisioning speed — become the constraint.

Branching has a narrower limit too. Neon's branch-and-fork model was designed for development and CI workflows — a handful of long-lived branches per project. Fleet-scale agent workloads want the opposite pattern. They need hundreds of lightweight, ephemeral branches created and torn down per minute, each isolated to a single agent run. That's closer to per-request sandboxing than to a Git-style branch. It's not what Neon's original design, or most managed Postgres services, were built to sustain at volume.

⚠️ Important: if you're letting agents provision their own databases or branches, put a hard quota on branch count and lifetime per agent first. An agent stuck in a retry loop can create branches far faster than a human ever would. And "scale to zero" only helps your bill if something eventually tears the branch down.

What This Means for Your Database Access Patterns

There's a broader trend backing all of this. Native vector support is moving back into general-purpose relational databases instead of staying in dedicated vector stores. SQL Server 2025 ships a native VECTOR data type built into the core engine. It supports up to 1,998 dimensions, stores data in optimized binary, and pairs with DiskANN-based approximate nearest-neighbor indexes. Oracle's AI Database 26ai ships AI Vector Search as a built-in feature, not a bolt-on. RDS and Cloud SQL already lean on pgvector for the same job. Database provisioning and the vector search agents need are converging into the same box.

That has practical consequences. Stop treating "provision a database" as a privileged, human-gated action if agents are already doing it in your stack. Design the access boundary around the agent's identity and scope, not around a shared service account. Budget for cleanup, too — an agent that can create a branch in 500ms can also forget to delete ten of them. And if you're choosing where embeddings live, native vector support in Postgres now has real production backing at scale. That changes the calculus against standing up a separate vector database by default.

None of this requires a migration if you're already running PostgreSQL 18. Lakebase and Agentic Postgres are both Postgres underneath, so the SQL you write doesn't change. What changes is who issues the CREATE DATABASE call, and how fast they expect it back. The Model Context Protocol guide covers the layer actually issuing these provisioning requests. And if you're weighing where a given workload belongs at all, the breakdown of different database types is still the right starting point before assuming agent-driven Postgres fits everything.

Frequently Asked Questions

Q: Do I need to switch to Neon or Tiger Data to let AI agents provision databases?
A: No. Both are specific implementations of a broader shift toward fast branching and forking on top of Postgres. If your managed Postgres already supports quick snapshots or read replicas, you can build a scoped-down version of the same pattern. You just won't get sub-second provisioning without a storage layer built for it.

Q: Is pgvector no longer good enough for AI workloads?
A: It's fine for moderate scale. The CPU bottleneck shows up specifically at large vector counts with high concurrent query volume — most teams won't hit it. Test with your actual embedding count and query rate before assuming you need a different engine.

Q: What's the real risk of letting agents provision their own databases?
A: Runaway resource creation, not data loss. An agent in a retry loop can create branches or instances far faster than a human, so the fix is a hard quota on branch count and lifetime per agent identity, not a ban on the capability.

Q: Does this trend replace dedicated vector databases entirely?
A: Not entirely, but it removes the default reason to reach for one. When Postgres, SQL Server, and Oracle all ship native vector search, a standalone vector database has to justify itself on something beyond "it does vector search" — usually scale or a specific indexing algorithm you can't get natively yet.

Quick Summary

Over 80% of databases provisioned on Neon are created by AI agents, up from roughly 30% at its 2024 GA, per Databricks
Databricks' Lakebase architecture provisions new Postgres branches in under 500ms (new instances in under a second) using Paxos-based safekeepers and separate page servers, handling 12 million launches a day
Tiger Data's Agentic Postgres takes a different route to the same problem: zero-copy forks on "Fluid Storage" plus pgvectorscale and a new BM25-based pg_textsearch extension
pgvector is CPU-bound, and memory becomes the real ceiling in the tens of millions of vectors; Neon's original branching model wasn't built for hundreds of ephemeral agent branches per minute
SQL Server 2025, Oracle AI Database 26ai, and RDS/Cloud SQL all now ship native vector search, pulling that workload back into general-purpose relational databases

If agents already touch your database layer, put a branch quota and a teardown policy in place before you give them database provisioning access — the infrastructure is fast enough now that the bottleneck is entirely on your side.

GitHub Actions and Git: A Complete Workflow Guide

Amaresh Pelleti — Fri, 28 Aug 2026 17:50:20 +0000

Git and GitHub Actions are two tools most teams adopt without ever deciding how they fit together. You pick a branching habit, wire up a workflow file, and six months later nobody remembers why deploys are slow or why one pull request skipped its tests. So this guide covers the decisions that actually matter — branching model, rebase timing, workflow structure, secret handling, and the failure modes that show up once real traffic hits your pipelines. Each section leads with the short answer, then the detail behind it.

What does a Git and GitHub Actions workflow actually look like?

A working setup has three layers. Git tracks your code history on short-lived branches. GitHub hosts the shared repository and enforces review rules. GitHub Actions runs automated jobs — tests, builds, deploys — triggered by events like a push or a pull request. The branch you push decides which workflows run. The review rules decide whether that branch can merge. Align those three layers and most CI pain disappears.

Here is the chain every run follows. An event fires: a push, a pull_request, a schedule, or a manual workflow_dispatch. GitHub matches that event against the on: block of every workflow file in .github/workflows/. Each matching workflow starts its jobs. By default, jobs run in parallel on separate runners, and needs: forces an order. Each job runs its steps in sequence on one machine. A step is either a shell command (run:) or a packaged action (uses:).

[IMAGE: articles/images/2026-08-28-git-github-actions-guide-diagram.png | alt: "Flow from a git event to workflow match to parallel jobs on runners to sequential steps"]

New to the split between the version control tool and the hosting platform? The difference between Git and GitHub for beginners is worth ten minutes first. Everything below assumes you know which is which.

Verdict: if you cannot draw this chain from memory, every debugging session starts from zero. Learn it once and the error messages start making sense.

Which Git branching model should you use?

For most teams, use GitHub Flow: one long-lived main branch, short-lived feature branches, and a merge through a pull request once checks pass. Trunk-based development goes further, with everyone committing to main several times a day behind feature flags, and it suits teams that ship continuously. Git Flow, with its develop and release branches, only earns its complexity if you ship versioned software to customers who run several versions at once.

Model	Branch structure	Best for	Main cost
GitHub Flow	`main` + short feature branches	Most web teams, continuous deployment	Needs solid PR checks
Trunk-based	`main` only, feature flags	Fast-moving teams, many deploys a day	Requires a fast, trusted test suite
Git Flow	`main`, `develop`, `release/`, `hotfix/`	Versioned/on-prem software, parallel releases	Heavy branch bookkeeping

GitHub Flow works because there is only one integration point. A branch is either merged or it is not. The risk is that a weak test suite lets broken code into main, so the model leans on branch protection to hold the line.

Trunk-based development removes even the feature branch. Work goes straight to main behind a flag that is off in production until the feature is ready. In practice, this keeps merge conflicts tiny because nothing diverges for long. But the price is discipline. Your pipeline has to catch regressions on every commit, because there is no staging branch to catch them later.

Git Flow is the odd one out in 2026. It was designed for scheduled, versioned releases, and it still fits that case. But for a team deploying a web app several times a week, the develop-to-release-to-main promotion path is bureaucracy with no payoff. For example commands per model, see the full breakdown of Git Flow, GitHub Flow, and trunk-based development. Pair it with a review of your branching and merging strategies. The branching and approval best practices guide covers how to enforce whichever one you pick.

Verdict: default to GitHub Flow. Move to trunk-based only when your test suite is fast and trustworthy enough to gate main directly. Reach for Git Flow only if you genuinely support multiple released versions.

When should you rebase instead of merge?

Rebase to clean up your own local commits before you share them. Merge to combine branches that other people have already pulled. The Pro Git book states the rule plainly: "Do not rebase commits that exist outside your repository and that people may have based work on." Break it and teammates get duplicate commits, a broken history, and merge conflicts that should not exist.

Rebase and merge do different things. A merge performs a three-way merge between the two branch tips and their common ancestor, then records a new merge commit. A rebase takes the diffs your branch introduced, resets your branch to the target, and replays each diff on top. As the book puts it: "Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together."

The everyday use is keeping a feature branch current:

git checkout feature/login
git rebase main

That replays your login work on top of the latest main, so the eventual pull request is a clean diff with no merge commits in the middle. You can make git pull do this automatically:

git config --global pull.rebase true

⚠️ Note: rebasing a branch you have already pushed and that a teammate has pulled means force-pushing over shared history. Their next git pull brings back your old commits alongside your rewritten ones, and now the branch has both. The recovery is git pull --rebase, which uses patch-id checksums to spot and drop the duplicates, but it is friction nobody wanted.

The safe boundary is simple. Rebase commits that have never left your machine, or that are pushed but that nobody has based work on. For the mechanics of interactive rebase, stash, and cherry-pick, see advanced Git rebase, stash, and cherry-pick. To tidy a messy branch into one commit before review, squash the feature branch instead of rebasing interactively. When a rebase or merge does collide, resolving merge conflicts in Git walks through the markers and the fix.

Verdict: rebase before the first push, merge after. The pull-request merge button is a merge, and that is correct — leave it alone.

What are Git hooks actually good for?

Git hooks run your own scripts automatically at points in the Git lifecycle: before a commit, before a push, after a merge. The useful ones are pre-commit for linting and formatting, commit-msg for enforcing a message format, and pre-push for a fast smoke test. One catch decides how you use them. Hooks live in .git/hooks and are never copied on clone, so a hook on your machine does nothing for anyone else.

When you run git init, Git fills .git/hooks with example scripts that end in .sample. Drop the suffix and make the file executable to activate one. Any language works. If the script exits non-zero, Git aborts the operation — a failing pre-commit stops the commit, a failing pre-push stops the push. Anyone can skip a client-side hook with git commit --no-verify, so a hook is a convenience, not a gate.

Because hooks are not version-controlled, teams share them one of two ways. First, you can commit hook scripts to a tracked folder and point Git at it with git config core.hooksPath .githooks. Or you can use a manager like pre-commit or Husky that wires itself in during a setup step. Either way, keep hook work fast. A pre-commit that runs the full test suite trains people to use --no-verify every time.

Server-side hooks (pre-receive, update, post-receive) run on the remote and cannot be bypassed, but on GitHub you do not manage those directly — branch protection and Actions cover the same ground. For working examples of each client-side hook, see Git hooks with real scripts, and check the official Git hooks reference for the full list and their arguments.

Verdict: use hooks for fast local checks only, and manage them with a tool so the whole team gets them. Real enforcement belongs in GitHub Actions and branch protection, not a hook that --no-verify skips.

How are GitHub Actions workflows structured?

A workflow is a YAML file in .github/workflows/. It needs three pieces: on: for what triggers it, jobs: for the units of work, and inside each job, runs-on: for the runner and steps: for the commands. Jobs run in parallel by default. Add needs: to make one job wait for another. Everything else — env:, permissions:, concurrency:, strategy.matrix: — is optional tuning.

name: CI
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

The triggers you will actually use are push, pull_request, schedule (POSIX cron, minimum five-minute intervals), workflow_dispatch for a manual run, and workflow_call to be invoked by another workflow. Branch and path filters narrow it further, so a docs-only change need not run the full build.

Two tuning keys matter early. concurrency groups runs so a new push cancels the in-progress one for the same branch:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

timeout-minutes caps a job. Without it, the platform still kills the job at six hours, but by then you have burned a runner for nothing. Environment variables follow a precedence order: a step-level env beats a job-level one, which beats the workflow level.

For the full syntax with every key explained, see the workflow YAML guide. If you have never built one, your first CI/CD pipeline starts from an empty repo, and an introduction to automating your workflow covers the concepts. Real patterns live in common use cases and examples.

Verdict: keep one workflow per purpose — CI, release, scheduled maintenance — not one file with twenty conditional jobs. Small files are far easier to reason about when a run fails at 2 a.m.

Reusable workflows, composite actions, or a matrix: which one?

Use a matrix when you run the same job across variations, like Node 18, 20, and 22, or three operating systems. A composite action fits a sequence of steps you repeat inside one repository, such as checkout, language setup, and cache restore. Reach for a reusable workflow when whole jobs need to be shared across many repositories. They solve different problems and often show up together.

Mechanism	Scope	What it shares	Called with
`strategy.matrix`	One job, many variants	Nothing — same steps, different inputs	Built into the job
Composite action	Within or across repos	A sequence of steps	`uses:` at the step level
Reusable workflow	Across repos	Whole jobs, with inputs and secrets	`uses:` at the job level, `secrets: inherit`

A matrix is the simplest and the one to try first:

strategy:
  matrix:
    node: [18, 20, 22]

That runs the job three times in parallel. Because a matrix caps at 256 jobs per workflow run, a two-dimensional matrix across many values adds up faster than people expect.

Composite actions bundle steps into an action.yml file so a repo can call uses: ./.github/actions/setup instead of repeating six lines. The reusable workflow is a full workflow with on: workflow_call, typed inputs, and either explicit secrets or secrets: inherit. It is how a platform team standardizes CI across forty services. The reusable workflows and composite actions guide has working examples of both.

Verdict: reach for a matrix first. Build a composite action or a reusable workflow only once you are copy-pasting the same block into a third place.

How should GitHub Actions handle secrets and cloud auth?

Stop storing long-lived cloud keys as repository secrets. Use OpenID Connect (OIDC): the workflow requests a short-lived token from AWS, Azure, or Google Cloud at run time, scoped to that repository and branch. For everything else, keep the GITHUB_TOKEN read-only by default and raise permissions per job. Never pass a secret as a command-line argument, because another job on the same runner can read it with ps x -w.

GitHub's own hardening guide is direct about the risks. It says automatic redaction "is not guaranteed," so mask anything sensitive that is not already a GitHub secret with the ::add-mask:: workflow command. It also says "Never use structured data as a secret" — a JSON or YAML blob lowers the odds that redaction catches every piece of it. Create one secret per value.

The permissions key is the single highest-value line in most workflows:

permissions:
  contents: read
  id-token: write   # only in the job that needs OIDC

GitHub flipped the GITHUB_TOKEN default to read-only for new repositories in 2023. But organizations created before February 2023 may still default to read-write. So check your organization's Actions settings and set it explicitly.

OIDC removes the stored key entirely. The workflow proves its identity to the cloud provider, which hands back a token that expires in minutes. GitHub's docs recommend it directly for any workflow that deploys to a cloud provider or uses HashiCorp Vault. One caveat: "Support for custom claims for OIDC is unavailable in AWS." So scope AWS trust policies on the standard subject claim.

For the day-to-day rules, see managing workflow secrets safely and the wider security best practices checklist. The official security-hardening docs are the source for all of the above.

Verdict: OIDC for cloud, a read-only GITHUB_TOKEN everywhere, and third-party actions pinned to a commit SHA. The section on what breaks explains why that last one is not optional.

How does GitHub Actions caching work, and what does it cost?

The actions/cache action stores a directory keyed by a hash, usually of your lockfile, and restores it on the next run. Each repository gets 10 GB of cache. GitHub deletes any cache not accessed in seven days. Once a repo passes 10 GB, it evicts entries "in order of last access date, from oldest to most recent." A pull request can restore caches from its own branch, the default branch, and its base branch. It cannot read caches from sibling or child branches.

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      npm-

The action looks for an exact key match first, then partial matches, then each restore-keys prefix in turn. A key can be up to 512 characters. The cache is best-effort: a miss should slow the build, never break it.

⚠️ Note: caches are not private within a repo. The docs are explicit: "Anyone who can open a pull request against your repository can read the contents of caches in the base branch." Do not cache credentials, tokens, or anything derived from a secret.

For key design and layered caching strategies, see caching and performance tuning. The official caching docs cover cross-OS archives and rate limits.

Verdict: cache dependency downloads, never build output you cannot trust to be stale. If a cache miss breaks your build, the build was already broken.

How do you enforce that tests pass and the right people review?

Enforcement lives in branch protection, not the workflow file. In the protected branch's rule, mark specific status checks as required, and the merge button stays disabled until they pass. Add a CODEOWNERS file to require a named team's review on the paths they own. For a monorepo, path filters plus per-path approval rules stop a frontend change from needing the database team's sign-off.

Required status checks are matched by job name. That creates a quiet trap. Rename a job in the workflow and the required check no longer matches, so the rule silently stops enforcing anything. So keep job names stable, or update the branch rule in the same change.

A CODEOWNERS file at .github/CODEOWNERS maps globs to owners:

/api/        @org/backend
/web/        @org/frontend
*.tf         @org/platform

With "Require review from Code Owners" enabled, a pull request touching /api/ needs a @org/backend approval before merge. The CODEOWNERS and review permissions guide covers the syntax edge cases, and path-based approval rules show how to scope checks per directory.

Two more pieces round this out. The guide to running unit tests in CI covers wiring the test job so its result is a usable status check. And pull request and issue templates give reviewers a checklist, so "looks fine" reviews get rarer.

Verdict: a test that is not a required status check is a suggestion. Wire the check into branch protection, or accept that people will merge red.

How do GitHub Actions deployment environments work?

An environment is a named deployment target — staging, production — with its own secrets and protection rules. A job that sets environment: production pauses until its rules pass: required reviewers approve, a wait timer elapses, or the branch matches an allowed pattern. Environment secrets are visible only to jobs targeting that environment, which keeps production credentials out of every other run.

deploy:
  runs-on: ubuntu-latest
  environment: production
  concurrency: production
  steps:
    - run: ./deploy.sh

The environment line does two things: it gates the job behind the environment's rules, and it scopes which secrets the job can read. The concurrency: production line stops two deploys running at once, so a fast follow-up merge queues behind the current release instead of racing it.

Rolling, blue-green, and canary deploys are not features you toggle. You build them by calling your platform's CLI or API across environment-scoped jobs, with the environment gate providing the human checkpoint. Tag-based releases fit here too — cutting a release from a Git tag is a clean trigger for a production workflow. The deployment strategies and environments guide walks through each pattern, and automating releases covers changelog and versioning steps.

Verdict: put every deploy behind an environment with at least one required reviewer for production. It is the cheapest safety net Actions gives you.

What actually breaks GitHub Actions in production?

Four failure modes show up again and again: a compromised third-party action leaking secrets, a pull_request_target workflow running attacker code, caches vanishing mid-sprint, and jobs silently hitting a platform limit. None of these appear in a tutorial. All of them have cost real teams real incidents.

A compromised action dumps your secrets into the logs

In March 2025, the widely used tj-actions/changed-files action was compromised (CVE-2025-30066). An attacker repointed every tag from v1 through v45.0.7 to a single malicious commit, 0e58ed8. The injected code read secrets out of the runner's memory and printed them into the workflow log, which is public on any public repository. More than 23,000 repositories ran the poisoned version before it was caught. The fix shipped as v46.0.1, and CISA advised every affected project to rotate every credential the workflow could touch during the window.

The defense is pinning. A tag is a movable pointer; a commit SHA is not.

# vulnerable — a tag can be repointed
- uses: tj-actions/changed-files@v45

# safe — an immutable reference
- uses: tj-actions/changed-files@a5b3c1d2e4f5...

GitHub's hardening guide says a full-length commit SHA "is currently the only way to use an action as an immutable release." Turn on Dependabot so a known-bad version gets flagged, and audit that the SHA belongs to the action's real repository, not a fork.

`pull_request_target` runs code from the fork with your token

The pull_request_target trigger runs with your repository's secrets and a writable GITHUB_TOKEN, but in the base repository's context, so it can comment on or label a pull request from a fork. The danger is checking out the pull request's head and then running anything from it:

# dangerous pattern
on: pull_request_target
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci && npm run build

That npm ci runs postinstall scripts from an attacker's branch, with your secrets in scope. Security researchers used exactly this pattern to reach remote code execution in workflows at Microsoft, Google, and Nvidia. The rule from GitHub's docs: workflows using these triggers "must not explicitly check out untrusted code." Use plain pull_request for anything that runs a contributor's code — it has no secrets and a read-only token — and move any privileged follow-up into a separate workflow_run workflow.

Your cache disappears the week you need it

The seven-day eviction plus the 10 GB cap means a cache you depend on can vanish after a quiet week, and a busy monorepo can evict its own caches within a day as new entries push old ones out. The symptom is CI time doubling overnight with no code change and no alert. Check the repository's cache list when build times jump:

gh cache list --repo owner/name

Scope keys tightly so unrelated changes do not invalidate everything, and design the build so a cold cache is slow but still green.

A job hits a limit and just stops

These limits have no loud error. A job is killed at six hours of execution time. Queued jobs are cancelled after 24 hours waiting for a runner. Matrix builds cap at 256 jobs per run. Concurrent jobs cap at 20 on Free, 40 on Pro, 60 on Team, and 500 on Enterprise, so a large matrix on a Free plan queues behind itself. The GITHUB_TOKEN also gets 1,000 API requests per hour per repository, so a workflow that loops over the API can start returning 403s late in the run.

Set an explicit timeout-minutes well under six hours so a hung job fails fast, keep matrices small, and know your plan's concurrency number before you fan out. The monitoring and debugging guide covers reading run logs when a job ends without an obvious reason. For the repository side of the same problem, see Git security best practices.

Verdict: pin actions to SHAs, keep untrusted code out of privileged triggers, and assume every cache and every runner is about to disappear. Design for that and GitHub Actions is boringly reliable.

Frequently Asked Questions

Q: Do I need GitHub Actions if I already use Git?
A: Git tracks code history; GitHub Actions automates what happens to that code. You can use Git alone, but you lose automated tests on every pull request, one-click deploys, and required checks that block bad merges. For a solo project it is optional. For a team, that automation is what keeps main releasable.

Q: Is rebase or merge better for a team?
A: Both, at different times. Rebase your own local commits to tidy them before the first push. Merge branches once other people have pulled them. The pull-request merge button is a merge and should stay that way. Never rebase a branch someone else has already based work on.

Q: How do I stop a third-party GitHub Action from stealing secrets?
A: Pin it to a full commit SHA, not a tag. A tag can be repointed to malicious code, as the tj-actions/changed-files compromise showed in 2025. Set the GITHUB_TOKEN to read-only, grant write access per job, and use OIDC instead of stored cloud keys. Turn on Dependabot to flag known-bad versions.

Q: Why did my GitHub Actions build suddenly get slower?
A: The most common cause is cache eviction. GitHub deletes caches not used in seven days and evicts the oldest once a repository passes 10 GB. A quiet week or a busy monorepo can wipe the cache you rely on, doubling build time with no code change and no alert. Check gh cache list.

Q: Where should I enforce that tests pass before a merge?
A: In branch protection, not the workflow file. Mark the test job as a required status check on the protected branch, and the merge button stays disabled until it passes. A workflow that runs tests but is not wired into branch protection does nothing to stop a red merge.

Quick Summary:

GitHub Flow — one main, short-lived feature branches, merge via pull request — is the right default. Move to trunk-based only with a fast, trusted test suite.
Rebase local commits before the first push; merge anything already shared. The Pro Git rule: never rebase commits others may have based work on.
Pin third-party actions to a full commit SHA. The tj-actions/changed-files compromise (CVE-2025-30066, March 2025) repointed every tag to secret-stealing code across 23,000+ repositories.
GitHub Actions caches are 10 GB per repository and evicted after seven days unused. A build that slows overnight with no code change is usually a lost cache.
Real enforcement lives in branch protection. A test that is not a required status check will not stop a red merge, and deploys belong behind an environment with a required reviewer.

Working through one of these decisions now? Start with the branching model — the three-model breakdown has the commands for each. Then wire your test job into branch protection before you touch anything else.

GitHub Actions Self-Hosted Runners: Fix Before Sept 25

Amaresh Pelleti — Thu, 27 Aug 2026 10:53:57 +0000

If you run GitHub Actions self-hosted runners, the enforcement clock isn't approaching — it's already running. GitHub's minimum-version enforcement blocks registration below version 2.329.0. It's been fully in effect for GitHub Enterprise Cloud with data residency since July 31, 2026, and for the rest of github.com the brownout windows started August 24 — full enforcement lands September 25.

The practical takeaway isn't "update your runners." It's that GitHub already tried this once and had to pull it days before the deadline, and the fix has a gap the changelog doesn't spell out: auto-update can't save a runner that's already below the line, because the version check happens before auto-update ever gets a chance to run.

What Breaks If You Don't Upgrade Your GitHub Actions Self-Hosted Runners

Two separate requirements kick in. Runners need version 2.329.0 or later just to register at all. Once registered, GitHub raises the bar again — runners must install new releases within 30 days of publication, or they stop picking up jobs even though they stay registered.

Each deadline comes with brownout windows — scheduled periods where GitHub temporarily blocks old-version registration so you can catch problems before enforcement is permanent. For September 25, those windows are already running: August 24 was the first, with more on August 31, September 2, 7, 9, 11, 14, 16, and 18 (11:00 AM–3:00 PM ET each). Miss the deadline entirely and the failure mode is blunt. New runners fail to register. Existing runners stop picking up jobs, and workflows targeting them sit queued or fail outright. Separately, when GitHub ships a critical security update to the runner, job queuing pauses on runners that haven't applied it.

[IMAGE: articles/images/2026-08-25-github-actions-self-hosted-runner-enforcement-diagram.png | alt: "registration flow for github actions self-hosted runners hitting the minimum version gate"]

If you're new to running your own runners at all, the guide to your first GitHub Actions CI/CD pipeline covers the baseline setup this enforcement sits on top of.

Why Enforcement Got Paused Once Already

This isn't GitHub's first attempt. Enforcement was originally slated for early 2026, pushed to March 16, and then paused three days before that deadline. GitHub's pause notice gave no technical reason — just wanting "a smooth transition" — but third-party reporting tied it to kernel compatibility failures v2.329.0 exposed in legacy cgroup environments, the kind of failure that breaks CI pipelines overnight. Three months later, GitHub came back with the current July 31 / September 25 timeline.

That history matters for one reason. 2.329.0 is the floor GitHub checks at registration, not a recommendation. Pull the current runner release instead of the minimum version number quoted in the changelog — newer releases carry every fix shipped since the pause, and the 30-day rule means you need to stay near-current anyway.

The Registration Trap: Why Auto-Update Won't Save an Old Runner

Here's the gotcha GitHub's own docs don't call out directly. Auto-update on a self-hosted runner only kicks in after the runner successfully registers with ./config.sh. If a runner is already below the minimum version, registration gets rejected first. Auto-update never gets a chance to pull a newer release.

That's a real chicken-and-egg problem. It hits teams provisioning runners from a golden image or a container that hasn't been rebuilt recently. A GitHub community discussion confirms the fix isn't waiting for auto-update. Bake a current runner tarball into the image or startup script before config.sh runs. Auto-update keeps it current from there.

# check what version a running self-hosted runner is on
cat _diag/*.log | grep -i "Runner Version"

# disable auto-update explicitly (you'll then own manual updates
# within 30 days of each new release, per GitHub's policy)
./config.sh --disableupdate

⚠️ Important: if you use --disableupdate, you're committing to manually updating that runner within 30 days of every new release GitHub ships — not just the current one. Most teams are better off leaving auto-update on and fixing the registration-time version at the image level instead.

How to Check and Upgrade GitHub Actions Self-Hosted Runners

Inventory your runner images and startup scripts. Anywhere a VM image, container image, or Kubernetes manifest pins a runner tarball URL or version string, that's a place a current runner release needs to land before September 25.
Confirm the version already registered. GitHub's Actions settings page lists each runner's version under Settings → Actions → Runners; cross-reference against anything still on 2.328.x or earlier.
Rebuild images with the current runner release, not the bare minimum. The reported cgroup issues with v2.329.0 are reason enough to stay off the exact floor version.
Re-run registration in a non-production environment first if you manage runners through Terraform, Pulumi, or a custom operator — the registration handshake is where the version gate lives, and that's the step most likely to silently fail in automation.
Leave auto-update enabled on any runner you don't have a strict reason to pin, so this doesn't recur at the next enforcement wave.

Once your runners are current, the caching and performance guide and the security best practices guide are worth a pass too — a version audit is a natural time to also check for other drift. And if you want visibility into runner health going forward instead of finding out at the next deadline, the monitoring and debugging guide covers exactly that.

Upgrade Now or Wait?

Upgrade now, in a staging environment — the brownout windows running through September 18 are exactly the feedback loop to use. GitHub's first enforcement attempt got paused amid reports of v2.329.0 breaking legacy cgroup setups, so treat this as a real change to test, not a checkbox. Because the failure mode is silent queuing rather than a loud error, teams that wait until the deadline usually find out from a stalled deploy, not a warning.

If your runners already sit on GitHub-managed VM images or an actively maintained container base, this is likely a non-event; auto-update has probably already carried you past 2.329.0. The risk concentrates in golden images, air-gapped runners, and anything provisioned by infrastructure code that hasn't been touched since early 2026.

Frequently Asked Questions

Q: What's the actual minimum GitHub Actions runner version required?
A: 2.329.0 for registration. But pull the current release instead of the bare minimum — reported compatibility issues with 2.329.0 on legacy cgroup setups were tied to GitHub's paused first enforcement attempt, and the 30-day rule means you need to stay near-current anyway.

Q: Will my existing, already-registered runners just stop working on September 25?
A: Not immediately for registration — that gate only applies to new or re-registering runners. But the separate 30-day job-execution rule means an already-registered runner that falls too far behind on releases will stop picking up jobs, even without re-registering.

Q: Does this affect GitHub Enterprise Server customers?
A: No. The enforcement applies to self-hosted runners on github.com — including GitHub Enterprise Cloud and its data-residency variant. GitHub says Enterprise Server isn't impacted at this time.

Q: Can I just disable auto-update and update manually on my own schedule?
A: Yes, with ./config.sh --disableupdate, but you then own updating within 30 days of every new release GitHub ships, not a schedule you control. For most teams, leaving auto-update on and fixing the version at the image level is simpler.

Quick Summary

Enforcement has been live for GitHub Enterprise Cloud data-residency orgs since July 31, 2026; for the rest of github.com, brownout windows are running now ahead of full enforcement September 25
Minimum version for registration is 2.329.0, but pull the current release — reported kernel compatibility problems with the bare minimum on legacy cgroup setups were tied to GitHub pausing its first enforcement attempt in March
Auto-update can't rescue a runner that's already below the minimum, because registration is rejected before auto-update gets a chance to run
Fix it at the image or startup-script level, not by waiting for the runner to self-update
GitHub Enterprise Server customers are not impacted at this time, per GitHub's changelog

Rebuild your GitHub Actions self-hosted runners with the current release now, register one in staging during a brownout window, and confirm the version shown in GitHub's Actions settings page before September 25 turns this into a production incident.

Git 2.55: History Fixup, Rust by Default, Safer Checkouts

Amaresh Pelleti — Tue, 25 Aug 2026 10:43:55 +0000

Git 2.55 landed on June 29, 2026, and the headline change isn't a new command — it's a build requirement. Starting with this release, building Git from source requires a Rust toolchain unless you explicitly opt out. Alongside that, Git 2.55 Git ships git history fixup for editing an old commit without a full interactive rebase, a safer git checkout -m that won't leave you with a half-resolved mess, and native fsmonitor support on Linux.

Here's exactly what changed, the commands you'll actually use, and what breaks if you build Git from source in CI.

git history fixup: Editing an Old Commit Without Rebase

Interactive rebase has always been the tool for folding a small fix into an earlier commit, but it means dropping into an editor and picking through a to-do list even for a one-line change. git history fixup skips that:

git add foo.c
git history fixup abcdef01

Stage your change normally, then point git history fixup at the target commit. It folds the staged change into that commit and replays every commit after it on top — the target commit keeps its original message and authorship unless you pass --reedit-message. The command is intentionally conservative: it requires a clean working tree and aborts outright if replaying the later commits would produce a conflict, rather than leaving you halfway through a rebase.

If you're already comfortable with git rebase --autosquash and fixup! commit prefixes, this covers the same use case with one command instead of a two-step commit-then-rebase dance. For anyone who's avoided rebase, stash, and cherry-pick because the interactive editor felt like overkill for a single-line fix, this is the more direct path.

Safer git checkout -m Behavior

git checkout -m <branch> re-applies your local changes on top of the branch you're switching to, merging them in. Before Git 2.55, if that merge hit a conflict, you got exactly one shot to resolve it on the spot — mess it up and you were stuck with a half-resolved working tree.

Git 2.55 changes the mechanics: checkout -m now uses an autostash internally, so your local changes land in a stash entry instead of a conflicted working tree. You can resolve the conflict immediately, or walk away and come back to it later with git stash pop when you're ready. If you've ever hit a merge conflict mid-checkout and had to untangle it under pressure, this removes the time pressure entirely.

Rust Now Required to Build Git From Source

This is the change that affects the most people indirectly, even if most Git users will never notice it. As of Git 2.55, the Rust compiler is required to build Git from source, unless you explicitly disable it:

# Makefile-based builds
make NO_RUST=YesPlease

# Meson-based builds
meson configure -Drust=disabled

If you install Git through your OS package manager or a prebuilt binary, this changes nothing for you — the maintainers handle the build. It matters if your CI pipeline compiles Git from source as part of a custom image or hardened build process. Any pipeline like that needs a Rust toolchain available now, or it needs the NO_RUST flag set explicitly, or the build breaks the next time it runs.

This is part of a longer-term push by the Git project to replace selected components with Rust for memory safety, the same direction several other systems-level open source projects have taken. Don't expect Rust to become mandatory with no opt-out in the very next release, but treat this as the direction things are heading and plan your build pipeline accordingly.

fsmonitor Now Works on Linux

fsmonitor speeds up status checks on large repositories by watching the filesystem in the background instead of walking the whole working tree on every git status. It's had Windows and macOS implementations for a while — Git 2.55 adds a Linux implementation, built on inotify.

The daemon doesn't need elevated privileges to run, but it does need one watch per directory, so very large repositories may need a higher fs.inotify.max_user_watches limit than the Linux default. Network-mounted repositories stay opt-in for fsmonitor, matching the behavior on the other platforms. If you manage a monorepo where git status has always felt sluggish, this is worth enabling.

[IMAGE: articles/images/2026-07-24-git-2-55-new-features-diagram.png | alt: "how git history fixup folds a staged change into an earlier commit"]

Git 2.55 Parallel Hooks

Hooks configured through Git's config system — as opposed to plain scripts dropped in .git/hooks — can now run in parallel instead of one after another. Turn it on per hook:

git config hook.pre-commit.parallel true

Control concurrency globally with hook.jobs, per-event with hook.<event>.jobs, or per-invocation with -j. Hooks that depend on shared state still run serially — Git doesn't parallelize anything that could race. If you're using Git hooks to automate parts of your workflow and have several independent checks running on every commit, this can meaningfully cut down the wait.

Git 2.55 Remote-Group Push

You can now push to multiple remotes in one command by defining a remote group:

git config remotes.publish "github gitlab mirror"
git push publish main

git push publish main pushes sequentially to every remote listed under remotes.publish. One limitation worth knowing: --atomic isn't supported for grouped pushes, since atomicity can't be guaranteed across multiple independent connections. If a push to one remote fails partway through, the others may already have succeeded.

Should You Upgrade to Git 2.55 Now

For most people, yes — none of the changes in this release are disruptive if you're using Git normally through a package manager or prebuilt binary. The one group that needs to act before upgrading: anyone with a CI pipeline or Docker image that compiles Git from source. Add a Rust toolchain to that build, or set NO_RUST=YesPlease explicitly, before you pull in 2.55.

Everyone else gets a genuinely useful set of additions — git history fixup for quick historical edits, a safer checkout -m, and fsmonitor finally working on Linux — without anything to migrate or rewrite. If you want the full technical rationale behind each change, GitHub's release highlights and GitLab's breakdown both cover the implementation details this article doesn't.

Frequently Asked Questions

Q: Do I need Rust installed to use Git 2.55?
A: Only if you're building Git from source. If you install it through a package manager, Homebrew, or a prebuilt binary, this change is invisible to you.

Q: Does git history fixup replace git rebase --autosquash?
A: Not entirely — it covers the common case of folding one staged change into an earlier commit in a single step. Complex interactive rebases with reordering or multiple fixups still need the full git rebase -i workflow.

Q: Will git checkout -m break my existing scripts if they expect the old conflict behavior?
A: If a script parses the exact output of a conflicted checkout -m and expects the working tree to be left in a conflicted state, yes, that output changes. Scripts that just check the exit code are unaffected.

Q: Can I use remote-group push with --force?
A: Yes, --force works with grouped pushes. It's specifically --atomic that's unsupported, because Git can't guarantee all-or-nothing delivery across multiple separate remote connections.

Quick Summary:

Git 2.55 requires Rust to build from source now, unless you set NO_RUST=YesPlease or -Drust=disabled explicitly — end users installing prebuilt Git are unaffected
git history fixup <commit> folds a staged change into an older commit and replays descendants, without a full interactive rebase
git checkout -m now autostashes conflicts instead of leaving a half-resolved working tree
fsmonitor finally has a Linux implementation, using inotify to speed up git status on large repos
Parallel hooks and remote-group push (git push publish main) round out the release

That's the full Git 2.55 picture: if you maintain a CI image that compiles Git from source, check that build today — that's the one place this release can break something without warning.

PostgreSQL 18: The 6 Features Worth Upgrading For

Amaresh Pelleti — Mon, 24 Aug 2026 22:25:28 +0000

PostgreSQL 18 is out, and it's a bigger release than the version bump suggests. The headline feature is a new asynchronous I/O subsystem that can cut read latency by up to 3x on the right workload. But the release also ships virtual generated columns as the new default, a uuidv7() function for sortable primary keys, and skip scan support for indexes that used to sit unused half the time.

Here's what's actually worth upgrading for, what changed under the hood, and what to check before you run pg_upgrade on production. The full technical detail lives in the official PostgreSQL 18 release notes — this covers the parts that change how you design and operate a database day to day.

PostgreSQL 18's Async I/O: Up to 3x Faster Reads

The AIO (asynchronous I/O) subsystem is the biggest architectural change in this release. Instead of issuing one disk read and waiting for it before starting the next, PostgreSQL 18 can queue multiple read requests at once. Sequential scans, bitmap heap scans, and vacuum operations all benefit directly.

Turn it on with a single setting:

SHOW io_method;

Two more settings control the behavior: io_combine_limit and io_max_combine_limit cap how many reads get batched together. If you're on a system without native fadvise() support, effective_io_concurrency and maintenance_io_concurrency now accept values above zero too, which wasn't possible before.

Want to see it working? Query the new pg_aios view — it shows the file handles currently in flight for async reads. If it's empty on a read-heavy workload, io_method probably isn't set the way you think it is.

[IMAGE: articles/images/2026-07-24-postgresql-18-new-features-diagram.png | alt: "sequential reads compared to the new asynchronous I/O subsystem"]

Storage-bound workloads see the biggest jump. If your bottleneck is CPU, not disk, don't expect PostgreSQL 18 to feel dramatically different — profile your actual queries with pg_stat_statements before assuming AIO will fix a slow endpoint.

Virtual Generated Columns Are Now the Default

Generated columns compute a value from other columns automatically. Before PostgreSQL 18, that computation always happened at write time, and the result got stored on disk. Now, virtual is the default:

CREATE TABLE orders (
  id INT,
  price NUMERIC,
  quantity INT,
  total NUMERIC GENERATED ALWAYS AS (price * quantity) VIRTUAL
);

Virtual columns compute the value at read time instead of write time — nothing gets stored. That saves disk space and write overhead, but it costs a bit of CPU on every read. If you need the old write-time behavior for a hot read path, say so explicitly:

CREATE TABLE orders (
  id INT,
  price NUMERIC,
  quantity INT,
  total NUMERIC GENERATED ALWAYS AS (price * quantity) STORED
);

Existing STORED columns from earlier versions keep working exactly as before — this only changes the default for new tables.

uuidv7(): Sortable UUIDs for Primary Keys

Random UUIDs (uuidv4()) have always been bad for index locality — every insert lands in a random spot in the B-tree, which fragments the index over time. PostgreSQL 18 ships uuidv7(), which encodes a timestamp into the leading bits:

SELECT uuidv7();

ALTER TABLE events ADD COLUMN id uuid DEFAULT uuidv7() PRIMARY KEY;

Because the timestamp sits at the front of the value, new rows insert close together in index order, the same way an auto-incrementing integer would. You get the collision-safety of a UUID without the write-amplification problem that's plagued uuidv4() primary keys for years. If you're designing a new schema, this is the default worth reaching for.

Skip Scan: Multicolumn Indexes That Actually Get Used

Multicolumn B-tree indexes have a well-known limitation: PostgreSQL could only use them efficiently if your query filtered on the leading column. An index on (tenant_id, status, created_at) was mostly useless for a query that filtered on status alone.

Skip scan changes that. PostgreSQL 18 can now use a multicolumn index even when the leading column has no restriction, by internally probing each distinct value of that column:

CREATE INDEX idx_orders ON orders(tenant_id, status, created_at);

-- Now benefits from the index above, even without a tenant_id filter
SELECT * FROM orders WHERE status = 'pending' AND created_at > now() - interval '1 day';

It's not free — skip scan works best when the leading column has a small number of distinct values. If tenant_id has millions of distinct values, the planner will likely still choose a sequential scan. Run EXPLAIN ANALYZE before and after upgrading to confirm the planner actually picks it up for your specific queries.

OAuth Authentication Support

PostgreSQL 18 adds native OAuth token authentication, configured in pg_hba.conf like any other auth method:

host    database    user    address    oauth

You'll need to build with --with-libcurl and load a token validation library via oauth_validator_libraries. This matters if your org is trying to get off long-lived database passwords and onto short-lived tokens tied to an identity provider — previously that meant a third-party proxy in front of Postgres. Now it's built in.

Upgrading to PostgreSQL 18 Without Losing Planner Statistics

The upgrade pain point that's kept people on old major versions isn't the schema — it's the hours-long window where a freshly upgraded cluster runs on empty planner statistics until ANALYZE catches up. PostgreSQL 18's pg_upgrade now preserves those statistics by default:

pg_upgrade -d /path/to/old_data -D /path/to/new_data

Extended statistics (the kind built with CREATE STATISTICS) aren't carried over — you'll still need to rebuild those manually. But regular column statistics survive the jump, so query plans stay sane immediately after cutover instead of degrading until autovacuum's analyze catches up. If you'd rather start clean, --no-statistics disables the behavior.

Breaking Changes to Check Before You Upgrade

A few defaults changed in ways that can bite you mid-migration:

Data checksums are now on by default in initdb. pg_upgrade requires matching checksum settings between the old and new cluster, so mismatched checksum config is the first thing to check if the upgrade fails immediately.
VACUUM and ANALYZE now process partitioned table children by default. If you were relying on the old skip-children behavior, add ONLY to keep it: VACUUM ONLY parent_table.
MD5 password authentication is deprecated — not removed yet, but CREATE ROLE and ALTER ROLE now emit a warning when you set one.
Full-text search now follows the cluster's default collation provider instead of always using libc. If your cluster runs a non-libc provider, reindex your full-text and pg_trgm indexes after upgrading.

None of these block an upgrade on their own, but any one of them can produce a confusing error if you're not expecting it — pgpedia's PostgreSQL 18 page tracks the full list if you want to check something not covered here first. If you hit something not covered here, our PostgreSQL troubleshooting guide walks through the most common post-upgrade failures.

Patch to the Latest Minor Version Before You Deploy

Don't install 18.0 straight off the release notes. PostgreSQL has shipped 18.1 through 18.6 since the initial release, fixing 46 CVEs along the way — several of them CVSS 8.8 remote-code-execution-class bugs. That includes CVE-2026-14676, a heap buffer overflow in pg_stat_statements itself, the exact extension this article points you to for profiling queries before you chase an AIO-related performance win. Pull the current minor (18.6 as of this writing) before you touch production, and set a reminder to keep pulling new minors — none of this is a one-time patch.

Should You Upgrade to PostgreSQL 18 Now

If you're running a workload where disk I/O is the bottleneck, the async I/O subsystem alone justifies testing PostgreSQL 18 in staging. Combined with statistics-preserving upgrades, the operational risk of the jump itself is lower than past major version upgrades. PostgreSQL 19 is in beta (Beta 3 as of this writing) and not recommended for production, so there's no reason to wait on 18 if you're evaluating a new deployment now.

If your database runs on Kubernetes, check how CloudNativePG handles major version upgrades before scheduling this — the sequencing matters more in an operator-managed cluster than a standalone install. And if you're running partitioned tables at scale, revisit your partitioning strategy against the new VACUUM defaults before you cut over, since the children-by-default change affects partition maintenance directly.

Frequently Asked Questions

Q: Do I need to change my application code to benefit from async I/O in PostgreSQL 18?
A: No. AIO works at the storage engine level. You get the benefit automatically once io_method is configured, with no query or schema changes required.

Q: Will my existing STORED generated columns break after upgrading to PostgreSQL 18?
A: No. Existing STORED columns keep working exactly as before. The new VIRTUAL default only applies to columns you create after upgrading, unless you explicitly write STORED.

Q: Is uuidv7() a drop-in replacement for uuidv4()?
A: For new tables, yes — swap the default and you get sortable inserts. For existing tables with uuidv4() primary keys already in production, migrating is a separate project since existing values won't retroactively sort.

Q: How long does upgrading to PostgreSQL 18 actually take with statistics preservation?
A: It depends on database size, but the statistics-preservation feature removes the multi-hour "cold cache, bad plans" window that used to follow a pg_upgrade. The physical upgrade time itself is unchanged — you're saving the recovery period after it, not the upgrade itself.

Q: Is it safe to run PostgreSQL 18.0, or should I be on a specific minor version?
A: Don't run 18.0 in production. PostgreSQL has shipped 18.1 through 18.6 since the initial release, fixing 46 CVEs, several of them CVSS 8.8 remote-code-execution bugs — including one in pg_stat_statements itself. Always deploy the current minor release and keep pulling new ones as they ship.

Quick Summary:

PostgreSQL 18's async I/O subsystem can cut read latency up to 3x on storage-bound workloads, with no query changes required
Virtual generated columns are now the default — computed at read time instead of write time, use STORED explicitly if you need the old behavior
uuidv7() gives you sortable, collision-safe UUIDs without the index fragmentation uuidv4() causes
Skip scan makes multicolumn indexes usable even when queries don't filter on the leading column
pg_upgrade now preserves planner statistics by default, removing the post-upgrade performance dip
Don't deploy 18.0 as-is — 18.1 through 18.6 fixed 46 CVEs, including a critical RCE in pg_stat_statements; always pull the current minor

Test PostgreSQL 18 against your actual query patterns in staging before committing to a production upgrade — EXPLAIN ANALYZE your slowest queries first and last, since the AIO and skip scan gains vary a lot by workload shape.