PostgreSQL database development
PostgreSQL is our default database. It is relational when you need guarantees and flexible when you need JSON, and it has a habit of removing the need for a second data store entirely.
Where we use PostgreSQL
PostgreSQL is part of the stack on these 3 services. Each page covers how we work, what you get and what it costs to start.
PostgreSQL in practice
PostgreSQL is our default because it refuses to store data that violates its own rules. Real constraints, real foreign keys and transactional DDL mean the database is the last line of defence rather than a passive store trusting whatever the application sends it. On a system several services write to, that is the difference between consistent data and a slow-growing mess.
It also keeps removing reasons to run a second system. JSONB covers most document use cases while keeping joins available, full-text search handles a large share of search requirements, PostGIS covers geospatial, and pgvector covers embedding search for AI features. Each one avoided is a service you do not have to run, secure, back up and keep in sync.
What we build with PostgreSQL
The transactional core of web and mobile products, with a schema designed to be migrated rather than worked around.
Window functions, CTEs and materialised views doing analytical work in place, before anyone buys a warehouse.
Full-text search and PostGIS for location features, often replacing a separate service on mid-sized products.
Is PostgreSQL right for you?
Ask usA good fit when
- The transactional core of almost any product
- Data with real relationships and constraints worth enforcing
- Analytical queries you would rather not move to a warehouse yet
- Search, geospatial or vector features you would otherwise buy separately
Probably not when
- Pure caching or ephemeral state — that is Redis
- Petabyte-scale analytics, which belongs in a warehouse
- Genuinely schemaless data with no stable shape at all
What we run alongside PostgreSQL
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- PgBouncer
- Connection pooling, which matters as soon as you run more than a couple of application instances.
- pgvector
- Embedding search next to your relational data, instead of a separate vector database.
- pg_stat_statements
- Which queries actually consume the time — where performance work should start.
- Flyway, Alembic or Prisma Migrate
- Versioned migrations reviewed like any other change.
- Point-in-time recovery
- Backups plus WAL archiving, with restores actually tested.
Why PostgreSQL
Let’s talkCorrectness first
Real constraints and transactional DDL mean the database refuses invalid data instead of trusting the application.
Relational and document in one
JSONB columns cover schema-flexible data without giving up joins and constraints elsewhere.
Extensions do a lot
PostGIS, pgvector and full-text search extend it into jobs that would otherwise mean another system to run.
What we get called in to fix
Get a second opinionMissing indexes
Sequential scans on large tables. Usually the cheapest large performance win available.
N+1 query patterns
Hundreds of small queries where one join would do — an ORM usage problem, not a database one.
Connection exhaustion
Every application instance holding its own pool until the database refuses new connections.
Migrations that lock production
Schema changes taking exclusive locks on large tables during traffic. Avoidable with the right sequence.
PostgreSQL or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Postgres for correctness, complex queries and JSON. MySQL is perfectly good on simpler read-heavy workloads with existing operational familiarity.
JSONB covers most document needs while keeping joins and constraints. Mongo when the data is genuinely variable and relationships are rare.
Managed almost always. Backups, failover and patching are worth more than the licence saving.
MongoDB
Node.js
PHP
Python
React
Vue
Angular
AWS
Azure
Django
Google CloudGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
PostgreSQL when correctness, complex queries or JSON matter. MySQL is a fine choice on simpler read-heavy workloads.
Frequently. JSONB covers most document use cases while keeping joins and constraints available.
Yes — versioned migrations in the deploy pipeline and tested restores, not just scheduled dumps.
Frequently, up to a few million documents. Beyond that, or with heavy relevance tuning, a dedicated engine earns its place.
By restoring them on a schedule. A backup nobody has restored is a hypothesis, not a backup.