Freeze the version matrix
Record 1C platform version and architecture, application configuration and extensions, Linux distribution, PostgreSQL build, drivers, license server and client connection methods. Validate support through official documentation and support terms rather than a successful test database startup.
Use a supported PostgreSQL build and account for 1C-specific patches optimized for platform workloads. Updating one element at random may change query plans or background-job behavior.
Size from workload
Collect active sessions, heavy reports, scheduled jobs, database size and growth, exchanges and maintenance windows. Separate the 1C application server and database where load, resilience or security requires it. Review NUMA, memory, storage, network and time synchronization.
Minimum requirements allow software to start; they do not replace a load test based on the real profile.
Tune PostgreSQL as part of 1C
Memory, autovacuum, checkpoints, logging and parallelism must match both 1C behavior and server capacity. Do not copy another database's configuration or select maximum values from an article.
Observe waits, locks, long queries, table and index growth, background-operation duration and storage latency. Every parameter change goes through staging and has a rollback plan.
Design recovery before launch
Define RPO and RTO, take full backups and archive logs, keep a copy in another security domain and restore regularly to a validation node. The test includes database consistency, user login and key business operations—not only a successful restore command.
Upgrade in one coordinated window
Change the platform, application, PostgreSQL, Linux and drivers under one plan. A production-like copy receives functional and load tests, then a pilot is updated before the remaining nodes. Record duration, errors and performance change.
The resulting environment is governable: the team knows its supported combination, can measure it and can recover service without guesswork.