--- title: DataMax: A Dedicated WAL Log-Store Node for... description: PolarDB adds DataMax, a dedicated node type that stores a durable copy of the write-ahead log without ever replaying it into a database. Because it skips... canonical: https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: DataMax: A Dedicated WAL Log-Store Node for Near-Synchronous Durability | daily.dev og:description: PolarDB adds DataMax, a dedicated node type that stores a durable copy of the write-ahead log without ever replaying it into a database. Because it skips... og:url: https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly og:image: https://api.daily.dev/og/posts/FF5335Nly.png og:image:alt: DataMax: A Dedicated WAL Log-Store Node for Near-Synchronous Durability og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # DataMax: A Dedicated WAL Log-Store Node for Near-Synchronous Durability **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 9 min read · 0 upvotes · 0 comments ## Summary PolarDB adds DataMax, a dedicated node type that stores a durable copy of the write-ahead log without ever replaying it into a database. Because it skips replay, it only pays for sequential log storage, not full buffer-pool and data-file costs. Placed in the same availability zone as the primary, it can be named in synchronous_standby_names so commits wait only for an intra-AZ hop while distant standbys replicate asynchronously from it. A new 'e' protocol message lets it borrow the primary's transaction epoch and WAL retention horizon, and a modified initdb lets it adopt the primary's system identifier without a full pg_basebackup. A new polar_datamax_mode setting and a promote-wait option (polar_enable_promote_wait_for_walreceive_done) round out the feature. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does PolarDB's DataMax node provide synchronous durability without the cost of a full standby? DataMax stores a durable copy of the write-ahead log and cascades it to downstream standbys, but never replays records into a database, so it avoids buffer pool and data file costs. Placed in the same availability zone as the primary, it can be named in synchronous_standby_names, letting commits wait only for an intra-AZ round trip instead of a cross-AZ one. _Teams designing low-latency synchronous replication can track architectures like this one on daily.dev._ ### How can a PostgreSQL node that runs no transactions compute a transaction-id epoch or WAL retention horizon? It borrows both from its upstream primary instead of deriving them locally. A new 'e' replication protocol message carries the primary's nextXid, epoch, last valid LSN, and last removed segment, which the receiving node records and reflects back for vacuum feedback and forwards onward to any downstream DataMax node. _Engineers debugging replication internals can follow protocol-level changes like this on daily.dev._ ### How does a PostgreSQL replica node get the same system identifier as its primary without running pg_basebackup? initdb can be given an explicit system identifier matching the upstream's, so the node presents that identity during the IDENTIFY_SYSTEM handshake without cloning the primary's control file or data. On a fresh start it requests streaming with a deliberately invalid timeline and LSN, then adopts the primary's timeline after the handshake completes. _Those building custom replication bootstrap flows can keep up with techniques like this via daily.dev._ ## Similar posts on daily.dev - [Speech at PGDay Israel 2026：Durability, Consistency, and Performance](https://daily.dev/posts/speech-at-pgday-israel-2026-durability-consistency-and-performance-yduiljbzp) · Planet PostgreSQL · 0 upvotes · 0 comments - [From Outages to Order: Netflix’s Approach to Database Resilience with WAL](https://daily.dev/posts/from-outages-to-order-netflix-s-approach-to-database-resilience-with-wal-aebzo3gxd) · InfoQ · 31 upvotes · 0 comments - [WAL \+ S3: Lakebase storage for the era of agents](https://daily.dev/posts/wal-s3-lakebase-storage-for-the-era-of-agents-4trqspanr) · Neon · 25 upvotes · 2 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"DataMax: A Dedicated WAL Log-Store Node for Near-Synchronous Durability","url":"https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly"},"datePublished":"2026-10-25T12:35:21.830Z","dateModified":"2026-10-25T12:36:01.014Z","description":"PolarDB adds DataMax, a dedicated node type that stores a durable copy of the write-ahead log without ever replaying it into a database. Because it skips...","image":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","thumbnailUrl":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql,distributed-systems","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"DataMax: A Dedicated WAL Log-Store Node for Near-Synchronous Durability"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/datamax-a-dedicated-wal-log-store-node-for-near-synchronous-durability-ff5335nly#faq","mainEntity":[{"@type":"Question","name":"How does PolarDB's DataMax node provide synchronous durability without the cost of a full standby?","acceptedAnswer":{"@type":"Answer","text":"DataMax stores a durable copy of the write-ahead log and cascades it to downstream standbys, but never replays records into a database, so it avoids buffer pool and data file costs. Placed in the same availability zone as the primary, it can be named in synchronous_standby_names, letting commits wait only for an intra-AZ round trip instead of a cross-AZ one. Teams designing low-latency synchronous replication can track architectures like this one on daily.dev."}},{"@type":"Question","name":"How can a PostgreSQL node that runs no transactions compute a transaction-id epoch or WAL retention horizon?","acceptedAnswer":{"@type":"Answer","text":"It borrows both from its upstream primary instead of deriving them locally. A new 'e' replication protocol message carries the primary's nextXid, epoch, last valid LSN, and last removed segment, which the receiving node records and reflects back for vacuum feedback and forwards onward to any downstream DataMax node. Engineers debugging replication internals can follow protocol-level changes like this on daily.dev."}},{"@type":"Question","name":"How does a PostgreSQL replica node get the same system identifier as its primary without running pg_basebackup?","acceptedAnswer":{"@type":"Answer","text":"initdb can be given an explicit system identifier matching the upstream's, so the node presents that identity during the IDENTIFY_SYSTEM handshake without cloning the primary's control file or data. On a fresh start it requests streaming with a deliberately invalid timeline and LSN, then adopts the primary's timeline after the handshake completes. Those building custom replication bootstrap flows can keep up with techniques like this via daily.dev."}}]} ```