Use case · Databases
PostgreSQL hosting
PostgreSQL is a powerful open-source relational database valued for reliability, standards compliance, and extensibility. Hosting it well means tuning memory for caching and providing fast storage for its data and write-ahead log, plus replication for availability. Open-source with no licensing, self-hosted on dedicated EU hardware, it gives control, performance, and European sovereignty.
Key points
- PostgreSQL is an advanced, open-source relational database known for reliability and integrity.
- It benefits from memory tuning for caching and fast storage for data and its write-ahead log.
- Its extensibility — custom types, functions, and extensions — is a defining strength.
- Streaming replication provides high availability and failover.
- Being open-source with no licensing, self-hosting on EU hardware gives control and sovereignty.
What is PostgreSQL, and why host it?
PostgreSQL is a powerful, open-source relational database, widely regarded as one of the most capable and reliable databases available. It is an advanced object-relational system, meaning it supports the full relational model with rich extensions to it, and it has a long reputation for correctness, data integrity, and adherence to standards. PostgreSQL is free and open-source under a permissive licence, so it can be used without licensing cost, and it is extensible in ways that let it be adapted to many needs. These qualities have made it a popular choice for applications that need a dependable, capable relational database.
Hosting PostgreSQL well means providing infrastructure suited to how it works and to the demands of a serious database, so that its capabilities are matched by the platform beneath it. Like any database, PostgreSQL benefits from fast storage, ample memory, and reliable hosting, but it also has characteristics — in how it uses memory, handles connections, and provides replication — that reward hosting attuned to them. This page focuses on PostgreSQL specifically; the general considerations of database hosting apply here too and are covered on the database-hosting page, while what follows attends to what is particular about running PostgreSQL.
PostgreSQL's strengths
PostgreSQL is valued for reliability, data integrity, standards compliance, and extensibility, a combination that suits it to demanding applications. It is designed to protect data integrity, adhering to the properties that keep transactions reliable and data consistent, which matters wherever the correctness of data is important. It is highly standards-compliant, implementing the SQL standard thoroughly, which makes it predictable and portable. And it is known for dependability under real use, having a long track record in production across many kinds of applications.
Extensibility is a particular strength that distinguishes PostgreSQL. It allows custom data types, functions, and operators, and supports extensions that add substantial capabilities — such as extensions for geospatial data, and many others — so that PostgreSQL can be adapted and extended far beyond a basic relational database. This extensibility, combined with its reliability and rich feature set, lets PostgreSQL serve a wide range of applications, from straightforward relational storage to specialised uses its extensions enable. The breadth of what PostgreSQL can do, on a dependable and standards-compliant foundation, is much of why it is so widely chosen.
Memory and configuration for PostgreSQL
PostgreSQL uses memory in specific ways that reward both ample memory and appropriate configuration, so tuning its memory settings to the hardware and workload is part of hosting it well. PostgreSQL caches data in memory to avoid slower storage access, and it uses memory for operations such as sorting and joining within queries; providing enough memory, and configuring how PostgreSQL uses it, lets more data be served from memory and queries run more efficiently. Key settings govern how much memory PostgreSQL dedicates to caching and to query operations, and these should be tuned to the available memory and the workload rather than left at defaults.
Getting this configuration right can make a substantial difference to PostgreSQL's performance. Too little memory dedicated to caching means more slow storage access; poorly-sized memory for query operations can force less efficient processing; and the balance depends on the workload's mix of reads, writes, and query complexity. Hosting PostgreSQL therefore benefits from configuring its memory use to the hardware it runs on and the workload it serves, so that its performance reflects the resources available. We provide ample memory and attend to configuring PostgreSQL to use it well, because a PostgreSQL server with generous, well-configured memory performs markedly better than one left starved or untuned.
Storage for PostgreSQL
PostgreSQL, like other databases, performs many storage operations, so fast storage matters, and it has a particular storage component — the write-ahead log — whose performance is important. Fast NVMe storage suits PostgreSQL by providing the throughput and input/output operations its reads and writes need, avoiding the bottleneck slower storage would impose. Beyond the main data, PostgreSQL writes changes first to a write-ahead log before applying them, which is central to its durability and crash recovery, so the performance of storage for this log affects write performance in particular.
Providing good storage for PostgreSQL therefore means fast storage for both its data and its write-ahead log, sized for capacity and performance. The write-ahead log's role in durability makes its storage important: PostgreSQL relies on it to recover data safely after a crash, so it must be written reliably and quickly. Fast, reliable storage underpins both PostgreSQL's performance and its durability guarantees, which depend on writes being safely recorded. We provide fast NVMe storage sized to the database, attentive to both the data and the write-ahead log, so that PostgreSQL's reads, writes, and durability all rest on storage that serves them well.
Connection handling and pooling
PostgreSQL handles each client connection with a dedicated server process, which is reliable but means that large numbers of connections consume significant resources, making connection management a consideration in hosting it. Each connection carries overhead, so an application opening very many connections — as some do, especially at scale — can burden a PostgreSQL server with the resources those connections consume. This is a well-known characteristic of PostgreSQL, and addressing it is part of running it well under high connection counts.
The usual answer is connection pooling — placing a pooler between the application and PostgreSQL that maintains a manageable set of connections and shares them among many clients, so that PostgreSQL sees a controlled number of connections rather than a flood. A connection pooler lets an application with many clients use PostgreSQL efficiently, avoiding the resource burden of excessive direct connections. For applications that open many connections, pooling is often important to PostgreSQL performing well. Hosting PostgreSQL for such workloads means providing for connection pooling, so that the database is not overwhelmed by connections; we account for this where the workload's connection pattern calls for it.
Replication and high availability
PostgreSQL provides replication, which supports high availability by maintaining copies of the database that can take over if the primary fails. Streaming replication keeps one or more replica servers continuously up to date with the primary, so that if the primary fails, a replica holds a current copy and can be promoted to take over, keeping the database available. This replication is built into PostgreSQL and is the usual basis for making a PostgreSQL database highly available, allowing it to survive the failure of a server.
Setting up replication for availability involves the primary and its replicas, and arrangements for detecting failure and failing over to a replica. The replicas stay current with the primary through streaming replication; when the primary fails, a replica is promoted to become the new primary, and the application is directed to it, restoring service. Replicas can also serve read queries, spreading read load. The right replication and failover arrangement depends on how available the database must be. When we host PostgreSQL, providing for replication and failover where availability requires it is part of the service, using PostgreSQL's own replication to keep the database available through server failures.
Extensions and the PostgreSQL ecosystem
PostgreSQL's extensibility gives it an ecosystem of extensions that add capabilities, which is one of its distinctive advantages and can influence how it is hosted. Extensions add functionality to PostgreSQL — geospatial capabilities, additional data types and indexing, and much more — letting a PostgreSQL database do things beyond the core, tailored to an application's needs. This extensibility means PostgreSQL can serve specialised roles that would otherwise need separate systems, consolidating capabilities within one dependable database.
Hosting PostgreSQL to take advantage of extensions means supporting the extensions an application needs, which run on the PostgreSQL server and may have their own resource implications. An application using a geospatial or other extension needs that extension available and the server resourced for the work it does. Because extensions run within PostgreSQL, they benefit from the same well-provisioned, well-tuned hosting the database as a whole needs. We support running PostgreSQL with the extensions a workload requires, so that the extensibility that is one of PostgreSQL's strengths is available on infrastructure sized for it — letting an application make full use of what PostgreSQL and its ecosystem provide.
Self-hosted PostgreSQL and sovereignty
PostgreSQL being open-source with no licensing cost makes self-hosting it particularly attractive, giving control and, on EU infrastructure, sovereignty without the licensing considerations some databases carry. Because PostgreSQL is free and permissively licensed, self-hosting it involves no licence fees, so the cost is the infrastructure and operation, and there is no vendor lock-in through licensing. This makes self-hosting PostgreSQL on infrastructure you control an appealing way to run a capable database with full control over it and its data.
Self-hosting PostgreSQL on EU infrastructure adds European sovereignty over the database's data. VV Internet Hosting is incorporated in the Netherlands, within the EU, so a PostgreSQL database self-hosted with us keeps its data under European jurisdiction and outside the direct reach of the US CLOUD Act, on infrastructure you control. For databases holding personal, sensitive, or regulated data, keeping the data in the EU on controlled infrastructure keeps it under European law and in your hands. The combination — a powerful open-source database, no licensing, self-hosted with control and European sovereignty — suits organisations that want a capable database on their own terms, which is much of PostgreSQL's appeal for self-hosting.
Where VV Internet Hosting fits — and where it does not
We host dedicated infrastructure for self-hosting PostgreSQL: fast NVMe storage for its data and write-ahead log, ample memory tuned for its caching, dedicated resources free of noisy neighbours, and support for replication, connection pooling, and extensions — in EU datacenters under European jurisdiction. This suits organisations self-hosting PostgreSQL that want performance, control, and European data sovereignty on a foundation they command, taking advantage of PostgreSQL's capabilities on well-suited hardware. For that, we are a strong fit, and we will size and configure the infrastructure to the PostgreSQL workload.
We are clear about our limits. We provide the dedicated infrastructure you run PostgreSQL on; we are not a fully managed PostgreSQL service that administers, tunes, backs up, and updates the database for you as a managed offering. If you want a fully managed PostgreSQL where the provider operates everything, that is a different kind of service. We are the dedicated, sovereign infrastructure on which you self-host and run PostgreSQL — suited to those who want control, performance, and European sovereignty, and not a replacement for a fully managed database service. If self-hosting PostgreSQL on infrastructure you control fits your needs, we can host it well; if you want it fully managed, we will be clear that is a different offering.
Related use cases
See also
Questions
PostgreSQL, answered plainly
Common questions about hosting for PostgreSQL.
Why is PostgreSQL so widely chosen?
For its combination of reliability, data integrity, standards compliance, and extensibility — it protects data integrity, implements the SQL standard thoroughly, and has a long production track record. Its extensibility (custom types, functions, and extensions like geospatial support) lets it serve a wide range of applications on a dependable foundation. It's also open-source with no licensing cost.
What does hosting PostgreSQL well require?
Ample, well-configured memory for its caching and query operations; fast NVMe storage for its data and its write-ahead log (central to durability and crash recovery); connection pooling where an application opens many connections; and replication for availability. Tuning memory and storage to the workload, on dedicated resources, is what lets PostgreSQL perform to its potential.
Why self-host PostgreSQL rather than use a managed service?
PostgreSQL is open-source with no licensing cost, so self-hosting involves no licence fees and no lock-in through licensing, while giving full control over the database and its data. Self-hosting on EU infrastructure also keeps the data under European jurisdiction. Organisations self-host when control, cost, or the sovereignty of the data matter more than a managed service's convenience.
Planning PostgreSQL infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.