Introduction#
Conceptual foundations#
Understand the principles and strategies behind modern data analytics and EDB’s approach.
Learn about data architectures (Data Warehouse, Data Lake, Lakehouse) and foundational technologies (columnar storage, vectorized engines, and others).
Explore EDB’s vision for Postgres® analytics and how EDB leverages core technologies.
Explained: Analytics
Review in-depth explanations of EDB analytical features, design choices, and advanced topics. (Coming soon)
EDB core analytics technologies#
Learn about EDB’s analytics technologies and how they extend Postgres®.
Review the EDB Postgres® Lakehouse solution and its components for enabling analytics on object storage.
Understand how EDB solutions use Apache Iceberg to manage large analytical datasets.
Learn how EDB Postgres® interacts with Delta tables to enable reliable data lakes.
Manage data across storage tiers using EDB Postgres Distributed (PGD) and Lakehouse capabilities to optimize cost and performance.
Practical guidance and solutions#
Apply EDB’s analytics capabilities to meet your needs.
Follow learning paths for DBAs, DevOps engineers, data scientists, and application developers.
Product-specific implementations#
Review how EDB analytics concepts and technologies are implemented in EDB products.
Access documentation for analytics features in EDB Hybrid Manager. This includes HM Lakehouse clusters, using Iceberg, Delta, and tiered tables in HM, and HM-specific tutorials.
Where to start#
Start with Generic analytics concepts and EDB Postgres Lakehouse to understand core ideas.
Explore practical guidance when available.
Use product-specific documentation when working with EDB Hybrid Manager.
Postgres Lakehouse is built using a number of technologies:
PostgreSQL
Seafowl , an analytical database
Apache DataFusion , the query engine used by Seafowl
Delta Lake (and specifically delta-rs ), for implementing the storage and retrieval layer of Delta Tables
Level 100#
The most important thing to understand about Postgres Lakehouse is that it separates storage from compute. This design allows you to scale them independently, which is ideal for analytical workloads where queries can be unpredictable and spiky. You wouldn’t want to keep a machine mostly idle just to hold data on its attached hard drives. Instead, you can keep data in object storage (and also in highly compressible formats), and only provision the compute needed to query it when necessary.
On the compute side, a vectorized query engine is optimized to query Lakehouse tables but still fall back to Postgres for full compatibility.
On the storage side, Lakehouse tables are stored using highly compressible columnar storage formats optimized for analytics.
Level 200#
Here’s a slightly more comprehensive diagram of how these services fit together:
Level 300#
Here’s the more detailed, zoomed-in view of “what’s in the box”:


