PostgreSQL.
A relational database for product data that needs structure, integrity and room to grow.
Talk to us about PostgreSQL
Key features
What PostgreSQL does well.
Extensions in the database
Extensions add features inside the database, such as PostGIS for location data and pgvector for embeddings.
Row-level security
Policies on a table decide which rows each database role can read or change, enforced by Postgres itself.
Indexed JSONB
JSONB columns store documents in a binary format, and GIN indexes make queries inside them fast.
Logical replication
Logical replication streams changes from chosen tables to another database, which helps with upgrades and reporting copies.
What we build with it
Data your product can rely on.
PostgreSQL is our default database for product data. It enforces relationships and constraints, handles JSON where a document fits better, and is available as a managed service on every major cloud.
Schema design
Tables, relationships and constraints that reflect how the business actually works.
Migrations
Versioned schema changes applied the same way in every environment.
Reporting queries
Indexes and views that keep dashboards and exports responsive as data grows.
When it’s the right choice
PostgreSQL suits almost any product with related records, permissions and reporting needs, particularly where data accuracy matters.
When we’d pick something else
For very high-volume event data or simple key-value lookups, a specialised store can sit alongside it. We would add one only when a real need appears.
Our PostgreSQL services
How we can help.
Schema design
Data models for new products, with constraints, indexes and access rules agreed before the first migration.
Performance reviews
Query plans, index use and connection settings checked against the queries your product actually runs.
Version upgrades
Major version upgrades tested against a copy of your data, with a rollback plan ready.
Migrations to Postgres
Moves from MySQL, SQL Server or other databases with repeatable scripts and checks against the source.
How we work
Starting a PostgreSQL project.
Review what exists
Code, data, hosting and the people who maintain it, before any PostgreSQL decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
In our own products
SoulCare.
In SoulCare, each home-care provider has its own PostgreSQL database, keeping one provider’s records apart from another’s.
Read the case study ↗
Industries
Where we use it.
- Health & social care Software for care providers, where visits, medication and family updates rely on one accurate record.
- Property & field services Software for maintenance and field teams, from the first request through inspection, dispatch and payment.
- Fintech & professional services Client portals and internal tools for firms where onboarding, documents, approvals and audit trails matter.
Where AI fits
AI in data work.
Vector search where your data lives
PostgreSQL with pgvector (including on Supabase and Neon), MongoDB Atlas and Redis can all store embeddings next to your records, so search does not need a separate system.
Knowledge assistants ↗Access rules before retrieval
Row-level security in PostgreSQL limits what an assistant can retrieve to what the signed-in user is allowed to see.
Knowledge assistants ↗
Where it stops: Embeddings are derived from personal data too, so they need the same retention and deletion rules as the records they came from.
What’s changing
Shifts to plan for.
Dates that affect PostgreSQL projects, checked against the official sources.
November 2025
PostgreSQL 13 reaches end of life
Version 13 had its final release on 13 November 2025. PostgreSQL 18, released that September, is the newest major version.
Where it fits
Related expertise.
- Web application development Browser-based tools for customers and staff, built for the data, roles and permissions behind them.
- APIs & integrations Connect your product to the systems your team relies on, with clear contracts and handled failures.
- Legacy modernisation Replace or rework an ageing system in stages, keeping the business running while it changes.
- Cloud architecture Choose and structure cloud services around your product’s data, access and operating needs.
Common questions
PostgreSQL questions.
Can you migrate data from another database?
Yes. We map the existing schema, write repeatable migration scripts, check the results against the source and plan a cut-over that limits downtime.
Should we use a managed PostgreSQL service?
Usually. Managed services on AWS, Azure and Google Cloud handle backups, patching and failover, which leaves your team less to operate.
Further reading
- A database for every pull request: preview environments that work How to give each pull request its own database branch, with safe data, tested migrations and automatic clean-up.
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- One database per tenant: isolating customer data in SaaS When each customer gets its own PostgreSQL database, and what that means for migrations, connections and running costs.