La arquitectura lakehouse representa una evolución significativa en la gestión de bases de datos Postgres, separando compute y storage de manera nativa. El problema central radica en el mecanismo de Full Page Write (FPW) de Postgres, diseñado para prevenir páginas corruptras tras un crash. Cada vez que se modifica una página después de un checkpoint, Postgres debe copiar toda la página de 8KB al Write-Ahead Log (WAL), lo que puede inflar el volumen del log hasta 15 veces, convertirsese en el principal cuello de botella en aplicaciones con muchas escrituras.
La solución implementada consiste en mover la inteligencia de generación de imágenes completas del compute al storage layer, denominado image generation pushdown. En una lakebase, el compute es stateless y no depende de un directorio local; en cambio, transmite WAL a un quorum de safekeepers. al no existir páginas locales que puedan damagedarse, el propósito original del FPW desaparece. Sin embargo, desactivarlo causaría problemas de lectura al necesitar replay de una cadena infinita de deltas pequeños.
El pageserver ahora decide cuándo generar imágenes completas basándose en el número real de cambios a una página, no en el proceso de checkpoint de Postgres. Los benchmarks muestran mejoras dramáticas: en un compute de 32-vCPU, el throughput subió de 95,686 a 439,300 nuevos pedidos por minuto (4.5x+). El WAL promedio por transacción cayó de 58KB a menos de 4KB (reducción del 94%). Las latencias de lectura p99 mejoraron entre 30-50%.
En producción, un proyecto de 56 vCPU redujo la generación de WAL de 30 MB/s a 1 MB/s. Para Synced Tables, la ingestión aumentó de 17k a 62k filas por segundo (3x). La característica está activa globalmente para todas las bases de datos Lakebase Serverless y Neon desde finales de marzo, implementada sin interrupciones mediante el mecanismo XLOG_FPW_CHANGE de Postgres.