Postgres as a Data Lake Is Gaining Serious Traction
A post explaining LTAP, an architecture that stores Postgres data in Parquet on S3, got real engagement. The pitch is eliminating the ETL pipeline between your transactional database and your analytical layer by unifying them in object storage. Commenters were genuinely excited, calling it a 'game changer,' though one immediately worried about S3 bandwidth bills on large queries.
This connects to the broader trend of Postgres eating the database market from multiple directions. Supabase is hiring for Multigres. ParadeDB is hiring platform engineers. The pattern is that Postgres is becoming the default substrate and people are building analytical and agent-facing layers on top of it rather than switching databases.
The bandwidth concern is real and the thread did not resolve it cleanly. For read-heavy analytical workloads, the cost math depends heavily on query patterns.
So what?
If you are architecting a new data stack, LTAP-style Parquet-on-S3 via Postgres replication is worth evaluating before you commit to a separate OLAP database. The operational complexity savings are real. But model your S3 egress costs before you deploy against a large dataset.