Build it properly, replicate it, make it fail over, and get off the version that is about to lose support. Australian-led PostgreSQL and EDB project work, quoted as a fixed price against acceptance criteria you agree before we start.
It installs in a minute, which is exactly why so many production estates are running a single instance with default settings, no tested standby and a pg_dump on a cron job. The work below is what turns that into something you can put a real workload on.
The instance was stood up to unblock a release and never revisited. Defaults for shared_buffers, work_mem, autovacuum and checkpoints are still in place, and the first sign of trouble is a query that used to take a second.
Streaming replication is configured, replication lag is unmonitored, and no one has run a failover in anger. A standby you have never promoted is a hypothesis, not a disaster recovery plan.
The PostgreSQL project supports each major version for five years and then stops shipping security fixes entirely. Upgrades are usually deferred because nobody owns the cutover plan.
Each of these is scoped, quoted as a fixed price and signed off against acceptance criteria agreed before the work starts. If it cannot be defined that precisely, we say so and quote it hourly instead.
A build you can put a real workload on: sizing against your actual data and concurrency, memory and checkpoint tuning, connection pooling with PgBouncer, autovacuum settings that suit your write pattern, roles and least-privilege grants, and a documented runbook. On-premises, Azure, AWS, or Aurora and Cloud SQL where managed suits you better.
Streaming replication with replication slots, synchronous or asynchronous to match the data loss you can actually tolerate, plus read replicas and routing so reporting stops competing with your transactional workload. Logical replication where you need to move a subset of tables rather than the whole cluster.
Automatic failover built on Patroni or repmgr with etcd or Consul, a virtual IP or HAProxy in front, fencing so a split brain cannot write to two primaries, and EDB Postgres Failover Manager for EDB estates. We fail it over in front of you before we hand it back.
pgBackRest or Barman with point-in-time recovery, retention that matches your policy rather than the default, off-site or cross-region copies, and a restore rehearsed against a stated RPO and RTO. A backup that has never been restored is not a backup.
Oracle, SQL Server or MySQL onto PostgreSQL or EDB Postgres: schema and PL/SQL assessment, data type mapping, application change list, a dry run against a copy of production, and a cutover plan with a rollback that has been tested. EDB Postgres Advanced Server where Oracle compatibility shortens the application work.
Major version upgrades with pg_upgrade or logical replication for a near-zero-downtime cutover, extension compatibility checked first, and a rehearsed rollback. Off end-of-life versions before the security fixes stop, not after.
Query and index tuning against pg_stat_statements, bloat and vacuum remediation, partitioning for tables that have outgrown a single heap, and right-sizing cloud instances that were provisioned for a guess.
The same delivery method as our SQL Server and Oracle work: ITIL change management, and nothing goes to production that has not been rehearsed.
Talk it through with a senior consultant on a free 30-minute call. We write up the scope and the deliverables, agree them with you, and then quote a single fixed price against them — including telling you when the work is smaller than you feared.
Discuss your projectPublished
Yes. Onsys delivers PostgreSQL and EDB Postgres project work for organisations across Australia and New Zealand, with project leadership based in Melbourne and follow-the-sun delivery from Colombo. Work is remote by default; on-site attendance in the Melbourne metropolitan area is arranged as part of the engagement where it helps.
Where the scope can be defined, the project is quoted as a single fixed price with milestone-based payments and written acceptance criteria, so there is no cost-overrun risk. Where it genuinely cannot be defined up front we say so and work at $150 per hour with a four-hour minimum. The scoping call is free and all prices are GST exclusive.
We agree in writing what "done" looks like before any work starts — for a high availability project that means the cluster fails over automatically, we demonstrate it in front of you, and it meets the RPO and RTO you stated. You pay the quoted price for that outcome. If it takes us longer than we estimated, that is our problem rather than a variation.
Yes. We build automatic failover on Patroni or repmgr with etcd or Consul for consensus, HAProxy or a virtual IP so applications follow the primary, and fencing so a split brain cannot write to two nodes. For EDB estates we use EDB Postgres Failover Manager. We run the failover in front of you before handover and leave a runbook your team can follow without us.
Yes. A migration starts with a schema and stored procedure assessment, data type mapping and an application change list, then a dry run against a copy of production before any cutover date is agreed. EDB Postgres Advanced Server is often the shorter path off Oracle because its compatibility layer reduces the application rework. Every cutover has a rollback plan that has been executed in test.
PostgreSQL 12 through 17, plus EDB Postgres Advanced Server, and the managed services — Amazon RDS and Aurora, Azure Database for PostgreSQL and Google Cloud SQL. The PostgreSQL project supports each major version for five years, after which security fixes stop entirely, so upgrade planning is usually the first thing we look at on an older estate.
No. Project work is standalone and most clients hand the finished environment to their own team with the runbook and the documentation. If you would rather not carry it, our monthly DBA plans cover PostgreSQL alongside SQL Server and Oracle, but nothing about the project depends on taking one.
A foundation build is usually days rather than weeks. A high availability or replication project depends on how much of the environment already exists and how much change approval it needs. A migration is dominated by the dry run and the application testing rather than the cutover itself. We give you a schedule with the fixed-price quote, after the free scoping call.