Skip to content

Conversation

@dannykopping
Copy link
Contributor

@dannykopping dannykopping commented Jan 19, 2026

Context:

We noticed by observing go_sql_in_use_connections and go_sql_idle_connections that we were saturating the max connections even in our modestly-sized dogfood installation.

After landing #21403 we conducted some experiments to see where the sweet-spot would be, and we landed on 30 max open connections and 15 idle connections per coder replica.

This will be the new default to give operators the best chance of a smooth experience when using the product.


However, operators who have existing installations need to pay close attention when upgrading to v2.30, which this change will be included in. Postgres' max_connections defaults to 100, and with a 10-replica installation they might've gotten away with not tuning this value with each replica only using 10 connections.

Release manager: we need to call this change out prominently in the changelog.

docs/tutorials/best-practices/scale-coder.md contains some scaling guidance for these values.

Signed-off-by: Danny Kopping <danny@coder.com>
Signed-off-by: Danny Kopping <danny@coder.com>
Signed-off-by: Danny Kopping <danny@coder.com>
@dannykopping dannykopping marked this pull request as ready for review January 19, 2026 16:35
@github-actions github-actions bot added the release/breaking This label is applied to PRs to detect breaking changes as part of the release process label Jan 19, 2026
@dannykopping dannykopping requested a review from johnstcn January 19, 2026 16:35
Copy link
Contributor

@spikecurtis spikecurtis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty nervous about making this breaking change.

First of all, us testing in dogfood is just one team/use case; I'm not sure we should assume it generalizes.

Second of all, while increasing these values decrease measured wait time, do we have any evidence that actual humans are having an actually better experience since we made these changes to our deployment?

This is a particularly sharp edge to ship to customers because they'll install the new version on staging, where loads are probably low and everthing will be fine. Then they could ship to prod and run out of connections and have requests start failing.

@dannykopping
Copy link
Contributor Author

Turns out we had a misunderstanding internally.

I'm going to close this, and we're instead going to call out https://coder.com/docs/tutorials/best-practices/scale-coder#connection-pool-tuning in the release notes of the upcoming v2.30 to advise operators to adjust their own settings accordingly.

@github-actions github-actions bot locked and limited conversation to collaborators Jan 20, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

release/breaking This label is applied to PRs to detect breaking changes as part of the release process

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants