Worth twenty minutes up front.

the options#

Auto-increment integer. Compact, fast, perfect index locality, human-readable in logs.

The problems are real. It leaks volume — /orders/48213 tells a competitor how many orders you have taken. It requires a round trip to the database to learn the ID, which blocks client-side generation and batching. And it makes merging data from two systems a genuine ordeal, because both start at 1.

UUIDv4. Random, globally unique, generatable anywhere without coordination, leaks nothing.

The cost is index behaviour. Random values scatter inserts across the entire B-tree, which destroys cache locality, inflates the index, and causes page splits on every insert. On a large, write-heavy table this is a genuine and measurable problem, not a theoretical one.

UUIDv7. Time-ordered UUID: a millisecond timestamp prefix, then randomness. Keeps global uniqueness and client-side generation, restores insert locality because new rows land at the end of the index.

This is the default I would now recommend for most new systems. It fixes the one serious problem with v4 while keeping everything that made v4 attractive. Postgres has uuidv7() built in; most languages have a library.

The trade: it leaks creation time. Usually fine, occasionally not.

ULID / KSUID and friends. Same idea as v7 — sortable, time-prefixed — with a more compact text encoding. Fine choices. UUIDv7 has the advantage of being a standard with native database support, which matters more than encoding length.

Natural keys. Email, ISBN, SKU. Almost always a mistake as a primary key, because "naturally unique and never changes" turns out to be false: people change email addresses, and standards get revised. Use them as unique constraints, not as the identifier everything else points at.

the two-identifier pattern#

Frequently the right answer is not to choose:

• Internal key: bigint, auto-increment. Used for foreign keys and joins. Compact, fast, never exposed.
• External ID: UUIDv7 or a prefixed string. Used in URLs, APIs, logs, support conversations. Unique index on it.

You get join performance and index locality internally, and no information leakage externally. The cost is one extra column and remembering which is which.

prefix your external IDs#

If you expose identifiers, prefix them by type:

cus_01J9F3K2M4N5P6Q7R8S9T0V1W2
ord_01J9F3K8X1Y2Z3A4B5C6D7E8F9

This is a small thing with an outsized payoff:

• A support engineer can tell what an ID refers to without asking.
• Passing a customer ID where an order ID belongs becomes detectable, and can be rejected at the API boundary rather than producing a confusing not-found.
• Logs and error reports become self-describing.
• You can rotate the encoding later without ambiguity.

Several well-run APIs do this and it is consistently one of the things developers say they appreciate about them.

the practical rules#

Never expose auto-increment integers publicly. Volume leakage plus trivial enumeration.

Do not use UUIDv4 as a clustered primary key on a table that will get large and write-heavy. If you already have, v7 for new tables and consider whether the old one needs a migration — usually it does not, but measure the index bloat before deciding.

Store UUIDs as a native uuid type, not as text. Sixteen bytes versus thirty-six, and correct comparison semantics.

Decide the case and format once, write it down, and validate at the boundary. Half your system accepting hyphenated lowercase and the other half accepting bare uppercase is a bug that surfaces years later in one integration.

Never reuse an ID. Ever. Deleted means gone; the identifier is retired with it. Reuse turns a stale reference from a clean not-found into silent corruption pointing at the wrong record.

the trap#

Five years of support sounds generous, so the upgrade never makes the roadmap. Then one of two things happens:

You reach end of life and have to do four or five major versions at once, under time pressure, with an accumulated set of behaviour changes nobody has read about.

You quietly lose years of free improvement. Postgres releases carry substantial planner, vacuum and I/O work every single year. A database three versions behind is slower than it needs to be, on hardware you are already paying for.

The teams that find upgrades painful are always the ones who defer them. The teams that upgrade every year find it boring, because one version of behaviour change is a changelog and four versions is a project.

what to actually do#

Read one document: the release notes' incompatibilities section. Not the feature list — the "Migration to Version N" section at the top. It is usually under a page and it is the only part that can hurt you.

Test on a copy of production, at production size. Restore a real dump, run your application's test suite against it, and run your slowest queries. Planner changes are the main source of surprise, and they only show up with real statistics and real data volume.

Check your extensions first. This is the most common blocker. Every extension must have a build for the target version, and if you depend on something niche, verify before you plan anything else.

Use logical replication for anything where downtime matters. Replicate old to new, let it catch up, cut over. pg_upgrade --link is fast and requires a maintenance window; logical replication is more setup and needs seconds.

Run ANALYZE immediately after. Modern pg_upgrade carries statistics across, which removed the classic post-upgrade outage where a statistics-free database planned everything terribly. Verify it happened rather than assuming.

the operational habit worth adopting#

Put it in the calendar: evaluate in October, upgrade in the first quarter.

That gives the release a few point versions to settle, keeps you at most one version behind, and turns the whole thing into a scheduled chore rather than an emergency. The same pattern works for any dependency with an annual cadence, and the calendar entry is what makes it happen — nobody ever gets around to it otherwise.

the version everyone is actually on#

Run this and find out where you really are:

SELECT version();
SELECT name, setting FROM pg_settings WHERE name IN
  ('server_version_num', 'shared_buffers', 'effective_cache_size',
   'work_mem', 'max_connections', 'effective_io_concurrency');

While you are there: max_connections is almost certainly too high and effective_io_concurrency is almost certainly too low for SSD storage. Both defaults date from an era of different hardware, and both are one-line changes with measurable effects.

The upgrade is the boring part. The settings nobody has revisited since the database was provisioned are usually the bigger win.

why connections are expensive#

In Postgres specifically, each connection is a separate operating system process with its own memory. A few megabytes of baseline, plus work memory for sorting and hashing, plus its share of shared buffer access.

Four hundred connections means four hundred processes. The scheduler is context switching between them, they are contending for the same locks and buffers, and the memory is largely wasted because most of them are idle.

The counterintuitive result, which has been measured many times: throughput frequently goes down as connection count goes up, past a fairly low threshold.

More connections does not mean more concurrency. It means more contention.

the actual number#

A widely used starting formula:

connections = (core_count × 2) + effective_spindle_count

For an 8-core machine with SSD storage, that is somewhere around 16 to 20.

That number seems shockingly low to people running pools of 100 or more. It is correct, and the reasoning is straightforward: a query is either using CPU or waiting on I/O. You need enough connections to keep the cores busy and to have some work queued behind I/O waits. Past that, additional connections are queued at the database instead of queued in your pool, and queueing at the database is worse because it consumes resources.

Test it. Take your load test, run it at pool sizes of 10, 20, 40, 80, and 160, and plot throughput and p99 latency. The curve rises, flattens, and then degrades. Most people are on the degrading side and have never looked.

the pooler layers#

Three, and they do different things.

Application-side pool. In-process, reuses connections across requests. Every ORM and database driver has one. This is the minimum.

External pooler — PgBouncer, pgcat, or a cloud provider's equivalent. Sits between your application and the database and multiplexes many client connections onto few server connections.

This is what you need when you have many application instances. Twenty instances with a pool of 20 each is 400 connections to the database, even if each instance is mostly idle. A pooler collapses that to the number the database actually wants.

The database's own limit. max_connections. Set it lower than you think — it is a safety valve, and setting it high does not make the database faster, it makes the failure mode worse.

pooling modes, and the one that bites#

External poolers have modes and choosing wrong causes subtle correctness bugs.

Session pooling. A client gets a server connection for the duration of its session. Safe, and provides little multiplexing benefit.

Transaction pooling. A server connection is assigned per transaction and returned after commit. This is where the big multiplexing win is, and it is what most people want.

The catch: anything that depends on session state breaks.

• Prepared statements (unless the pooler supports them explicitly, which newer ones do)
• SET at the session level
• Session-level advisory locks
• LISTEN/NOTIFY
• Temporary tables
• WITH HOLD cursors

If your ORM uses server-side prepared statements by default — many do — you must either disable them or use a pooler that handles them. This is the single most common transaction-pooling problem and it manifests as intermittent errors under load, which is a miserable thing to debug.

Statement pooling. A connection per statement. Maximum multiplexing, breaks multi-statement transactions. Almost never what you want.

the settings that matter#

Beyond size:

Connection timeout. How long a request waits for a connection before failing. This should be short — a few seconds. A request waiting thirty seconds for a connection has already been abandoned by its caller.

Idle timeout. Return connections to the database when not in use. Important with many application instances.

Max lifetime. Recycle connections periodically. This handles the case where a database failover happens and your pool is holding connections to the old primary — without a max lifetime, some pools hold those indefinitely.

Validation. Test a connection before handing it out, or handle the failure on first use. Something has to deal with connections that died while idle.

the diagnostic#

SELECT state, count(*), max(now() - state_change) AS longest
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state;

What you are looking for:

• Many idle in transaction — the worst state. A transaction is open and doing nothing, holding locks and preventing vacuum. This is an application bug: a transaction opened and not committed, usually because of an early return or an exception path.
• Many idle — pool is oversized. Harmless but wasteful.
• Many active with long durations — queries are slow; the pool is not the problem.

idle in transaction is the one to alert on. It is always a bug and it causes outages that look like database problems and are application problems.

the summary#

Size your pool from a load test, not from a blog post. It is smaller than you think. Use an external pooler in transaction mode if you have many application instances, and check your prepared statement behavior when you do.

Here is the pattern that works, and the specific things that go wrong.

the locks that kill you#

The failure mode is almost always a lock held longer than expected, blocking every query behind it, until connections exhaust and the application falls over.

In Postgres, these are safe (metadata-only, fast):

• ADD COLUMN with no default, or with a non-volatile default (since PG 11).
• DROP COLUMN (marks it dead, does not rewrite).
• ADD CONSTRAINT ... NOT VALID, then VALIDATE CONSTRAINT separately.
• CREATE INDEX CONCURRENTLY.
• Renaming things.

These rewrite the table and hold an exclusive lock for the duration:

• ALTER COLUMN TYPE (most of the time).
• ADD COLUMN with a volatile default.
• SET NOT NULL directly (use a CHECK constraint validated separately, then convert).

The one everyone hits: CREATE INDEX without CONCURRENTLY blocks writes for the entire build. On a large table that is minutes to hours. CONCURRENTLY takes longer and does not block, and it can fail — leaving an invalid index you must drop and retry.

The one nobody expects: even a fast ALTER TABLE must acquire an exclusive lock, and it will queue behind any long-running transaction. Then everything queues behind it. A migration that takes 5 ms can cause a 10-minute outage if a reporting query is holding a lock.

Set lock_timeout before every DDL statement:

SET lock_timeout = '3s';
ALTER TABLE orders ADD COLUMN region text;

If it cannot get the lock in three seconds, it fails and you retry, rather than queueing behind something and taking the site down. This one line prevents a large share of migration incidents.

expand and contract, always#

Never change a column in place. Four deploys:

1. Expand. Add the new column, nullable. Deploy. Old code ignores it.

2. Backfill and dual-write. Application writes both columns. Backfill existing rows in batches. Deploy.

-- in a loop, with a pause between batches
UPDATE orders SET region = derive_region(country)
WHERE region IS NULL AND id BETWEEN $1 AND $2;

Batch size in the thousands. Sleep between batches. Monitor replication lag and back off if it grows — a backfill that outruns replication is how you take down your read replicas.

3. Switch reads. Read from the new column. Deploy. Still fully reversible, the old column is intact and still being written.

4. Contract. Stop writing the old column, deploy, and drop it days later.

Four deploys instead of one. Every intermediate state works with both the old and new code, so any deploy can be rolled back independently.

the backfill rules#

Idempotent. It will be interrupted. It must be safe to re-run.

Resumable. Track progress. A backfill that starts over from the beginning after a failure will never finish on a large table.

Rate limited. Not "as fast as possible." A backfill competing with production traffic for I/O is a self-inflicted incident. Watch replication lag, watch p99 latency, and throttle.

Observable. Log progress. "Backfilled 4.2M of 180M rows, ETA 6h" lets someone make a decision. Silence does not.

Kill-switchable. You need to be able to stop it immediately without deploying. A flag it checks between batches.

testing it#

On a copy of production, at production size. A migration tested on a 10,000-row development database tells you the syntax is right and nothing about the runtime.

With concurrent load. Locks only matter under contention. Run the migration against a restored copy while replaying production traffic.

With the rollback. Actually run it. A rollback plan that has never been executed is a hypothesis.

the checklist#

Before any production migration on a large table:

• [ ] Tested on production-sized data with concurrent load
• [ ] lock_timeout set on every DDL statement
• [ ] Expand-contract, not in-place
• [ ] Backfill is batched, rate-limited, resumable, and killable
• [ ] Rollback tested
• [ ] Replication lag monitored with a threshold to pause at
• [ ] Someone is watching, with the kill switch, for the duration
• [ ] Not on a Friday

That last one is not superstition. It is that the people who understand the change should be available for the two days after it, and on Friday they are not.

This is not a controversial position anymore, which is itself notable, because a decade ago it was.

what it absorbed#

The reason the argument ended is that Postgres kept adding the things people left it for:

JSON. jsonb with indexing, operators, and path queries. The document database use case — schemaless-ish data with nested structure — is handled well enough that the specialized option is rarely worth a second system.

Full-text search. Built in, with ranking, stemming, and index support. Not as good as a dedicated search engine at large scale or with complex relevance requirements. Good enough for the search box on most applications, and one fewer system to operate.

Vector search. pgvector with HNSW indexing. Again: not the best available at extreme scale, and entirely adequate for most retrieval workloads, with the enormous advantage that your vectors sit next to your metadata and you can filter and join in one query.

That last point is underrated. A dedicated vector database that cannot join to your relational data means you do the join in application code, badly.

Time series. Partitioning, BRIN indexes, and extensions cover a lot of the use case.

Geospatial. PostGIS remains the best geospatial implementation in any database, period.

Queues. SELECT ... FOR UPDATE SKIP LOCKED gives you a correct, transactional job queue in about twenty lines. For anything under high-thousands of jobs per second — which is most systems — you do not need a dedicated queue, and the transactional property (enqueue in the same transaction as the state change) removes an entire class of consistency bug.

the operational reality#

One system to operate. Every additional datastore is a backup strategy, a monitoring setup, an upgrade path, a failure mode, an on-call runbook, and a set of consistency questions between it and everything else.

The cost of a second datastore is not the license. It is the permanent operational surface, and teams consistently underestimate it by a large factor.

Transactions across your data. If your users and your documents and your embeddings are in one database, a change to all three is one transaction. Split across three systems, it is a distributed consistency problem you now own.

when it is genuinely wrong#

Being honest about this matters, because "just use Postgres" as a reflex is the same failure mode as any other reflex.

Extreme write throughput on a single logical dataset. Postgres scales writes vertically, well, up to a point. Past that point you need sharding, and Postgres's sharding story is real but less mature than systems designed for it from the start. If you genuinely need millions of writes per second, look elsewhere.

Analytical queries over very large datasets. Postgres is a row store. Scanning a billion rows to compute an aggregate is what column stores are for, and the difference is orders of magnitude. Use a column store — several integrate cleanly with Postgres.

Global multi-region with low write latency everywhere. Postgres replication is primary-based. If you need writes accepted in multiple regions with low latency, that is a distributed database problem and Postgres is not one.

Extremely high-volume caching. Redis exists and is better at being a cache. This is a legitimate second system.

Embedded / on-device. SQLite. Different problem, different answer.

the thing to actually do#

Start with Postgres. Put everything in it. Measure.

When something is genuinely the bottleneck — and you will know, because you will have the metrics — extract that one thing to a specialized system with a clear reason.

That order matters. Teams that start with five specialized systems on the theory that they will need them end up operating five systems for a workload one would have handled, and the complexity is permanent.

the version note#

Whatever you are running, be less than two major versions behind. Postgres's release quality is high, the upgrades are usually boring, and the performance improvements between versions are substantial and free.

The people who have bad Postgres upgrade experiences are the ones who skipped four versions and tried to do it in one jump during an outage.

The database schema is largely the same, with accretions.

That asymmetry is the most underappreciated fact in software architecture, and it should change how you allocate design effort.

why schemas are sticky#

Data outlives code. You can rewrite a service over a weekend. You cannot rewrite ten years of production data.

Migrations are risky and get riskier with volume. A schema change on a table with a hundred rows is instant. On a table with two billion rows it is a project with a rollback plan and a maintenance window you cannot get.

Everything couples to it. Reports, exports, downstream consumers, that one analytics job nobody owns, the integration a customer built against your read replica five years ago.

Bad shapes calcify into application logic. If a column means two things depending on another column, every piece of code that touches it encodes that rule. Fixing the schema means fixing all of them, and by then nobody knows where they all are.

the decisions that are expensive to reverse#

Identity. Integer, UUID, or something else. Integers are compact and leak information — an incrementing ID tells competitors your order volume. Random UUIDs destroy index locality on insert. UUIDv7 is time-ordered and mostly solves that.

Pick early, because changing a primary key type across a live system with foreign keys is one of the genuinely hardest migrations there is.

Cardinality. "A user has one address" is a decision you will regret. Almost every one-to-one relationship eventually becomes one-to-many: one email, one phone, one payment method, one team.

The cost of modeling it as one-to-many from the start is a join. The cost of changing it later is a migration plus every query plus every piece of application logic that assumed singularity.

Nullability. A nullable column means every consumer must handle null forever. Make columns NOT NULL with a default unless the absence of a value is genuinely meaningful — and if it is, ask whether "unknown" and "not applicable" are the same thing, because they usually are not and you have just conflated them.

Enumerated values in the schema versus a lookup table. A native enum type is fast and adding a value is a migration. A lookup table is flexible and costs a join. For a set that changes rarely (order status), enum. For a set that business users will want to edit (categories), table.

Soft delete. deleted_at IS NULL on every query, forever, and one place that forgets it is a data leak. Sometimes required by regulation. Often adopted by default without thinking, and then it is permanent.

If you need it, consider a separate archive table instead — moving the row rather than flagging it. That keeps the hot table clean and makes the "forgot the filter" bug impossible.

Timestamps. Always store UTC. Always store the timezone separately if local time matters semantically ("the meeting is at 9 a.m. in Berlin" is not the same fact as an instant). Always timestamptz, never timestamp, in Postgres.

the practices that make it survivable#

Constraints in the database, not just the application. A CHECK constraint, a foreign key, a UNIQUE index. Application-level validation is bypassed by the migration script, the admin tool, the data fix someone ran by hand at 2 a.m., and the second service somebody wrote.

The database is the only place a rule is actually enforced.

Expand-contract for every change. Add nullable, backfill, dual-write, switch reads, remove old. Four deploys, every intermediate state reversible. This is not optional discipline; it is the only way to change a schema without a maintenance window.

Never reuse a column for a new meaning. The old data is still in there with the old meaning. Add a column.

Name things fully. status is not a name. subscription_status is. Abbreviations that were obvious to you in 2019 are not obvious to anyone in 2029.

Comment the schema. Postgres has COMMENT ON COLUMN. Almost nobody uses it. The place to record what a column means is on the column.

the exercise worth doing#

Take your main table. For each column, ask:

1. What does it mean, precisely?
2. Can it be null, and what does null mean?
3. Who writes it, and is there more than one writer?
4. What enforces its validity?
5. If we needed two of these, what would break?

You will find at least one column that means different things in different rows. That column is going to be the source of an incident, eventually, and it was a design decision someone made in ten minutes six years ago.

Spend the extra day on the schema. It is the only artifact you are going to be living with.

That is a bigger change to web application architecture than it first appears.

what it replaces#

The default architecture for a data-heavy web application is: the browser holds almost nothing, every view is a request, and the server does the querying.

That produces:

• A round trip for every interaction, at whatever latency the user's network has.
• An API endpoint per view, because generic endpoints are inefficient and specific ones proliferate.
• A loading state for everything, and the accompanying skeleton screens.
• Nothing works offline.
• Server cost proportional to reads, which are the overwhelming majority of traffic.

If the client has the data, all of that changes. A view is a query against local storage. It returns in a millisecond. There is no loading state because there is no load.

the practical setup#

import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm';

const db = await sqlite3Worker1Promiser.v2();
await db('open', { filename: 'file:app.sqlite3?vfs=opfs' });

await db('exec', {
  sql: `select id, title, updated_at from notes
        where project_id = ? order by updated_at desc limit 50`,
  bind: [projectId],
  rowMode: 'object',
});

Run it in a worker. The synchronous access handle API — which is what makes durable storage fast — is only available off the main thread, and you did not want to block the main thread with database I/O anyway.

the design questions this forces#

How much data does a client get? All of it is fine for a personal notes app. It is catastrophic for a system where a user may see a tiny fraction of a large corpus, and it is a security problem if the partition is not enforced server-side.

The general answer is a working set: the user's own data, recently accessed shared data, and lazy loading for the rest. Deciding what is in the working set is the hard design problem and it is application-specific.

How does it sync? This is where the complexity lives. Options range from "pull changes since a watermark and last-write-wins" to full CRDT-based merge. The right answer depends on whether concurrent edits to the same record are possible and what should happen when they are.

Start with the simplest thing that is correct for your data. Most applications have very little genuine concurrent editing and do not need CRDTs.

What about permissions? The client has the data, so the client can read the data, so anything the client should not see must not be synced. Your sync layer has to understand your authorization model.

This is the constraint that rules out local-first for a lot of enterprise applications, and pretending otherwise is how you build a data leak.

What about migrations? Users have databases on their machines in old schemas. You need versioned migrations that run on the client, and you need to handle a client that has been offline across four versions.

Build this on day one. It is very painful to retrofit.

what it is genuinely good for#

• Applications with a personal working set: notes, tasks, editors, trackers, design tools, dashboards over a user's own data.
• Anything where the user expects instant interaction.
• Anything that should work on a plane.
• Anything where read traffic dominates and server costs scale with it.

what it is not good for#

• Large shared datasets with narrow per-user views.
• Anything requiring server-authoritative state.
• Anything with fine-grained dynamic permissions.
• Regulatory environments where data on client devices is restricted.

the performance note that surprises people#

For a dataset that fits — and "fits" is generous, tens of megabytes is unremarkable — local SQL queries are faster than a network request by roughly three orders of magnitude.

That is not an optimization. It is a different category of user experience, and users notice it immediately even if they cannot say why.

The application that responds instantly to every action feels like a tool. The one with a spinner on every click feels like a website. That distinction is worth more than most features.

the pitch#

Data lives on the user's device. The application reads and writes locally, so every interaction is instant and works offline. Changes sync to other devices and other users in the background, merging automatically.

The properties you get:

• No loading spinners. Reads are local. The interaction latency is the render time.
• Offline works. Not degraded — fully functional.
• The user owns their data, in a file, on their machine.
• The server is a relay, not the source of truth, which makes it much simpler and much cheaper.

The properties you give up are the interesting part.

what actually got solved#

Conflict resolution. CRDTs — conflict-free replicated data types — let two devices edit the same document offline and merge deterministically without a central arbiter. The theory is old. What is new is that the implementations got fast enough and small enough to use.

The specific thing that changed: document sizes. Early CRDT implementations carried enormous metadata overhead — a text document could be ten times its content in tombstones and identifiers. Modern implementations use run-length encoding and columnar formats that bring the overhead down to something reasonable, and they can compact history.

Sync engines became a category. You no longer write the sync layer. Several production-grade options exist, some open source, some hosted, all with the mundane parts — auth, presence, storage, reconnection — handled.

Local databases in the browser. SQLite compiled to WebAssembly with a persistent backing store means the browser can host a real relational database with real queries. That removes the "but I need to query it" objection that killed a lot of earlier local-first attempts.

what is still hard#

Authorization. This is the big one and it does not have a clean answer.

In a server-authoritative system, permission checks happen in one place. In a local-first system, the client has the data — so either you sync only what the user may see (which requires the server to understand your permission model and partition accordingly), or you encrypt per-scope and manage keys.

Both are real work. Anything with fine-grained, dynamic, row-level permissions is a poor fit and you should be honest about that before you start.

Schema migration. Your users have data on their devices in an old schema and some of them will not open the app for eight months. You need migrations that run locally, that are forward and backward compatible, and that handle a client syncing after skipping four versions.

This is solvable and it is a discipline you must adopt from day one. Retrofitting it is very painful.

Server-side logic. Anything that must be authoritative — payment, inventory decrement, rate limiting, anything where the user must not be able to lie — still needs a server. Local-first is not "no backend." It is "the backend is smaller and does less."

History size. CRDTs accumulate operation history. For a long-lived document with many edits, that grows. Compaction helps and it has consequences for concurrent editing across the compaction boundary.

where it fits#

Excellent fit: note-taking, editors, design tools, project trackers, single-user or small-team collaborative documents, anything where a user has a personal working set and expects it to be fast.

Poor fit: anything with a large shared dataset the user only sees a slice of, anything requiring server-authoritative state, anything with complex dynamic permissions, anything regulated in a way that prohibits data on client devices.

Mixed: most business applications, where some of the data is personal working state that should be local and some is shared authoritative state that should not be. The hybrid is more work than either pure approach and is usually correct.

the reason to care#

The default web application architecture — every interaction is a network round trip to a server that queries a database — produces software that is slower today than desktop software was in 1998, on hardware that is thousands of times faster.

Everyone has normalized this. Users have not; they just do not have a word for why the app feels bad.

Local-first is the architecture that fixes it, and it is now practical enough that "we cannot do that" has stopped being true.

what it does#

Historically Postgres read from disk synchronously: a backend process issues a read, blocks, gets the page, continues. On a spinning disk that was fine — the disk was the bottleneck and you could not do better. On modern NVMe, where the device can service many requests in parallel and a single-threaded synchronous reader leaves most of the device idle, it wasted a great deal of available throughput.

Postgres 18 adds an I/O method abstraction:

io_method = sync          # the old behavior
io_method = worker        # dedicated I/O worker processes (default)
io_method = io_uring      # Linux io_uring, if built with support

Sequential scans, bitmap heap scans, and vacuum use it. Other paths do not yet; this is an incremental rollout across releases.

what people are seeing#

The consistent pattern from the reports I trust:

Large sequential scans on fast NVMe: substantial improvement. Analytical queries scanning a large table are the clearest win. This is exactly what you would predict — the workload was read-parallel and the code was not.

Vacuum: meaningfully faster. This matters more than it sounds. Vacuum being slow is the root of a large class of Postgres operational problems, and anything that makes it finish sooner reduces bloat pressure.

OLTP with a good cache hit rate: little change. If your working set is in shared buffers, you were not doing I/O, so making I/O faster does nothing. Most transactional workloads are in this category and should not expect much.

Cloud block storage: mixed. Network-attached storage has enough latency and enough of its own queueing that the gains are smaller and less predictable than on local NVMe. Test rather than assume.

the tuning notes#

Two settings matter and the defaults are conservative:

io_combine_limit = 128kB        # how much adjacent I/O to merge into one request
effective_io_concurrency = 16   # how many concurrent reads to issue

effective_io_concurrency has historically been set based on spindle count, which is meaningless on NVMe. For a modern SSD, values well above the old defaults are appropriate. Measure — the curve flattens and then degrades, and where it turns depends on your device.

If you are on Linux with a recent kernel and can build with io_uring support, it generally outperforms the worker method by a modest margin. The worker method is the safe default and it is genuinely good.

the other things in 18 worth knowing#

Skip scan for B-tree indexes. A multi-column index on (a, b) can now be used for a query filtering only on b, when a has low cardinality. This eliminates a category of redundant index that people have been maintaining for years.

uuidv7() built in. Time-ordered UUIDs, natively. If you use UUIDs as primary keys, v7 dramatically improves index locality compared to v4, which scatters inserts across the whole B-tree. This is a real performance issue that a lot of applications have and do not know about.

OAuth authentication support, which matters for anyone trying to eliminate static database passwords.

Faster major-version upgrades, with statistics preserved across pg_upgrade. Previously you finished an upgrade with no statistics and a database that planned terribly until you ran ANALYZE across everything. That was a genuine outage risk and it is fixed.

should you upgrade#

Yes, on the normal schedule — after a point release or two, with a tested rollback, having read the release notes for the incompatibilities.

The async I/O is the headline and for most transactional workloads the statistics preservation on upgrade and uuidv7() will matter more day to day.

As always with Postgres: the release is well-tested, the migration is usually boring, and the people who get burned are the ones who skipped four major versions and tried to do it in one jump.

And a lot of engineers still classify it as "the thing you use before you get a real database."

when it is the right choice#

Read-heavy workloads on a single machine. SQLite has no network hop, no connection pool, no serialization. A query is a function call into memory-mapped pages. For reads it is frequently faster than Postgres on the same hardware by an order of magnitude, because the fastest network request is the one that does not happen.

Applications whose data fits on one disk. Which is most applications. A terabyte NVMe drive costs very little and holds a large amount of business data. The number of applications that genuinely need distributed storage is much smaller than the number that use it.

Anything where operational simplicity matters. No server to run, patch, monitor, back up separately, or fail over. Your backup is a file copy. Your staging environment is cp prod.db staging.db. Your local development environment is identical to production.

Edge deployment. Ship the database with the application. This is why the edge-runtime ecosystem has converged on SQLite-derived systems.

the write concurrency question#

The historical objection: SQLite serializes writes. One writer at a time.

This is true, and with WAL mode it is far less limiting than it sounds. Readers do not block writers and writers do not block readers. Only writer-versus-writer contends.

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA busy_timeout = 5000;
PRAGMA foreign_keys = ON;

Set those four. The defaults are conservative for embedded use and wrong for a server application.

A single writer on NVMe handles thousands of transactions per second if the transactions are short. The failure mode is long-running write transactions blocking others, which is a thing you should not do in any database.

Be honest about your actual write rate. Most applications that think they are write-heavy are doing a few hundred writes per second at peak, which SQLite handles without noticing.

when it is the wrong choice#

• Multiple application servers needing write access to the same data. This is the real limit. The replication ecosystem (Litestream, LiteFS, rqlite, and the various hosted variants) addresses parts of it with real trade-offs, but if you genuinely need multi-writer, use Postgres.
• Very large datasets with complex analytical queries. The query planner is good and it is not Postgres's, and you do not get parallel query execution.
• Rich types and extensions. No native JSON operators as capable as Postgres's, no PostGIS, no pgvector. There are extensions; they are not the same ecosystem.
• Fine-grained access control. SQLite's security model is filesystem permissions. If you need row-level security, you need something else.

the deployment pattern that works#

Application and database on the same machine. Vertical scaling — modern hardware is very large. WAL mode. Continuous replication to object storage for durability. Read replicas if you need geographic distribution.

This handles a genuinely enormous amount of traffic. Not every application, and far more than the conventional architecture assumes.

the actual argument#

The default architecture for a web application — separate database server, connection pooling, network round trips, replication topology, a managed service bill — solves problems that most applications do not have, and it costs complexity that every application pays.

Start with the simplest thing that could work. For a very large class of applications, that is a single machine with a file on it, and you can move later if you need to.

Most never need to. The ones that do will have revenue by then.

the notable bits#

ext4 gains support for concurrent direct I/O writes to the same file when using extent-based allocation without needing exclusive inode locking. For database workloads on ext4 this is a meaningful throughput improvement — the exclusive lock was a real serialization point on write-heavy workloads with many threads hitting one large file.

If you run Postgres or MySQL on ext4 with direct I/O, this is worth benchmarking after you upgrade.

Btrfs continues its steady improvement, including better handling of large folios. XFS got more work on its atomic write support, which is one of those capabilities that unlocks meaningful optimizations in databases that can rely on it — no more double-write buffers if the filesystem can guarantee torn-write protection.

More Rust bindings landed, including additional infrastructure for DRM drivers. The Rust-for-Linux effort continues its subsystem-by-subsystem advance.

Futex improvements for scalability under contention, which matters for any heavily threaded userspace runtime — the JVM, Go's scheduler, and every async runtime with a work-stealing thread pool ultimately bottom out here.

the thing about boring releases#

The Linux kernel ships roughly every nine to ten weeks. It has done so for two decades. Every release contains thousands of commits from over a thousand developers across hundreds of companies who mostly compete with each other.

There is no roadmap document. There is no product manager. There is a maintainer hierarchy, a merge window, a stabilization period, and a release.

It works better than almost any commercially-managed software project on earth, and the reason is worth thinking about: the process optimizes for not regressing above everything else. The famous "we do not break userspace" rule is not politeness, it is the constraint that makes an enormous decentralized project tractable. If the interface contract is inviolable, subsystems can evolve independently without coordination.

That is the actual lesson for people building large systems. Stable interfaces between components are what let you have many independent teams. Every organization that struggles with cross-team coordination is, underneath, struggling with unstable interfaces.

the maintainer question#

Worth noting alongside: the kernel has a succession problem. A meaningful number of critical subsystems are maintained by people who have been doing it for fifteen or twenty years, and the pipeline of replacements is thin.

This is true of most critical infrastructure software and it does not get attention because it is not an incident until it is. The number of load-bearing open source projects with exactly one active maintainer remains one of the scariest statistics in computing.

If your company depends on the kernel — and it does — funding maintainers is a better use of security budget than most of the things in your security budget.

Structurally this is an acquihire with an equity stake attached, arranged to avoid the antitrust review a full acquisition would trigger. It is the third such deal in a year following similar structures at other labs, and regulators have noticed the pattern.

why Scale#

Scale's business is data: labeling, annotation, evaluation, and increasingly the human expert layer that produces high-quality demonstrations for RLHF and reasoning training.

That business is unglamorous and it is a genuine bottleneck. Every frontier lab needs enormous amounts of carefully constructed training data, especially for post-training. Web scrape is free and getting exhausted. What is scarce is expert-produced reasoning traces, verified solutions, and adversarial evaluations, and Scale is the largest supplier.

Meta's Llama 4 launch underwhelmed. Their internal read, based on the reporting, was that the gap was not compute — Meta has enormous compute — but post-training quality. Buying the data layer is a direct response to that diagnosis.

the conflict of interest problem#

Scale's customers include most of Meta's competitors. Several immediately began reducing their reliance, which is the obvious response when your data vendor is half-owned by a rival.

Scale has said the business remains independent and customer data is siloed. That is probably true operationally and it does not matter, because the risk assessment is not about what Scale does, it is about what Scale could do, and no chief information security officer is going to sign off on that.

Expect a scramble toward Surge, Turing, Mercor, Invisible, and in-house annotation teams over the next two quarters.

the talent market#

This deal is one data point in the most aggressive AI talent market anyone has seen. Compensation packages for senior researchers have reached numbers that sound like typos, and the poaching is happening in public.

Two things worth noting:

The concentration is extreme. The number of people who have personally led a frontier pretraining run is in the low hundreds globally. That is a genuinely scarce input and it prices accordingly.

It is probably a bubble in the specific sense that it will correct. Talent premiums of this magnitude assume the individual contributor is the bottleneck. As tooling matures and recipes become public — and they are becoming public, fast — the premium compresses. It always has.

what it means for everyone else#

If you are not a frontier lab, the actionable read is about your data.

The scarce resource in applied AI is not model access, it is well-constructed, domain-specific evaluation and training data. Nobody can buy your production logs, your customer support transcripts, your annotated failure cases. That is the asset.

Most companies are sitting on it and not using it. Start by building an evaluation set from real failures. That is worth more than any model upgrade and it appreciates rather than depreciating.