WarehousePG is a massively parallel processing (MPP) database originating from the open source Greenplum database. Sadly, Greenplum database is no longer open source, but EnterpriseDB is now the steward of this Apache-licensed open source project.

Why WarehousePG

There are several vendors that sell consumption-based analytical platforms that result in unexpected charges and constant vendor pressure to consume more, while WarehousePG provides predictable economics with a predictable per-core pricing model, lowering total cost of ownership (TCO) by up to 58%. 

Thanks to being open source under the Apache 2.0 license, there is no vendor lock-in.  

The technology is amazing too. The MPP architecture is well proven providing highly scalable performance. It is AI ready with native support for vector embeddings, RAG applications, in-database machine learning, streaming data ingestion, and fully integrated to your lakehouse.

Lastly, WarehousePG deploys anywhere. Unlike some cloud-only solutions, you can deploy WarehousePG on-premises, air-gapped, in public clouds, and even hybrid deployments.  

This blog post covers some of the ways you can deploy WarehousePG in AWS. 

WarehousePG on AWS: Overview

WarehousePG can be deployed anywhere, and on AWS specifically, its many services offer several flexible deployment options.

Using AWS CloudFormation, we will cover three different approaches to deploying WarehousePG in AWS. Instead of being forced into one architectural approach with other products, you can deploy with the architecture that best aligns with your requirements.

• Option 1: Built on S3 storage with storage separate from compute. Pause/resume of EC2 instances are fully supported and HA/DR relies on S3.
• Option 2: Most similar to on-premises but pause/resume not supported. Ideal when using Reserved Instances.
• Option 3: Similar to on-premises but (EBS) storage scales independently from compute  and support for pause/resume. EBS storage can slow down under heavy usage.

Deployment Options Comparison

Option 1 - Storage Separated from Compute

Many cloud-hosted analytics platforms take advantage of cloud storage like S3, to provide elastic compute, elastic storage, high availability across multiple Availability Zones within a Region, and consumption-based billing for storage. But those often come with consumption-based charges for compute that can lead to unexpected charges that blow out your budget!

WarehousePG can take advantage of Reserved Instances in AWS to have predictable costs for compute and also take advantage of S3 for storage.

Why Pick This Architecture?

This architecture is ideal for deployments that need a very low Recovery Point Objective (RPO) if an Availability Zone were to fail. 

Because the data lives in S3 across the entire Region rather than on disks tied to one AZ, there's no periodic backup-and-copy step to fall behind on. If an AZ fails, you haven't lost anything created since "the last backup"—because there is no last backup; the data was never AZ-bound to begin with. (Compare that to Options 2 and 3, which persist data in a single AZ, so recovery depends on how recently you last snapshotted elsewhere.)

Another benefit of this architecture is elastic scaling. It is possible to quickly change the number of nodes up or down (within limits). Increasing the number of nodes in this way greatly improves performance during high concurrency demands.

The billing for storage is elastic. As you consume more, you pay more. This also means if you are slowly ramping up your analytics platform, you won't be overprovisioned and paying for storage that you aren't using. 

S3 provides incredible durability with data being replicated across a minimum of 3 AZs within the Region, so for that reason, the internal mirroring that WarehousePG typically uses is omitted. This saves you on storage costs and follows the same pattern used by other analytics platforms.

This solution provides the lowest possible RPO for a Regional failure. Asynchronous S3 replication can be enabled, which can provide an RPO in the range of minutes for an AZ failure. 

The trade-off for this approach of using S3 backed storage is that load performance is negatively impacted and the initial queries can be slightly slower. 

AWS Resources

This architecture is designed to separate storage from compute. It utilizes some well-established AWS services but also some that are new.

EC2

The compute resides on EC2 instances with local, ephemeral storage attached to each VM. The R6 series instance types are memory optimized, and the R6idn have been chosen because these instances also provide very high network performance and very fast local NVMe drives.

S3 Files

AWS has long cautioned customers that S3 is not a file system, but in April of 2026 they announced that S3 is now a file system! This new feature, called "S3 Files," lets you mount S3 directly from EC2 instances and operate on the files just like any other file system.

The data persists in S3 and is available as a mount on every node in the cluster. S3 Files provides caching as part of the solution, but in addition to that caching, the local NVMe on each EC2 instance is used as a file system cache. 

Amazon Elastic File System (EFS)

EFS is a fully managed, serverless shared file storage service. EFS can be mounted by every node in the cluster, and it is available in every AZ in a Region. However, EFS is over 10x more expensive than S3 Files, so EFS is only used to store configuration and metadata files. 

All segments' files except for "base/" are stored in EFS. The base/directory contains the data files for tables and this is stored in S3 Files.

CloudFormation

CloudFormation is the native infrastructure-as-code (IaC) service in AWS. A simple template is available in our GitHub repository that builds everything needed for this architecture. It also deploys WarehousePG and configures everything for you.

Architectural Diagram

Storage is separate from compute. 

Option 2 - Local Storage

The classic massively parallel processing (MPP) architecture is "shared nothing." This means each node uses independent resources: memory, CPU, and storage. The local storage option uses the locally available NVMe storage on each node to persist the data.

Local storage provides exceptional disk performance and the size of the disk(s) are fixed. If you want to grow your storage, you will need to add more nodes. 

Why Pick This Architecture?

This architecture is ideal for deployments that mirror on-premises. Typically, when you need more storage, you need more memory and CPU to keep performance consistent. This architecture ties storage with compute resources. 

If you are considering using AWS to evaluate WarehousePG but want to deploy on-premises, then this is the architecture for you.

This architecture is also ideal for having your database available 24x7 and then utilize Reserved Instances to save money.

The trade-off for this approach is the storage is ephemeral, so you can't stop the VMs (reboots are fine) without losing data.

AWS Resources

This architecture is very similar to an on-premises deployment, and we made it very easy to get started.

EC2

The compute resides on EC2 instances with local, ephemeral storage attached to each VM. The I4i series instance types are optimized for high-performance local storage with plenty of memory.

CloudFormation

A separate template is available for this architecture so you won't have to worry about modifying the Option 1 template. The template is ready to go, plus all of the scripts.

Architectural Diagram

Classic MPP architecture in the cloud.

Option 3 - EBS Storage

This architecture is the classic MPP architecture, but instead of using local disks, it uses Elastic Block Store (EBS) in AWS. EBS provides scalable storage with many benefits over using local storage.

Why pick this architecture?

EBS provides flexible storage options with different disk types and independent scalability. You can start with the least expensive disk type and, as needed, switch to the higher performing and more expensive disk type.

You may also want to utilize disk snapshots. These snapshots can be copied to other Regions as a Disaster Recovery solution.

Lastly, this option is like Option 2 but also allows you to pause/resume the nodes in the cluster. If you are utilizing the EC2 on-demand pricing and don't need the cluster up 24x7, this architecture allows you to do that.

The trade-off for this approach is the bursting performance of EBS storage can be exhausted under heavy workloads, which will slow query performance.

AWS Resources

The resources here are similar to the local storage resources but with additional EBS resources.

EC2

The R6 series instance type was chosen for being optimized for memory. The particular R6in series was chosen because it adds the high-performance network feature. It is also essentially the same instance type as Option 1 except it doesn't have local storage.

Elastic Block Storage (EBS)

For analytical workloads, the Throughput Optimized (ST1) disk type provides the best performance and at a low cost. GP2 or GP3 disks are also available but these come at a premium and were designed for small and fast transactions. 

WarehousePG needs high throughput for querying data and not IOPs. 

There is also an option to use Cold Storage (SC1), which provides roughly half the performance of ST1 disks but at a discount. 

Throughput Optimized (ST1) is priced at $0.045 per GB per month while Cold Storage (SC1) is priced at $0.015 per GB per month. ST1 provides double the throughput of SC1 but at 3x the expense. 

It should be noted that with EBS, you pay for the amount of storage you provision, not how much you consume. If you create a 4TB EBS volume, you will pay for 4TB of storage even if you only put 500MB of data on the volume. If you stored that same amount of data in S3, you would only pay for 500MB of storage.

Lastly, EBS can be resized while attached to the cluster. With simple commands, you resize the storage and grow it as needed. You can scale each EBS volume up to 16Tib in size!

CloudFormation

Just like the other two options, a dedicated template is available to deploy this architecture.

Architectural Diagram

Classic MPP architecture with a twist.

Getting Started

Keeping true to open source, we have the CloudFormation templates and scripts readily available for use in a publicly available GitHub repository: https://github.com/warehouse-pg/warehousepg-aws

The templates are parameterized so you can configure your deployment based on your needs and because it is all open source, you can further customize everything about how you want to use WarehousePG for your analytical needs.

Learn more about WarehousePG, PXF, and PGAA!

Summary

WarehousePG is a massively parallel processing (MPP) database originating from the open source Greenplum database. It can be deployed anywhere, including on AWS. WarehousePG is software you deploy how you see fit, instead of it being a one-size-fits-all service. Use the architecture that makes the most sense for your use case!