# Postgres.app: six PostgreSQL majors on one Mac, side by side > A Swift menu bar app that ships prebuilt PostgreSQL binaries from 9.4 through 19 beta with PostGIS and friends, runs each server as your own user, and lets several majors run at once. The interesting parts are the build matrix and the two release lines. **PostgresApp/PostgresApp** — The easiest way to get started with PostgreSQL on the Mac - Repository: https://github.com/PostgresApp/PostgresApp - Website: https://postgresapp.com - Stars: 7,785 · Forks: 404 - Language: Makefile - License: NOASSERTION - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/postgresapp-postgresapp ## What happens the first time you start the app The README's Under the Hood section spells out the whole first-run sequence, which is the most useful thing on the page. On the first launch, Postgres.app initialises a cluster, starts the server, creates a superuser named after you, and creates a user database of the same name. On every launch after that it only starts the server. ```bash initdb -D DATA_DIRECTORY -U postgres --encoding=UTF-8 --locale=en_US.UTF-8 pg_ctl start -D DATA_DIRECTORY --wait --log=DATA_DIRECTORY/postgres-server.log --options="-p PORT" createuser -U postgres -p PORT --superuser USERNAME createdb USERNAME ``` Two details in there matter more than they look. The first is that PostgreSQL 15 and later get additional flags, namely `--locale-provider=icu --icu-locale=en-US --data-checksums`, so a 15+ cluster is created with ICU collation and data checksums enabled. If you are comparing behaviour across majors, those defaults differ and they are not yours to change without rebuilding the cluster. The second is the data directory: `/Users/USERNAME/Library/Application Support/Postgres/var-xx`, where `xx` is the major version. It sits inside your home directory and each major gets its own. Stopping is a single fast-mode call: ```bash pg_ctl stop --mode=fast --wait -D DATA_DIRECTORY ``` The README also states plainly that Postgres.app runs the server as your login user, unlike installations that create a separate system account named `postgres`. That is convenient on a laptop and it is the wrong shape for a machine where you care about which operating system account can read the data directory. ## The extension list changes with the PostgreSQL major The bundled extension set is not uniform across versions, and the README is specific enough to be worth reading closely. PostGIS is there for every version. pgrouting and pgvector are marked PostgreSQL 15 and higher. plv8 is marked PostgreSQL 13 and lower, and pljs is marked 14 and higher, which reads as a replacement rather than an addition: plv8 stops where pljs starts. wal2json and pldebugger carry no version qualifier at all, so they are bundled across the board. That matters more than it appears, because the v2.9.6 release notes flag a required configuration change for wal2json after the quarterly upgrade: if you use a third-party logical decoding output plugin such as the bundled wal2json, you need to set the new `output_plugin_libraries` GUC to allow it to load. An upgrade that appears to break replication can be a missing setting rather than a bug. The same release notes warn that indexes using `btree_gist` and `ltree` may require a post-upgrade step, and that parallel built GIN indexes in PostgreSQL 18 need attention. These are upstream PostgreSQL changes passing through the bundle, and the value of Postgres.app here is that the notes tell you they are coming. The repository tree also contains a `Postgres.xcodeproj/` directory and a `Postgres/` directory for the Swift interface, which is the actual application. Everything under `src-xx/` is build input rather than application code. ## Two release lines, one stable and one alpha The releases page currently carries both `v2.9.6` and two 3.x alphas, and which one you should install follows from that. v2.9.6, published on 2026-08-13, is titled August 2026 Releases and its body says it includes the latest quarterly bug and security fixes for PostgreSQL. It lists PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24 paired with PostGIS 3.6.3 through 3.2.10. That is the line carrying security patches. `v3alpha8` shares that same publication date and brings PostgreSQL 19 Beta 3 with PostGIS 3.7.0beta2 and pgvector 0.8.6, described as a preview towards Postgres.app 3.0. `v3alpha9`, published 2026-09-15, adds GUI improvements from issue 842 and another PostgreSQL 19 beta 3 build with PostGIS 3.7.0rc1, and it opens by saying it is a pre-release build for testing. Its version table spans PostgreSQL 14.24 through 19beta3. The 3.x line is where the interface rewrite lives, so it is the one to install if you want to see the new GUI, and the 2.x line is the one to install if you want quarterly security fixes on a stable interface. The last push was on 2026-09-15, the same day as v3alpha9, so both lines are moving. One change worth noticing in the 3.x notes: the `address_standardizer` and `postgis_tiger_geocoder` extensions have been removed from the bundled PostGIS, and along with other previously bundled extensions will ship as separate downloads from a PostgresApp Extensions repository. That is a shift from everything-in-one-binary toward separate downloads, and it lands at the same time as the new GUI. ## Building the binaries needs many gigabytes and a version-specific Python Building the GUI is the cheap half. The buildscript by default just copies binaries out of an existing Postgres.app in your applications folder, so the documented path is to have a copy installed, open the Xcode file and start editing. Xcode 11 or later is required, with Swift 5 support. Building the binaries is not cheap. The `src-xx` directories each hold a makefile that downloads and builds everything, and the README warns in plain terms that it will download and build many gigabytes of sources. The default target builds postgresql, postgis, wal2json, pldebugger, plv8 up to PostgreSQL 13, pgvector from 15, and pgrouting from 15. ```bash make make -j 3 postgresql make -j 3 || echo "Build failed with exit code $?" ``` That last line is a habit worth copying, since a multi-hour parallel build failing quietly near the end is a common way to lose an afternoon. The README also recommends one more job than your logical CPU count and explains why: a macOS 10.12 VM limited to two virtual CPUs uses `-j 3`. It warns against parallel builds for debugging, because they make failures harder to read. The Python requirement is pinned per major version: 3.8.x for PostgreSQL 13, 3.9.x for 14, 3.11.x for 15, 3.12.x for 16, 3.13.x for 17, and 3.9.x or newer for 18 and up. MacPorts is the documented fast route: ```bash xcode-select --install sudo port -N install autoconf automake pkgconfig libtool docbook-xml-4.5 docbook-xsl-nons fop brew install automake cmake docbook-xsl pkgconf ``` Homebrew covers PostgreSQL 14 and later only. The README also states that every major version is built on a different macOS release with a matching Command Line Tools version, PostgreSQL 14 on macOS 11, 15 and 16 on macOS 12, 17 and 18 on macOS 14, and 19 on macOS 26, while the GUI is built on macOS 14 with Xcode 15.0.1. That table is the compatibility story: binary extensions are compiled against a specific SDK, and running an old major on a new macOS is exactly the case where that shows up. ## A repository whose language is Makefile and whose license GitHub cannot name GitHub lists this repository's primary language as Makefile, which is a fair summary: the interesting automation lives in the `src-xx` makefiles, while `update_makefile_targets.py` suggests the version matrix is partly generated. There is also a `BUILD_HISTORY.md`, a `crashreporting/` directory, and separate directories for a login helper, a menu helper and a permissions dialog, which tells you the app does more than wrap pg_ctl. The license situation is genuinely unclear and worth stating plainly rather than smoothing over. GitHub reports no recognised license identifier for this repository, while a `LICENSE` file is present at the top level of the tree. Both facts are true at once, and neither tells you what the terms are. For personal use on your own Mac this does not come up. If you plan to redistribute the binaries, or use them in a commercial setting, that is a question for the file itself or for the author, not something this repository's metadata answers. The topic tags are short, just `postgis` and `postgres`, and the homepage is postgresapp.com with documentation at a `/documentation` path, reachable from the app's Open Documentation menu item. The README also notes that older versions and pre-releases live in the GitHub releases section, which is where the alpha builds above come from. Its command line utility listing is described in the README itself as possibly outdated, which is a small but honest signal about how carefully to read the tail of that page. ## Conclusion Postgres.app is the shortest path from a fresh Mac to a running PostgreSQL with PostGIS, and the part that sets it apart is that several major versions can run simultaneously, which makes it the practical choice for testing an upgrade or reproducing a bug against an older major. What it does not replace is a server you administer: there is no configuration UI beyond starting and stopping, no backup tooling, and no replication setup. Verify two things before depending on it. First, that the version you need is on the release line you are installing, since 3.x is still alpha while 2.x carries the quarterly PostgreSQL security releases. Second, what `LICENSE` actually grants, since GitHub reports no recognised license identifier for this repository while a LICENSE file sits in the tree. ## FAQ ### Can I run several PostgreSQL versions at the same time with Postgres.app? Yes. Running multiple versions of PostgreSQL simultaneously is one of the three things the README lists as included, and each major version gets its own data directory under Application Support named `var-xx`. Starting one server does not stop the others. ### Which PostgreSQL versions does the current build include? The v3alpha9 release from 2026-09-15 lists PostgreSQL 14.24, 15.19, 16.15, 17.11, 18.6 and 19beta3, each paired with a PostGIS version from 3.2.10 up to 3.7.0rc1. The stable v2.9.6 release carries the same majors except 19. ### How do I start and stop a Postgres.app server? From the GUI, using the menu bar app, which issues `pg_ctl start` or `pg_ctl stop --mode=fast --wait -D DATA_DIRECTORY` on your behalf. The README documents the underlying commands but the intended interface is the app, and the data directory defaults to a path inside your own home directory. ### Does Postgres.app run PostgreSQL as a separate system user? No. The README states that Postgres.app runs the server as your user, unlike other installations which might create a separate system user named postgres. The data directory lives in your home directory as a result. ## Sources - [Issues](https://github.com/PostgresApp/PostgresApp/issues) - [PostgresApp/PostgresApp on GitHub](https://github.com/PostgresApp/PostgresApp) - [Project website](https://postgresapp.com) - [README](https://github.com/PostgresApp/PostgresApp/blob/master/README.md) - [Releases](https://github.com/PostgresApp/PostgresApp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/postgresapp-postgresapp