Support Configuring Multiple Databases in the Postpipe 2.0 Connector Template
Summary
In the current Postpipe 2.0 connector template, database configuration assumes a single target database. However, in several deployment scenarios—especially Postpipe 2.0 local development environments that already use a fully separate Postpipe database—there is a need to configure and route traffic to multiple databases.
Right now there is no standard, template-level mechanism to define, register, or switch between database connections. This forces developers to manually modify the connector logic when multiple data stores are required.
Use Case / Motivation
- Separate databases for different projects or tenants
- Stronger logical and security isolation
- Cleaner separation between environments (prod, staging, local, etc.)
- Local Postpipe 2.0 development where Postpipe already runs on its own database and connectors should point elsewhere
- Easier scaling and maintainability as usage grows
Expected Behavior
Developers should be able to define and select multiple database connections through configuration, for example:
- Environment variables
- A configuration file
- A connection registry / client map
The connector should route reads and writes to the correct database based on connector configuration (e.g., connector ID, tenant mapping, or config flag).
Actual Behavior
- Only a single database connection is supported
- Multi-database routing requires custom code changes
- This limits scalability and isolation across deployments
Proposed Enhancement
- Extend the connector template to support multiple DB URIs / configurations
- Provide a standard way to select the database at runtime
- Include documentation and examples for:
- Local Postpipe 2.0 environments using an independent DB
- Multi-tenant or multi-project separation models
Additional Context
This feature request is specifically driven by Postpipe 2.0 local development setups, where the core Postpipe app already utilizes a separate database instance. Supporting multiple database configurations at the connector-template level will prevent accidental data overlap and improve security, maintainability, and clarity.
Support Configuring Multiple Databases in the Postpipe 2.0 Connector Template
Summary
In the current Postpipe 2.0 connector template, database configuration assumes a single target database. However, in several deployment scenarios—especially Postpipe 2.0 local development environments that already use a fully separate Postpipe database—there is a need to configure and route traffic to multiple databases.
Right now there is no standard, template-level mechanism to define, register, or switch between database connections. This forces developers to manually modify the connector logic when multiple data stores are required.
Use Case / Motivation
- Separate databases for different projects or tenants
- Stronger logical and security isolation
- Cleaner separation between environments (prod, staging, local, etc.)
- Local Postpipe 2.0 development where Postpipe already runs on its own database and connectors should point elsewhere
- Easier scaling and maintainability as usage grows
Expected Behavior
Developers should be able to define and select multiple database connections through configuration, for example:
- Environment variables
- A configuration file
- A connection registry / client map
The connector should route reads and writes to the correct database based on connector configuration (e.g., connector ID, tenant mapping, or config flag).
Actual Behavior
- Only a single database connection is supported
- Multi-database routing requires custom code changes
- This limits scalability and isolation across deployments
Proposed Enhancement
- Extend the connector template to support multiple DB URIs / configurations
- Provide a standard way to select the database at runtime
- Include documentation and examples for:
- Local Postpipe 2.0 environments using an independent DB
- Multi-tenant or multi-project separation models
Additional Context
This feature request is specifically driven by Postpipe 2.0 local development setups, where the core Postpipe app already utilizes a separate database instance. Supporting multiple database configurations at the connector-template level will prevent accidental data overlap and improve security, maintainability, and clarity.
Support Configuring Multiple Databases in the Postpipe 2.0 Connector Template
Summary
In the current Postpipe 2.0 connector template, database configuration assumes a single target database. However, in several deployment scenarios—especially Postpipe 2.0 local development environments that already use a fully separate Postpipe database—there is a need to configure and route traffic to multiple databases.
Right now there is no standard, template-level mechanism to define, register, or switch between database connections. This forces developers to manually modify the connector logic when multiple data stores are required.
Use Case / Motivation
Expected Behavior
Developers should be able to define and select multiple database connections through configuration, for example:
The connector should route reads and writes to the correct database based on connector configuration (e.g., connector ID, tenant mapping, or config flag).
Actual Behavior
Proposed Enhancement
Additional Context
This feature request is specifically driven by Postpipe 2.0 local development setups, where the core Postpipe app already utilizes a separate database instance. Supporting multiple database configurations at the connector-template level will prevent accidental data overlap and improve security, maintainability, and clarity.
Support Configuring Multiple Databases in the Postpipe 2.0 Connector Template
Summary
In the current Postpipe 2.0 connector template, database configuration assumes a single target database. However, in several deployment scenarios—especially Postpipe 2.0 local development environments that already use a fully separate Postpipe database—there is a need to configure and route traffic to multiple databases.
Right now there is no standard, template-level mechanism to define, register, or switch between database connections. This forces developers to manually modify the connector logic when multiple data stores are required.
Use Case / Motivation
Expected Behavior
Developers should be able to define and select multiple database connections through configuration, for example:
The connector should route reads and writes to the correct database based on connector configuration (e.g., connector ID, tenant mapping, or config flag).
Actual Behavior
Proposed Enhancement
Additional Context
This feature request is specifically driven by Postpipe 2.0 local development setups, where the core Postpipe app already utilizes a separate database instance. Supporting multiple database configurations at the connector-template level will prevent accidental data overlap and improve security, maintainability, and clarity.