PostgreSQL is a relational database with a reputation for correctness. It also handles JSON, full-text search, geospatial data and vector search natively, which regularly removes the need for a second datastore.
What is PostgreSQL?
Postgres is the database that prioritises being right. Constraints are enforced, transactions behave the way the documentation says, and data that violates a rule is rejected rather than silently coerced into something almost correct.
What has made it the default choice is how much it absorbs. JSON columns for semi-structured data, full-text search that removes the need for a separate search service at moderate scale, PostGIS for anything geographic, and pgvector for embeddings. Each of those is a system you do not have to run, back up and keep consistent.
When we choose PostgreSQL
By default, for any new application. The data outlives the code, and a schema that enforces its own rules is the cheapest insurance available against the class of bug that corrupts records quietly.
Specifically when the project involves geography, search, or embeddings — Postgres does all three without a second system.
When we do not use PostgreSQL
On shared hosting, where MySQL is what is offered and Postgres often is not. That is a hosting constraint rather than a technical preference, and MySQL is perfectly capable for most sites.
And when the client's team already operates MySQL well. A database nobody in-house can tune is a worse outcome than a slightly less capable one they can.
And when the application is a small WordPress or WooCommerce site. Those are built for MySQL, run best on it, and moving them is work with no benefit to show for it.
What we build with PostgreSQL
Schemas that enforce the business rules
Foreign keys, check constraints and unique indexes so an invalid state cannot be written at all. Application code can be bypassed; a database constraint cannot, and that is where the guarantee belongs.
Geospatial systems with PostGIS
Vehicle positions, delivery zones, nearest-branch queries. Meridian Freight's control tower runs on this — distance and containment calculated in the database rather than in application code.
Retrieval without a second database
With pgvector, embeddings sit beside the records they describe, in the same transaction and the same backup — which removes an entire class of consistency bug from any AI project.
Full-text search without a search service
Ranked, stemmed search across articles, products or documents, in the database. At the scale most sites operate at this removes an entire service from the architecture and its monthly cost with it.
Audit trails and history
Recording what changed, when and by whom, at the database level so it cannot be bypassed by application code. Finance and compliance ask for this eventually; building it in later is considerably more expensive.
Multi-tenant schemas
One database serving many client organisations with row-level security enforcing isolation, so a query cannot accidentally return another tenant's data even if the application code is wrong.
Reporting without slowing the site
Heavy analytical queries served from a read replica so a month-end report cannot compete with customers for database capacity. The reports get their own resources and the site keeps its response time.
How we ship PostgreSQL projects
Schema designed in the architecture phase, before anyone writes a feature. That week decides whether the system scales far more than the framework choice does.
Backups tested by restoring them. An untested backup is a belief, not a backup, and the moment you find out is the worst possible moment.
Migrations are versioned and run automatically on deploy, so the schema in production is always the schema the code expects. Hand-edited databases are where the worst production incidents start.
What PostgreSQL costs you
Less available on cheap shared hosting than MySQL, which is a real constraint for small budgets in this region.
Tuning it well needs more knowledge than MySQL, so a client operating it themselves needs someone who knows it — otherwise the defaults will do until suddenly they will not.
Connection handling is the operational detail that catches people out. Each connection costs real memory, so an application opening a new one per request will exhaust the server long before the queries do. A connection pooler fixes it, and it needs to be in the plan rather than added after the first outage.
PostgreSQL questions we get asked
Postgres by default for a new application, especially with geography, search or AI involved. MySQL when the hosting only offers it or your team already runs it well. For a typical content site the difference is genuinely small.
Automated, off the production server, and tested by restoring them into a scratch environment. An untested backup is a belief rather than a backup, and the moment you discover that is always the worst possible moment.
Yes, though we would ask why first. If the answer is a specific capability — geospatial, vector search, stricter constraints — it is worth doing. If it is preference, the migration cost and the risk usually are not.
Yes — UTF-8 throughout with no equivalent of MySQL's old utf8 trap, and collation can be set so Arabic sorts in the order a reader expects rather than by byte value. This is one of the quieter reasons we default to it on bilingual projects.
Migrations run as part of the deploy and are written to be safe on a table with data in it — adding a column before using it, backfilling separately, dropping only after nothing reads it. A migration that locks a large table during business hours is a self-inflicted outage.
Comfortably. Postgres runs systems far larger than most businesses reach, and the limit is almost always schema design and missing indexes rather than the database. We design the schema in the architecture phase because that week decides how far the system scales more than any later choice does.