What is PostgreSQL?
PostgreSQL is an open-source relational database. It stores data in tables with a schema, guarantees that a transaction either completes fully or not at all, and answers questions in standard SQL. It has been developed in the open for decades, by a community rather than a vendor, under a permissive license that nobody has been able to change.
That last point is not a detail. Several databases that were open source when teams adopted them have since moved to restrictive licenses. PostgreSQL's governance makes that particular surprise unlikely, and for organizations choosing a store they expect to keep for a decade, it is often the deciding argument.
What you actually get
The parts people expect: tables, joins, indexes, transactions, constraints, and a query planner that has had a very long time to get good.
The parts that surprise people who last looked years ago:
- JSON as a first-class type. JSONB stores documents with indexing and querying, so the common "we need a document store alongside our database" requirement often turns out not to need a second database.
- PostGIS for geospatial data, which is the reference implementation in that field rather than an also-ran.
- pgvector for embeddings and similarity search, which is why PostgreSQL keeps appearing in AI architectures that expected to need a dedicated vector database.
- Full-text search, arrays, range types, and an extension mechanism that installs the rest.
The practical consequence is that the default answer to "we need another datastore for this" is worth challenging once. Often PostgreSQL already does it, and one database is far less work to run than two.
The vector case is worth drawing out, because it is where this argument has teeth. A retrieval system that anything depends on needs its vector store to survive a node failure, restore to a point in time, and be backed up on the same schedule as everything else. Those are settled problems in PostgreSQL: replication, failover and point-in-time recovery are the parts of it that have had the most attention for the longest. A purpose-built vector store may well search faster, and then its availability, backup and recovery story is a separate thing you own and operate. That second system is where the cost usually turns up, and it turns up in operations rather than in the benchmark.
When something else fits better
Caching and ephemeral state. A key-value store is the right tool for a session cache. PostgreSQL can do it and should not. Redis is the usual answer.
Queues and event streaming. Using a table as a work queue is a well-known pattern and a well-known source of lock contention at volume. A message broker is built for it: RabbitMQ for distributing work, a log such as Kafka when every consumer needs to read every event.
Genuinely enormous single tables with simple access patterns. At the point where you are sharding aggressively, purpose-built stores earn their keep.
Analytics on billions of rows. Column-oriented engines answer those queries in a way a row store will not, however good its planner is.
The version treadmill nobody mentions
PostgreSQL major versions are supported for five years. That is a comfortable cadence compared with much of the stack, and it is exactly why it gets forgotten: five years is long enough for the person who set the database up to have changed jobs.
A major upgrade is not a package update. It rewrites the on-disk format, which means either downtime proportional to your data or a replication-based upgrade set up in advance. Teams that skip several versions discover that the deferred work did not go away, it compounded.
What running one properly involves
The install is easy. These are the parts that decide whether you still have your data in three years:
- Backups you have restored. A backup that has never been restored is a belief, not a backup. Point-in-time recovery is the standard to aim for, and testing it is the only way to know you have it.
- Failover that has been rehearsed. Replication is straightforward to configure and easy to configure in a way that quietly does not fail over when the primary dies.
- Connection management. PostgreSQL allocates a process per connection. An application pool sized without thinking about that is one of the most common ways a healthy database falls over.
- Vacuum and bloat. The storage model leaves dead rows behind, and autovacuum keeps up with normal load. Under abnormal load it does not, and the failure is gradual until it is not.
- Security patching on the project's schedule. Minor releases arrive quarterly and fix real problems.
None of this is hard in isolation. It is a standing obligation, and it is usually nobody's actual job.
Managed, or your own
Running PostgreSQL yourself is entirely reasonable if someone owns the list above. The question worth answering honestly is whether anyone does, and what happens on the week they are on holiday.
A managed service moves that list to someone whose job it is. What varies between managed offerings is where they run, which jurisdiction governs the contract, and whether you keep a standard PostgreSQL you could take elsewhere or a fork you cannot.
Where VSHN fits
VSHN operates PostgreSQL on Swiss cloud infrastructure from CHF 80 per month, with up to 99.99% SLA, backups, upgrades and 24/7 incident response, on Cloudscale, Exoscale and other providers. It is standard PostgreSQL with the standard extension mechanism, so nothing about it locks your application in. Our sovereignty assessment covers the jurisdiction question, and Servala offers self-service ordering if you would rather not talk to anyone first.