PostgreSQL development

Design, optimize, and manage advancedPostgreSQL database solutions for complex applications

We design PostgreSQL schemas, find out why queries are slow and plan major-version upgrades, working from the application's point of view. If you are on version 14, its final release is due on 12 November 2026, so now is the time to plan the next step.

Discuss your PostgreSQL databaseCompare MySQL

What PostgreSQL work covers

Database work as part of an application, and not just administration.

  • Schema design

    Tables, constraints and types chosen so the database itself rejects bad data, with JSONB only for data that is really variable.

  • Query tuning

    Reading EXPLAIN ANALYZE output and pg_stat_statements to find what is actually slow, then changing the index, the query or the application.

  • Major-version upgrades

    Choosing the method that suits your downtime window and rehearsing it on a copy, with a way back at every step.

  • Moving from another database

    Moving data and application queries from MySQL or a document store, with row counts and checksums to confirm the result.

PostgreSQL versions, as of October 2026

From PostgreSQL's versioning policy. Each major version is supported for five years.

  • Version 14 ends on 12 November 2026

    Versions 15 to 18 stay in support, with 15 ending in November 2027 and 18 in November 2030. Version 13 and older are already out of support.

  • Version 18 is the current stable

    Now at 18.6. It added asynchronous I/O, uuidv7() for timestamp-ordered IDs, virtual generated columns, and planner statistics that survive a major upgrade.

  • Version 19 is close

    Release candidate 1 came out on 15 October 2026, with general availability planned for 19 November 2026. We'd wait for the first minor release before using it in production.

Three ways to upgrade a major version

These are the methods in PostgreSQL's own documentation. The right one depends on your database size and tolerance for downtime.

  • Dump and restore

    The simplest method, and the slowest. It works well for a small database with a generous maintenance window.

  • pg_upgrade

    An in-place upgrade that can take minutes, especially in link mode. The server is offline meanwhile. From version 18, keeping planner statistics helps performance recover sooner.

  • Logical replication

    A new-version server syncs up with the old one, and you switch over. The documentation puts the switch at several seconds of downtime, but it needs more setup and sequences need extra care.

  • When PostgreSQL isn't the answer

    A simple application on hosting that only offers MySQL may not gain enough from a move. Moving a working database just because of a trend is rarely worth the risk.

How PostgreSQL work runs

We measure before changing anything, and rehearse before touching production.

  1. Measure what you have

    We review versions, sizes, extensions and the slowest queries from your statistics, and take no action on assumptions.

  2. Check the extensions

    Extensions such as PostGIS must have a build for the target version and your host. That can decide the upgrade method.

  3. Rehearse on a copy

    The full process runs on a copy of production, is timed and has its results checked, including the application's own tests.

  4. Cut over with a way back

    We agree the window and the rollback point, then run the rehearsed steps and watch query performance afterwards.

How PostgreSQL work is charged

Tuning is well suited to a short engagement. Schema design belongs in the wider project.

An upgrade or tuning review can be scoped as a fixed piece of work once we have seen the statistics. Longer work, or database help alongside feature development, is billed from $20/h in USD, invoiced in USD, GBP, EUR or INR, or arranged through a dedicated developer.

We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. We can run a cutover in a low-traffic window for you while still having time to check it with your team. PostgreSQL commonly sits behind Django and Laravel applications.

Why no client databases are named

Most of our work is delivered under NDA, so many projects cannot be named.

A database is the most sensitive part of any system, so we don't name the ones we have worked on. This page explains how we would treat yours. We work on copies where possible, and agree access rules in advance.

Questions about PostgreSQL

What teams usually ask before an upgrade or a move.

Our host manages PostgreSQL. Do we still need to do anything?
Yes. Managed services apply minor updates, but major versions usually need planning on your side, as your application and extensions have to be tested on the new version, and hosts have their own deadlines.
Should we skip straight to 18?
Normally yes. Each of the three upgrade methods can skip versions, so going to a current version buys you the most time. Read the release notes in between, because behaviour changes accumulate.
PostgreSQL or MySQL?
Both are capable. PostgreSQL has richer types, extensions such as PostGIS and stricter data handling. MySQL is very widely hosted and may be what your stack already expects. Existing skills and hosting often decide it.
Will adding indexes fix our slow queries?
Sometimes. It can also slow down writes, and the cause may be the query, missing statistics or table bloat. That is why we read the query plans first.

Tell us your version and database size

Add your host and how much downtime you can accept. We will suggest an upgrade method and tell you what we need to confirm it.

Start a PostgreSQL conversationCompare MySQL

We reply within one business day (IST).