DEV Community: Emrullah Bozkurt

Why React 19's useOptimistic Replaces Manual Rollback Logic for Server Mutations

Emrullah Bozkurt — Tue, 06 Oct 2026 18:45:40 +0000

Manual optimistic updates in React have always required a stack of useState calls: one for the current value, one for the pending flag, one for the error, and often a ref to track the previous value so a catch block can restore it. Every mutation becomes a ceremony — set pending, optimistically update, await the request, then either commit or manually roll back in the catch. Miss a finally block and the UI stays stuck in a loading state; fire two requests in quick succession and the second response can overwrite the first, leaving the user with stale data.

React 19's useOptimistic hook collapses this entire pattern into a single call that returns an array with exactly two values: the optimistic state and a setter function (React docs). When the associated Action settles — whether it resolves or throws — React automatically reverts to the canonical value in the same render, no catch block required (React 19 blog). Actions also expose built-in pending state and error handling, so the boilerplate that used to live in useEffect and try/catch disappears entirely (React 19 blog). The old pattern isn't just verbose; it's a surface area for bugs that the new hook eliminates.

How useOptimistic Works Under the Hood

useOptimistic returns a two‑element array: the current optimistic state and a setter function. The first element is the value you passed in — until an Action starts. While that Action is pending, the hook shows either the reducer's output or the raw value you handed to the setter.

function CommentList({ comments }: { comments: Comment[] }) {
  const [optimisticComments, addComment] = useOptimistic(
    comments,
    (current, newComment: Comment) => [...current, newComment]
  );

  return (
    <ul>
      {optimisticComments.map(c => <li key={c.id}>{c.text}</li>)}
    </ul>
  );
}

The reducer runs with the latest comments prop whenever it changes during a pending Action. React re‑invokes your reducer with the fresh base data so optimistic additions stay stacked on top of the server's current view. This means you don't need a separate useEffect to reconcile incoming props with pending mutations.

When the Action finishes — success or failure — there is no extra render to "clear" the optimistic layer. The optimistic and real state converge in the same render that completes the Transition. The component simply receives the updated comments prop from the server, and the hook's first return value switches back to it without a visible flash or intermediate frame. On failure, the optimistic updates are discarded and the component renders the server's authoritative state.

Automatic Rollback Without Catch Blocks

When the server mutation fails, the Transition ends and React renders with the current value — which, because the parent only updates on success, remains the pre‑optimistic state. No catch block, no manual rollback, no extra render to "clear" the optimistic layer. The hook's first return value switches back immediately.

async function updateCommentAction(commentId: string, newText: string) {
  'use server';
  const res = await fetch(`/api/comments/${commentId}`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: newText }),
  });
  if (!res.ok) {
    throw new Error('Failed to update');
  }
  return res.json();
}

function CommentEditor({ comment }: { comment: Comment }) {
  const [optimisticText, setOptimisticText] = useOptimistic(
    comment.text,
    (current, newText: string) => newText
  );

  async function handleSubmit(formData: FormData) {
    const newText = formData.get('text') as string;
    setOptimisticText(newText);
    await updateCommentAction(comment.id, newText);
  }

  return (
    <form action={handleSubmit}>
      <textarea
        value={optimisticText}
        onChange={e => setOptimisticText(e.target.value)}
        name="text"
      />
      <button type="submit">Save</button>
    </form>
  );
}

The setter runs inside the Action. If updateCommentAction throws, the Transition completes and React renders with the unchanged comment.text — the optimistic value disappears in the same render.

Error path — optimistic update applied, server fails, Transition ends, UI reverts to original value in the same render.

This behavior is guaranteed by the hook's contract: the setter must be called inside an Action; calling it outside triggers a warning and a brief optimistic flash (https://react.dev/reference/react/useOptimistic). When the Action throws, the Transition still ends, and React renders with whatever value currently exists — typically the unchanged server state (https://react.dev/reference/react/useOptimistic). The React 19 blog notes that Actions automatically manage pending state, error handling, and optimistic updates, reverting to the original value when a request finishes or errors (https://react.dev/blog/2024/12/05/react-19).

The rejected promise from the Action still needs to be handled — either with a try/catch inside the Action, the error tuple returned by useActionState, or an Error Boundary — to avoid an unhandled rejection. The UI rollback occurs only when the Action's promise settles, and it assumes the parent component does not mutate its own state on error.

Race Conditions and Transitions

Rapid successive updates expose a gap in the raw useOptimistic API. When a user clicks a toggle multiple times before the first request resolves, each setOptimisticTask call replaces the pending state rather than merging concurrent changes. The UI briefly shows stale or incorrect data until the server responds (source).

Figure: Rapid clicks produce synchronous optimistic updates that React batches inside a transition, yielding a single render with the final state.

The fix is to keep the optimistic setter synchronous while wrapping the actual mutation in startTransition. This lets React treat the async work as a transition, batching and reconciling overlapping updates instead of letting them clobber each other (source).

function TaskItem({ task }: { task: Task }) {
  const [optimisticTask, setOptimisticTask] = useOptimistic(
    task,
    (current, update: Partial<Task>) => ({ ...current, ...update })
  );
  const [isPending, startTransition] = useTransition();

  const handleStatusChange = (newStatus: TaskStatus) => {
    setOptimisticTask({ status: newStatus });
    startTransition(async () => {
      await updateTaskStatus(task.id, newStatus);
    });
  };

  return (
    <div className={isPending ? "opacity-50" : ""}>
      <select
        value={optimisticTask.status}
        onChange={(e) => handleStatusChange(e.target.value as TaskStatus)}
        disabled={isPending}
      >
        <option value="todo">To Do</option>
        <option value="done">Done</option>
      </select>
    </div>
  );
}

useTransition returns isPending, which stays true while any transition is active. Use it to dim the UI, disable inputs, or show a spinner — no extra useState required. The transition also ensures that if the Action throws, React reverts to the pre‑optimistic value in the same render cycle, eliminating manual rollback logic.

Batching constraint: React only merges optimistic updates when all setOptimistic calls execute synchronously within the same event handler, before any await. If you trigger an optimistic update after an await (for example, in a chained mutation or a debounced callback), that update runs outside the original transition and will not be batched with prior ones — it can overwrite the pending state. To guarantee merging, keep every optimistic write in the synchronous portion of the handler, or queue updates and flush them inside a single startTransition callback. The transition boundary is the batching boundary; plan accordingly.

Concern	Manual `useState` + `useEffect`	`useOptimistic` + `startTransition`
Lines of code	~40–60 (state, effect, rollback, loading, error)	~15–20 (hook, setter, transition)
Rollback handling	Explicit `catch` block + state restore	Automatic on Action throw
Race‑condition safety	Manual `AbortController` or version tokens	Built‑in via transition batching

Integrating with Forms and useActionState

React 19 lets you drop the useState dance entirely by pairing a <form action={...}> with useActionState. The hook wraps your server Action and returns a tuple: the last result (or undefined before the first submit), a pending boolean, and any thrown error. When the form submits, React calls the Action, tracks its promise, and surfaces those three values without extra renders or manual state synchronization.

import { useActionState, useFormStatus } from "react";

async function updateName(prev: string | undefined, formData: FormData) {
  const res = await fetch("/api/user", {
    method: "PATCH",
    body: JSON.stringify({ name: formData.get("name") }),
  });
  if (!res.ok) throw new Error("Failed to update");
  return res.json();
}

function NameForm() {
  const [name, submit, { pending, error }] = useActionState(updateName, "");

  return (
    <form action={submit}>
      <input name="name" defaultValue={name} disabled={pending} />
      <SubmitButton />
      {error && <p className="error">{error.message}</p>}
    </form>
  );
}

function SubmitButton() {
  const { pending } = useFormStatus();
  return <button type="submit" disabled={pending}>{pending ? "Saving…" : "Save"}</button>;
}

The <form action> prop accepts the wrapped Action from useActionState. On success, React does not reset uncontrolled inputs automatically — they retain their values. If you need to clear the form, call requestFormReset (from react-dom) or manage controlled components with state. useActionState itself does not touch input values. useFormStatus lets any descendant (like SubmitButton) read the form's pending state without prop drilling, since the form acts as a context provider. Together, these APIs eliminate the boilerplate of tracking isSubmitting, submitError, and lastResult in separate useState calls. The form, the Action, and the status hook all share the same underlying transition, so the UI stays consistent without manual coordination.

When You Still Need Manual Control

useOptimistic covers the happy path: a single Action, a predictable rollback, and a UI that converges without extra state. It does not, however, replace every pattern teams have built around optimistic updates.

The most common gap is optimistic concurrency control that relies on server‑side conflict tokens. HTTP's statelessness makes locking infeasible, so web UIs commonly use ETag/If‑Match headers or hidden fields containing timestamps, sequence numbers, or opaque tokens to detect stale writes (source). When the server rejects a mutation because the token has changed, the client must decide whether to retry with fresh data, surface a merge UI, or abandon the edit — logic that lives outside the Action's success/failure boundary and therefore outside useOptimistic's automatic rollback.

A second gap is non‑Action async flows. WebSocket pushes, Server‑Sent Events, or polling‑based sync engines mutate server state without going through a form Action. useOptimistic only reacts to the pending state of the Action you pass it; it has no hook into external event streams. You still need a manual reducer or a library like TanStack Query to reconcile those pushes against the optimistic cache. Additionally, useOptimistic does not integrate with Suspense-driven data fetching, and any external subscriptions (e.g., WebSocket listeners) must be cleaned up manually — the hook provides no automatic cleanup for such resources.

Finally, complex validation that depends on cross‑field rules or async lookups (e.g., "is this username still available?") often runs before the mutation commits. If the server returns a structured error payload that maps to multiple form fields, the simple throw‑and‑rollback model doesn't give you a place to attach that payload without reverting the optimistic UI first.

In these scenarios, useOptimistic remains a building block, not a complete solution. You keep the hook for the straightforward mutations and layer a custom reducer or conflict‑resolution layer on top for the exceptions.

Adopt the Hook, Delete the Boilerplate

Replace every manual optimistic-update implementation with useOptimistic and an Action. The migration checklist is short:

Delete the pending-state useState — Actions expose isPending through useActionState or useTransition.
Remove the catch-block rollback — React reverts to the original value automatically when the Action settles or throws.
Drop the race-condition guards — startTransition batches rapid submissions; the hook converges state without extra renders.
Swap useEffect side effects for the Action callback — the server call lives in the Action, not in an effect that races renders.
Verify Error Boundary coverage — failed Actions bubble to the nearest boundary while the UI snaps back to the pre-optimistic value.

If a mutation needs custom conflict tokens, multi-step validation, or non-Action async flows, keep useOptimistic for the simple path and layer a reducer on top. For the vast majority of server mutations, the old pattern is now an anti-pattern: more code, more bugs, and no advantage over the built-in behavior React 19.

References

Composition Root in Node.js: Dependency Injection Without a DI Framework

Emrullah Bozkurt — Mon, 05 Oct 2026 11:17:07 +0000

Introduction: The Quest for Clean Architecture in Node.js

When building backend applications in Node.js, managing dependencies between services, database adapters, external HTTP clients, and configuration providers is one of the most critical structural challenges. Many developers coming from Java or .NET immediately reach for runtime Dependency Injection (DI) frameworks like InversifyJS, TypeDI, or NestJS's built-in DI module.

However, Dependency Injection is simply a structural design pattern, whereas DI Containers are optional framework tools. In Node.js, these containers are often overkill. This article explores how to achieve clean architecture, decoupling, and effortless testability using the Composition Root pattern without any DI framework whatsoever.

What is a Composition Root?

A Composition Root is the unique entry point of an application where the entire dependency graph is instantiated, wired up, and bootstrap-configured. Typically, this is your main.ts or index.ts file.

Instead of modules importing their dependencies dynamically at runtime or pulling them directly from global state, dependencies are passed strictly down through constructors. At the very edge of your application—the entry point—you instantiate everything in sequence.

As shown above, the dependencies must be resolved sequentially in topological order. The low-level utilities (like configurations and database clients) are instantiated first, followed by repositories, services, and finally HTTP servers or controller layers.

The Pitfalls of DI Containers in JavaScript and TypeScript

While DI containers promise seamless dependency management, they introduce significant complexity to JavaScript and TypeScript projects.

Lack of Native Reflection: TypeScript does not exist at runtime. Unlike C# or Java, there is no built-in reflection API. To make DI containers work, frameworks must rely on non-standard, experimental TS compiler options like experimentalDecorators and emitDecoratorMetadata, alongside runtime polyfills like reflect-metadata.
Implicit Dependency Matching: Containers resolve dependencies using runtime tokens (such as strings or Symbols). This bypasses the compiler, making it possible to miss a binding that only fails at runtime when a service returns undefined.
Vendor Lock-in: Annotating business logic with framework-specific decorators like @Injectable() tightly couples your pure domain logic to a specific DI container library.

Implementing Explicit Factory Wiring with Interfaces

To ensure complete isolation of our business logic, we should inject interfaces rather than concrete classes. This adheres to the Dependency Inversion Principle (the 'D' in SOLID). In TypeScript, we can use an interface to define the contract, and standard constructor functions to compose the dependencies manually.

Let's write a simple, clean, working backend architecture starting with our types and classes.

// 1. types.ts
export interface User {
  id: string;
  name: string;
}

export interface IUserRepository {
  findById(id: string): Promise<User | null>;
}

// 2. database.ts
export class DatabaseClient {
  constructor(private readonly connectionUri: string) {}

  async connect(): Promise<void> {
    console.log(`Connected to database at ${this.connectionUri}`);
  }

  async disconnect(): Promise<void> {
    console.log("Disconnected database client.");
  }

  async query<T>(sql: string, params: unknown[] = []): Promise<T[]> {
    console.log(`Executing: ${sql} with params:`, params);
    // Mock implementation
    return [{ id: "123", name: "Alice" }] as unknown as T[];
  }
}

// 3. userRepository.ts
import { DatabaseClient } from "./database";
import { IUserRepository, User } from "./types";

export class UserRepository implements IUserRepository {
  constructor(private readonly db: DatabaseClient) {}

  async findById(id: string): Promise<User | null> {
    const rows = await this.db.query<User>("SELECT * FROM users WHERE id = $1", [id]);
    return rows[0] || null;
  }
}

// 4. userService.ts
import { IUserRepository } from "./types";

export class UserService {
  // Depend on the interface, not the concrete class
  constructor(private readonly userRepo: IUserRepository) {}

  async getUserDetails(id: string) {
    const user = await this.userRepo.findById(id);
    if (!user) throw new Error("User not found");
    return user;
  }
}

The Composition Root with Lifecycle Management

Our Composition Root is responsible for both construction and lifecycle coordination. It instantiates the classes in topological order, invokes asynchronous startup methods (like establishing the database connection), and listens for termination signals to perform clean, graceful shutdowns.

// main.ts (The Composition Root)
import { DatabaseClient } from "./database";
import { UserRepository } from "./userRepository";
import { UserService } from "./userService";

async function bootstrap() {
  // 1. Resolve configuration environment
  const dbUri = process.env.DATABASE_URL ?? "postgres://localhost:5432/db";

  // 2. Instantiate dependencies in topological order
  const databaseClient = new DatabaseClient(dbUri);
  const userRepository = new UserRepository(databaseClient);
  const userService = new UserService(userRepository);

  // 3. Coordinate startup lifecycle
  await databaseClient.connect();
  console.log(`Initializing application components...`);

  const user = await userService.getUserDetails("123");
  console.log(`Successfully bootstrapped. Sample user:`, user);

  // 4. Handle graceful shutdown
  const gracefulShutdown = async (signal: string) => {
    console.log(`\nReceived ${signal}. Starting graceful shutdown...`);
    await databaseClient.disconnect();
    process.exit(0);
  };

  process.on("SIGTERM", () => gracefulShutdown("SIGTERM"));
  process.on("SIGINT", () => gracefulShutdown("SIGINT"));
}

bootstrap().catch((err) => {
  console.error("Fatal error during bootstrap:", err);
  process.exit(1);
});

Scaling Pure DI Beyond Simple Files

Skeptics often worry that manual wiring becomes unmanageable as the application grows. If you have 150 services, your main.ts file will grow into a massive block of imperative code.

To prevent this, split your composition logic into modular domain sub-factories. Your central Composition Root simply coordinates these domain factories:

// userModule.ts (Sub-factory)
import { DatabaseClient } from "./database";
import { UserRepository } from "./userRepository";
import { UserService } from "./userService";

export function composeUserModule(databaseClient: DatabaseClient) {
  const userRepository = new UserRepository(databaseClient);
  const userService = new UserService(userRepository);
  return { userService, userRepository };
}

This keeps your central main.ts highly readable, serving purely as a high-level router/orchestrator of modules.

Type-Safe Mocking Without Framework Hacks

Because we write constructors that accept explicit interfaces, testing is trivial and completely type-safe without relying on magic container overrides or casting tricks. The compiler guarantees that our mock complies with the contract.

// userService.test.ts
import { UserService } from "./userService";
import { IUserRepository, User } from "./types";

describe("UserService", () => {
  it("should fetch user details correctly via mocked repository", async () => {
    const mockUser: User = { id: "123", name: "Test User" };

    // Compiler-verified mock implementing IUserRepository
    const mockRepo: IUserRepository = {
      findById: async (id: string): Promise<User | null> => {
        return id === "123" ? mockUser : null;
      }
    };

    // Secure compile-time injection
    const userService = new UserService(mockRepo);
    const result = await userService.getUserDetails("123");

    expect(result).toEqual(mockUser);
  });
});

Readability, Traceability, and Cold-Start Performance Benefits

Choosing explicit wiring over dynamic metadata DI containers offers immediate engineering advantages across three categories: readability, developer tooling, and execution performance.

1. Developer Tooling and Traceability

When navigating a container-wired codebase, finding where a class is registered can feel like detective work. In contrast, using pure DI preserves the effectiveness of your IDE's "Go to Definition" function.

2. Comparison Matrix: Pure DI vs. Container Frameworks

Feature	Explicit Wiring (Pure DI)	Container-based DI (e.g., Inversify, TypeDI)
Runtime Overhead	Zero (Standard JS/TS objects)	Medium (Metadata loading, container lookups)
IDE Navigation	Native "Go to Definition" works out-of-the-box	Broken or requires manual Symbol/String tracing
Type Safety	100% Compiler verified	Partial (Relies on runtime decorator string/symbol tokens)
Boilerplate / Setup	Minimal (One `main.ts` file setup)	High (Requires configurations, decorators, reflection)
Cold-Start Performance	Excellent (Instantaneous)	Slower (Impacted by dynamic class decorator scanning)

3. Cold-Start Performance

Removing DI container frameworks entirely eliminates initialization overhead. In serverless deployment environments like AWS Lambda, Azure Functions, or Google Cloud Run, cold-start latency is critical. A pure DI application avoids class scanning, decorator metadata compilation, and container resolution cycles, booting instantly to process user requests.

Conclusion: Keeping Node.js Applications Simple and Explicit

You do not need heavy framework setups to build clean, maintainable, testable backend architectures. By utilizing a Composition Root combined with interface-based Pure Dependency Injection, your Node.js code remains fully type-safe, simple to test, traceably navigable, and highly performant.

Why PostgreSQL MVCC Scales Better Than Lock-Based Reads for Read-Heavy Workloads

Emrullah Bozkurt — Mon, 05 Oct 2026 11:16:55 +0000

A dashboard query runs while a background job updates ten thousand rows. In a lock-based engine, that SELECT waits—sometimes for seconds—until every UPDATE releases its row locks. PostgreSQL's MVCC sidesteps this entirely: readers operate on a snapshot taken at query start, so they never block writers and writers never block readers.

The mechanism is straightforward. When a row changes, PostgreSQL writes a new tuple version instead of overwriting the old one. The previous version remains visible to any transaction whose snapshot predates the commit. Under steady-state conditions with adequate vacuuming, read latency tends to remain stable regardless of write throughput, but it can degrade if vacuum falls behind or bloat accumulates.

The trade-off is storage. Dead tuple versions accumulate until vacuum reclaims them. That maintenance overhead—bloat, autovacuum tuning, the occasional VACUUM FULL—is the only real cost of MVCC. The rest of this article shows why, for read-dominated systems, that cost is worth paying and how to keep it bounded.

Readers never block writers: the snapshot mechanics

PostgreSQL ships with Read Committed as the default isolation level. When a transaction runs at this level, every SELECT (without FOR UPDATE/SHARE) takes a snapshot at query start. That snapshot contains only rows committed before the query began; it never sees uncommitted data or changes committed by concurrent transactions during the query's execution.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM accounts WHERE id = 42;

The snapshot is per-query, not per-transaction. Two successive SELECT commands in the same transaction can return different results if other transactions commit between them. This is the mechanism that lets readers proceed without ever blocking on writers.

Writers behave symmetrically: UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE search for target rows using a snapshot taken at command start. They lock only the specific rows they modify, not the entire table or index range.

Reader takes snapshot at T1, writer commits new version at T2, reader's next query at T3 sees the committed change without ever waiting for a lock.

Snapshot overhead is low—essentially a transaction ID threshold—so read throughput can scale well with cores, though actual scaling depends on many factors (I/O, cache hit rate, query complexity, lock contention on hot rows). Under the default isolation level, read-heavy workloads see minimal contention because readers never wait for writers.

Visibility map and index‑only scans

The visibility map (VM) is a per‑relation bitmap that tracks which heap pages contain only tuples visible to all active transactions. Each bit corresponds to one heap page; when set, it guarantees that every tuple on that page is all‑visible. This guarantee is what allows an index‑only scan to return results without ever touching the heap.

Vacuum sets all‑visible bits; index‑only scans consult the visibility map and satisfy queries from the index alone.

Because the map is conservative—if a bit is set the condition holds, but an unset bit means nothing definite—PostgreSQL can safely skip heap fetches only when the bit is set. Indexes themselves have no visibility map, so the heap‑page flag is the sole shortcut.

EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM accounts WHERE balance > 1000;

When the planner chooses an Index Only Scan, the Buffers output will show hits on the index only (e.g., Buffers: shared hit=12) and zero heap blocks read—provided the VM bits for the relevant pages are set.

Those bits are set exclusively by vacuum and are cleared by any data‑modifying operation on the page. The VM lives in a separate fork named <filenode>_vm alongside the main relation file. If vacuum falls behind, the map becomes stale, index‑only scans degrade to regular index scans with heap fetches, and read latency rises. Keeping vacuum current is therefore not just a maintenance chore—it is the prerequisite for the read‑path optimization that makes MVCC fast for read‑heavy workloads.

The vacuum cost: bloat, autovacuum, and VACUUM FULL

Dead tuples are the price of MVCC's non-blocking reads. Every UPDATE or DELETE leaves behind a tuple version that remains visible to in-flight transactions. Until those transactions end, the space is unreclaimable. Standard VACUUM marks dead tuples reusable for future inserts but, per the documentation, "will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained". This means bloat—the gap between logical data size and on-disk footprint—is normal and expected. Storage overhead and vacuum maintenance are the primary costs of MVCC, but they are not the only ones: the mechanism also incurs CPU overhead for visibility checks on every read and requires monitoring for transaction ID wraparound.

The autovacuum daemon handles this continuously. It "will never issue VACUUM FULL" and instead "maintain steady-state usage of disk space: each table occupies space equivalent to its minimum size plus however much space gets used up between vacuum runs". Standard VACUUM runs concurrently with production traffic: "SELECT, INSERT, UPDATE, and DELETE will continue to function normally, though you will not be able to modify the definition of a table with commands such as ALTER TABLE while it is being vacuumed".

psql -c "VACUUM (VERBOSE, ANALYZE) accounts;"

VACUUM FULL is a different beast. It "actively compacts tables by writing a complete new version of the table file with no dead space", but it "requires an ACCESS EXCLUSIVE lock on the table it is working on, and therefore cannot be done in parallel with other use of the table". It also demands extra disk space for the rewrite and can take hours on large tables. Treat it as a last resort—scheduled maintenance windows only—after autovacuum tuning has failed to control bloat.

Tuning autovacuum for steady state

Autovacuum runs in the background, but its default thresholds assume a modest write rate. On read‑heavy systems with bursty updates, the default scale factors let dead tuples accumulate until the next vacuum cycle, inflating table size and degrading index‑only scans. Two knobs move the needle: shared_buffers (so vacuum can keep more pages in memory) and the autovacuum scale factors (so vacuum triggers earlier).

shared_buffers defaults to 128 MB. On a dedicated server with 1 GB or more RAM, a reasonable starting value is 25 % of system memory; allocating more than 40 % is unlikely to improve performance because PostgreSQL also relies on the operating system cache. The setting is global and requires a restart.

For autovacuum, lower the scale factors so vacuum and analyze fire after a smaller fraction of rows change. The defaults (0.2 for vacuum, 0.1 for analyze) work for light write loads; read‑heavy workloads with occasional spikes often benefit from starting points around 0.05 and 0.02 respectively. Pair these with autovacuum_vacuum_cost_limit raised to 2000–4000 only if I/O headroom exists—monitor iowait and pg_stat_progress_vacuum while increasing incrementally; setting it too high can starve other backend processes of I/O bandwidth. Treat these numbers as initial values—validate them against pg_stat_progress_vacuum and pg_stat_user_tables for your specific workload.

Parameter	Default	Tuned for read‑heavy steady state (starting points)
`shared_buffers`	128 MB	25 % of RAM (≤40 %)
`autovacuum_vacuum_scale_factor`	0.2	0.05
`autovacuum_analyze_scale_factor`	0.1	0.02
`autovacuum_vacuum_cost_limit`	200	2000–4000

# postgresql.conf snippet
shared_buffers: '4GB'                 # example for 16 GB host
autovacuum_vacuum_scale_factor: 0.05
autovacuum_analyze_scale_factor: 0.02
autovacuum_vacuum_cost_limit: 3000

Monitor pg_stat_progress_vacuum and pg_stat_user_tables.n_dead_tup to verify dead‑tuple counts stay low between cycles. If bloat still grows, consider per‑table autovacuum_vacuum_scale_factor overrides via ALTER TABLE … SET (autovacuum_vacuum_scale_factor = 0.01).

When row‑level locking can still win

Row-level locking wins when write contention is extreme and sustained—think high-frequency counter updates on a single hot row, or long-running transactions that pin old snapshots and prevent vacuum from reclaiming dead tuples. In those cases MVCC's version chains grow unbounded, index-only scans degrade because the visibility map stays dirty, and every new writer pays the cost of traversing or cleaning up the chain. The lock-based alternative serializes writers cleanly and avoids version bloat entirely.

That serialization has a cost, though: row-level locking forces readers to wait for writers (and writers to wait for readers), introducing reader‑writer contention that reduces read throughput and increases latency. For read‑heavy workloads where reads dominate, this contention is precisely what MVCC avoids.

That much is true. If your workload is a stream of UPDATE counter SET n = n + 1 on one row, MVCC creates a new tuple version per statement and vacuum must chase each one. HOT (Heap-Only Tuple) updates can alleviate version chaining when the updated column is not indexed and the page has enough free space (governed by fillfactor), but a counter column is often indexed, limiting this benefit. Standard VACUUM can run alongside reads and writes, but it cannot keep up with that churn rate, and VACUUM FULL—the only way to physically compact the table—requires an ACCESS EXCLUSIVE lock that blocks all access.

But read-heavy workloads don't look like that. By definition, reads dominate; the hot rows are reference data, not counters. Long-running transactions are rare because analytics queries run against replicas or materialized views, not the primary. Write bursts are short and spread across many rows, so version chains stay short and vacuum catches up during quiet periods. The overhead that hurts in write-heavy corners is simply not the steady state for the workloads this article addresses.

MVCC wins for read‑heavy workloads if you manage vacuum

MVCC wins for read-heavy workloads because non-blocking reads are the default, not a tuning achievement. The trade-off—storage overhead and vacuum maintenance—is manageable when reads dominate. Apply this checklist:

Monitor bloat continuously. Track pgstattuple or pg_freespacemap metrics; alert when dead-tuple ratios climb on hot tables.
Tune autovacuum aggressively. Lower autovacuum_vacuum_scale_factor to 0.05–0.1, raise autovacuum_max_workers, and set autovacuum_vacuum_cost_limit high enough to keep pace with write bursts.
Design for index-only scans. Keep the visibility map current (see #2) and include frequently selected columns in indexes so the executor skips heap fetches entirely.

If you run read-heavy on the primary and accept these three operational habits, MVCC delivers higher throughput and simpler application logic than any locking-based alternative. The vacuum tax is real; the blocking tax is avoidable. Choose the one you can automate.