- Uses the same PostgreSQL major version as production.
- Applies the same schema definitions as production.
- Contains representative development data.
- Supports normal application development and testing workflows.
Example development flow
A typical local development workflow looks like: Managed Postgres fits into existing PostgreSQL development workflows. By developing against a local PostgreSQL instance, teams can iterate quickly, maintain reproducible environments, and gain confidence that applications behave consistently when deployed to Managed Postgres.Run PostgreSQL locally with Docker
The simplest way to create a local development environment is to run PostgreSQL in Docker. Choose a PostgreSQL version that matches your Managed Postgres deployment:docker-compose.yml
Apply the application schema
There’s no single required approach for creating the schema in a local environment. Most organizations already have an established schema management workflow that can be reused unchanged.Application migrations
Many teams use the same migration framework that runs in staging and production environments — tools like Flyway, Liquibase, Rails migrations, Django migrations, Prisma migrations, or Alembic. Applying migrations locally ensures schema evolution is continuously tested as part of normal development:Schema-only PostgreSQL dumps
A schema-only PostgreSQL export can reproduce an existing database structure. This is useful for onboarding, investigating schema behavior, validating compatibility, or quickly bootstrapping development environments. Export the schema:Checked-in SQL definitions
Some teams maintain schema definitions directly in source control as SQL files. These can be applied directly to a local PostgreSQL instance during environment setup. Regardless of the approach, the important outcome is that schema creation is automated, reproducible, and derived from version-controlled definitions.Populate representative development data
Once the schema exists, populate the database with representative development data. For most development workflows, synthetic datasets generated through seed scripts are sufficient. They’re easy to recreate, safe to distribute, and avoid the compliance and security considerations associated with production data. A common approach for SaaS applications is to generate data for a small number of sample tenants and create realistic relationships between users, products, orders, and other business entities.Example multi-tenant schema
The following schema represents a simplified multi-tenant SaaS application:Generate sample data
Install dependencies:seed.py:
seed.py
| Table | Records |
|---|---|
| tenants | 3 |
| users | 60 |
| products | 45 |
| orders | 150 |
| order_items | 400+ |
| audit_logs | 150+ |
PostgreSQL + ClickHouse development environment
The examples above focus on local PostgreSQL development. If you want to test the complete PostgreSQL-to-ClickHouse architecture locally, you can run the open-source PostgreSQL + ClickHouse stack. This stack combines PostgreSQL for transactional workloads, ClickHouse for analytics, and PeerDB for native change data capture (CDC). It lets you develop against PostgreSQL while continuously replicating data into ClickHouse — making it possible to test operational analytics, reporting workloads, and real-time data pipelines directly from your laptop. The stack can be started with a single command and includes all required services preconfigured:- PostgreSQL
- ClickHouse
- PeerDB for PostgreSQL CDC
- Supporting services and sample applications