HorizonDB: What Changes When Compute and Storage Split

PostgreSQL has earned its place because it is boring in the best way. It is reliable, familiar, extensible, and battle-tested. For most workloads, the traditional PostgreSQL architecture works extremely well.

But at cloud scale, the same design starts to show pressure.

The issue is not PostgreSQL itself. The issue is the amount of responsibility placed on the database server.

In a traditional PostgreSQL architecture, the server does a lot. It runs SQL. It manages transactions. It handles MVCC. It writes WAL. It manages dirty pages. It runs checkpoints. It performs recovery. It supports replicas. It owns the relationship between memory, logs, and database files.

That model is simple and powerful, but it also creates bottlenecks. The same compute layer responsible for serving the application is also responsible for durability work, page flushing, checkpoint I/O, recovery, and replication overhead.

HorizonDB changes that model.

The simplest way to explain it is this:

Flexible Server manages PostgreSQL better. HorizonDB changes the PostgreSQL storage architecture.

The old model: the server owns the database#

In classic PostgreSQL, when an application updates a row, PostgreSQL loads the relevant data page into memory, changes it, writes a WAL record, confirms the transaction once the WAL is durable, and later flushes the dirty data page back to disk.

That design is safe. WAL is the durable receipt. If the server crashes before the changed page is written, PostgreSQL can replay WAL and recover the committed change.

But the server is still doing both jobs: it runs the workload, and it manages the physical durability path.

That means the database server must handle WAL writes, data page writes, checkpoints, recovery, and replica coordination. As workloads grow, these background responsibilities compete with customer workload for CPU, memory, disk, and network.

That is where the pain shows up. Not always immediately. But eventually customers start seeing checkpoint spikes, write amplification, read replica lag, longer recovery paths, expensive replicas, and operational complexity around large databases.

Flexible Server separates infrastructure, not the storage contract#

Azure Database for PostgreSQL Flexible Server already separates compute and storage at the Azure platform layer. The PostgreSQL engine runs on compute, while database files live on Azure-managed storage.

That is a major managed-service improvement. Customers get HA options, backups, maintenance controls, storage durability, and operational simplicity without managing PostgreSQL on their own VMs.

But PostgreSQL still behaves like PostgreSQL. The engine still writes WAL. It still writes data pages. It still has checkpoints. It still has recovery. It still has traditional PostgreSQL replication behavior.

That is not a criticism. For many customers, that is exactly what they want. But it is important to separate the two ideas:

Flexible Server separates compute and storage at the platform level. HorizonDB separates compute and storage at the database architecture level.

That distinction matters.

HorizonDB: the log becomes the database#

HorizonDB takes a more radical position: compute should not own durable database pages.

The compute layer still runs PostgreSQL. It still handles SQL, transactions, MVCC, query execution, sessions, memory, and caching. But it does not own the durable database state.

Instead, HorizonDB uses a database-as-a-log architecture. The compute layer generates WAL. That WAL is sent to a dedicated WAL storage service. Once the WAL is durable, the transaction can be acknowledged. The page storage layer then applies the WAL and materializes the database pages.

That means compute writes the log, but storage owns the durable truth.

Traditional PostgreSQL              HorizonDB

      App                                 App
       |                                   |
  Postgres Server                  Stateless Compute
   |- SQL / MVCC                    |- SQL / MVCC
   |- WAL writes                    |- Local NVMe cache
   |- Data page writes                     |
   |- Checkpoints                  WAL Storage Service
         |                                 |
    Local / Attached Disk          Page Storage Service
                                    (Azure Blob Storage)

This is the shift. In traditional PostgreSQL, compute writes WAL and later writes data pages. In HorizonDB, compute writes WAL only. Storage turns WAL into pages.

That one change has a huge impact.

Why this matters#

The obvious benefit is lower write-path pressure on compute. If compute no longer has to flush dirty database pages to durable storage, then it can spend more of its resources running the application workload. The storage layer handles the durability-heavy work: WAL persistence, page materialization, backups, checkpoint-related responsibilities, and serving pages back to compute.

This also changes the failover model.

In traditional PostgreSQL, the primary server owns important durable state. If it fails, the system has to determine which replica is caught up, how much WAL must be replayed, whether the old primary can safely rejoin, and whether any rewind or reinitialization is required.

In HorizonDB, compute is more disposable. The durable truth is already in shared storage. A new compute replica can attach to the same WAL and data storage layer and continue from the durable log position.

That is why this architecture is not just about performance. It is also about operational simplicity.

Read replicas become lighter#

Read scale is another major change.

In traditional PostgreSQL, a read replica usually has to maintain its own copy of the database and keep up by receiving and replaying WAL. That works, but for large databases it can be expensive and slow to scale.

HorizonDB changes the replica model. A read replica is still a PostgreSQL compute node, but it shares the same storage layer. It does not need a full independent copy of the database before it can be useful. It can cache hot pages locally and fetch pages from the shared storage layer as needed.

That makes replicas lighter, faster to provision, and more practical for large read-heavy workloads. The storage layer becomes the shared source of truth. Compute replicas become query engines with local cache.

Caching still matters#

Stateless compute does not mean empty compute. This is an important point.

HorizonDB compute replicas still have memory. They still have local cache. They still have active sessions, query state, transaction state, and local NVMe SSD cache for hot pages.

The difference is that none of that is the durable database truth. If a compute node dies, the cache dies with it. That is acceptable because the durable WAL and page state live in the storage layer.

So the right way to say it is: HorizonDB compute is stateless from a durability perspective. Not: HorizonDB compute has no state at all.

That distinction keeps the architecture honest.

The customer value#

Customers do not buy architecture diagrams. They buy outcomes. The value of HorizonDB is that it targets the places where traditional PostgreSQL starts to hurt at scale:

• write latency pressure
• checkpoint I/O spikes
• replica creation time
• failover complexity
• storage duplication
• recovery time
• large database operations
• scaling compute and storage together when they should scale independently

That is the business value. It gives customers PostgreSQL compatibility while changing the underlying durability and storage model for cloud-scale workloads.

Where this lands#

Flexible Server remains the right answer for a lot of customers. It is managed PostgreSQL with control, compatibility, HA, backups, and predictable operations.

HorizonDB is for a different conversation. It is for customers asking:

• Why does failover still take this long?
• Why are replicas expensive to create and maintain?
• Why do checkpoints hurt latency?
• Why does scaling storage require thinking about compute?
• Why does a large PostgreSQL estate become harder to operate as it grows?

That is where HorizonDB has a strong story. It is not "PostgreSQL, but hosted." It is PostgreSQL with the storage layer redesigned for the cloud.

Built-in AI and developer capabilities#

The storage redesign is the foundation, but it is not the whole story. Once compute is stateless and storage is distributed, it becomes much easier to layer modern workloads on top of PostgreSQL without bolting on a separate system.

The clearest example is vector search. HorizonDB ships DiskANN indexing that Microsoft benchmarks at up to 10× faster, 4× lower cost, and 32× less memory than HNSW on 1M vectors at 1536 dimensions and 90% recall. Filter-aware search combines metadata filtering and vector search in a single operation, so you are not stitching together two query paths in the application.

On top of that, in-database AI functions are callable directly from SQL. You can generate embeddings, run generation, ranking, and extraction, and classify rows against managed embedding, chat-completion, and re-ranking models that are auto-provisioned with the service. Usage and cost flow through the same billing surface as the database.

The rest of the developer surface follows the same theme: pgvector for teams that want it, the AGE graph extension for graph workloads, Fabric mirroring for real-time analytics without an ETL pipeline, and a first-class VS Code experience so the database does not feel like a separate world from the code.

The big idea behind HorizonDB is simple: keep PostgreSQL where it matters — SQL, transactions, MVCC, compatibility, and ecosystem. Replace the old storage bottleneck underneath it, and let AI, graph, and analytics workloads ride on the same engine.

That is the architectural bet. Flexible Server gives customers a managed version of the traditional model. HorizonDB gives customers a new model: PostgreSQL compute on top of distributed WAL and page storage.

One manages the old architecture well. The other changes what PostgreSQL can become in the cloud.