Managed PostgreSQL
PostgreSQL that is always a cluster.
prty runs PostgreSQL as a cluster of machines in different availability zones, reachable only from inside a private network. We ship what we can do reliably. This site also says what we have not built yet, and where our reliability can never be better than the cloud underneath us.
There is no sign-up form. Today the only way to use prty is to write to us.
Principles we do not trade away
High availability only
Every database is a cluster: a primary and at least one replica, in different availability zones. There is no single-machine option to fall back to.
Reliability over features
We would rather have fewer features that are tested under failure than many that are not. A feature that cannot be tested does not ship.
Private by construction
Databases have no public addresses. They are reachable from inside the private network only, and nothing for managing them is exposed to the internet.
Small, written-in-Rust agents
The programs that run beside your database are small, written in Rust, and budgeted for memory and CPU: your database should use the machine, not our tooling.
Open building blocks
Metrics and logs go to VictoriaMetrics and VictoriaLogs. We do not invent a metrics system.
Operations you can trigger by hand first
Every operation ships as something a person can run and inspect. Automation comes second, and never makes an operation less safe.
How a cluster works
A cluster has three members, one in each of three availability zones. Two hold your data: a primary and a replica. The third, the arbiter, holds no data and exists to cast the deciding vote. The members run a consensus protocol (Raft) among themselves, so the cluster elects its own primary, fails over, and shuts a primary down by itself when it can no longer prove that it is the primary. No central server has to be up for that to happen.
A primary that loses contact with the majority stops itself before any other member can take over, and a kernel watchdog resets the machine if the agent hangs. That ordering is what keeps two members from both accepting writes.
What works today
chaos scenarios on AWS (primary killed, replica killed, partitions, restarts, member replacement) in which no acknowledged write was lost
longest pause for writers during an automatic failover in our AWS tests (29.5 s and 30.1 s)
acknowledged writes missing after a soak of almost two days with machines interrupted on purpose (119,654 writes, checked every 30 minutes)
The full list, and what is still missing, is on Status and roadmap. The honest short version: the cluster, its failover and its operations are built and tested; backups and point-in-time recovery, and encryption of connections, are not built yet.
What we will not claim
prty cannot be more reliable than the cloud it runs on. Our machines, disks and DNS are the cloud’s, and so are their availability commitments. Each cloud makes different ones. The reliability page works this out from the providers’ published SLAs and says which of our numbers are measured and which are targets.
We run on AWS today. Google Cloud is on that page and the cost page so that you can compare the two; prty does not run there.
Talk to us
If you would like to use prty, or you want to challenge anything on this site, write to contact@prty.cloud. We will tell you honestly whether it fits.