Verified history
This means HyperObserve has not found sufficient first-party evidence for a dated before-and-after event. It does not mean PostgreSQL has never changed. Undated values are kept in the current baseline below instead of being presented as history.
Current monitored baseline
HyperObserve currently monitors 4 scoped observations for PostgreSQL. The baseline covers max_connections, Field size, Columns per table, Identifier length. Each value retains its plan, product, endpoint, region, account, or runtime qualifier so a future change can be compared against the correct scope.
| Constraint | Current value | Scope | Verified source |
|---|---|---|---|
| max_connectionsThis is not a universal hard maximum. Kernel settings, provider configuration, reserved slots, and memory affect usable capacity. | Configured per server; typically 100 by default | PostgreSQL 18 | PostgreSQL Global Development GroupAug 22, 2026 |
| Field sizeVariable-length values can be stored out of line with TOAST; practical limits may be lower. | 1 GB | PostgreSQL 18 | PostgreSQL Global Development GroupAug 22, 2026 |
| Columns per tableFurther limited by the requirement that the stored tuple fit on a single heap page; dropped columns still count. | 1,600 | PostgreSQL 18 | PostgreSQL Global Development GroupAug 22, 2026 |
| Identifier lengthCan be changed only by recompiling PostgreSQL. | 63 bytes | PostgreSQL 18 | PostgreSQL Global Development GroupAug 22, 2026 |
Tracked constraints and impact
Engine limits, configured server values, and practical operational constraints. A change is recorded only when it alters a constraint developers can act on, such as capacity planning, request shaping, model selection, deployment configuration, storage design, retry behavior, or account budgeting.
PostgreSQL max connections
How PostgreSQL max_connections actually works, how to inspect it, reserved slots, provider caps, and safer scaling choices.
PostgreSQL row size limits
PostgreSQL 18 field, column, identifier, heap-page, and TOAST constraints without collapsing them into one misleading row-size number.
How a change is verified
- Compare the current first-party statement with the previously stored observation, including the exact plan, model, runtime, endpoint, region, and account scope.
- Separate a true product change from documentation clarification, temporary capacity, configurable account state, or a limit that applies to a different execution path.
- Preserve the old and new values, official source, effective date when disclosed, detection date, and practical impact. If those elements cannot be supported, no historical event is published.
Official sources monitored
These first-party documents support the current PostgreSQL baseline. HyperObserve links directly to them so you can confirm the live wording before making a production decision.
max_connections
PostgreSQL 18 Appendix K