PostgreSQL Support
PostgreSQL Support
Connexion v26 adds PostgreSQL as a first-class database platform alongside SQL Server. PostgreSQL can be used for both the Connexion configuration database and message queue repositories; it is not an experimental or reduced-function backend.
This gives customers a supported path to Linux-native and managed-cloud database deployments without requiring SQL Server.
Why it matters
Linux-native deployments. Connexion and PostgreSQL can run natively on supported Linux platforms.
Deployment choice. Customers can choose SQL Server or PostgreSQL based on their existing standards, hosting model, and cost requirements.
Managed cloud databases. Connexion can use managed PostgreSQL services and short-lived cloud identity tokens instead of permanently stored database passwords.
Scalable queues. The PostgreSQL queue implementation includes partitioning, set-based queue operations, batched database work, maintenance, metrics, and tier-2 storage integration.
Cost. Postgres is considerably less expensive to license than Sql Server.
Partitioning & Database Maintenance
By default, a repository database is partitioned into about 10 partitions, with each partition representing an equal fraction of the overall message retention. For example, a 30 day retention might use 10 3-day partitions.
Partitioning is also set at the group level. That means each group in the system typically has its own dedicated partition, with retention settings independent from other groups.
Typically, top-level partitioning is done at the group level, with sub-partitioning done by time spans (using the above target of 10 partitions per retention period). This architecture provides a good partition granularity while keeping the overall Postgres partition count at a reasonable number.
Partitioning improves normal queue performance because Connexion and PostgreSQL can work with the partitions that contain the relevant time range instead of treating all retained history as one continuously growing structure. Active indexes and frequently accessed data remain smaller, and statistics, retention, and maintenance can be performed one partition at a time.
Benefit | What partitioning changes |
|---|---|
Queue performance | Queries, queue operations, statistics, and maintenance can target the relevant partitions while older data remains outside the active working set. |
Retention maintenance | When every message in a completed partition has reached its retention boundary, Connexion can retire the entire partition instead of deleting millions of rows individually. |
Tier-2 storage | A completed partition can optionally be archived to low-cost Parquet storage, verified, and then removed from PostgreSQL while its historical messages remain queryable from Connexion. |
Fast partition retirement instead of logged deletes
One of the main complaints with the v16 Sql Server-based message repositories is slow database maintenance. In high-throughput systems, 10s or 100s of millions of messages may need to be pruned daily, and when that pruning is via logged deletes, it can take a long time.
Partitions which are out of scope can be dropped almost instantly – so the same 10s or 100s of millions of messages can be dropped in minutes. This is a major win for high-throughput systems.
Keep the hot database small without losing history
Tier-2 storage, also called cold storage, is optional. When historical retention is required, Connexion can archive a completed partition to Parquet files and verify the archived data before dropping the PostgreSQL partition. Message queries continue across both tiers, so users do not need to restore an archive before investigating an older message.
The active PostgreSQL partition receives current queue work.
After the time range closes and all work is complete, the partition becomes eligible for retention processing.
If tier-2 storage is enabled, Connexion copies and verifies the partition in the configured file system or object store.
Connexion drops the completed partition from PostgreSQL.
Historical queries continue through tier 2, while PostgreSQL remains focused on the smaller operational working set.
This separation keeps active data and indexes compact, makes retention maintenance much faster and more predictable, and allows long-term history to use lower-cost storage. If tier-2 storage is not enabled, dropping an expired partition permanently removes that historical range according to the configured retention policy.
For archive targets, query behavior, retention controls, and PHI considerations, see Message Archiving and Tier 2 Storage.
Version and installation
Connexion v26 targets PostgreSQL 17 or later.
The configuration wizard can connect to an existing PostgreSQL instance, or, install a local stand-alone instance for easy evaluation of the Connexion platform.
For Linux installation details, see Linux Support.
Cloud database authentication
PostgreSQL connections can use:
AWS IAM authentication for services such as Amazon RDS for PostgreSQL.
Azure Entra ID authentication for Azure Database for PostgreSQL.
Google Cloud IAM authentication for Cloud SQL for PostgreSQL.
Traditional PostgreSQL username/password authentication where appropriate.
Cloud token providers refresh credentials through the database client rather than requiring an operator to rotate a static password manually.
Operational considerations
Confirm that the database version, extensions, network path, and identity configuration match the supported deployment guide.
Treat configuration-database migration and queue-repository migration as separate activities.
Test cloud identity and connection renewal before production cutover.
Continue to size and monitor the database according to message volume, retention, and partition activity.
Use message archiving when long retention requirements would otherwise keep excessive historical data in the hot database.