Managed Neon
Understand the self-hosted Neon stack, its storage quorum and the work required before availability.
Managed Neon is in development and unavailable for creation. Hakopod is building a self-hosted Neon stack on your infrastructure. This does not require a subscription to the hosted Neon service.
What runs#
Neon separates PostgreSQL compute from storage. A compute process runs queries. Pageservers provide database pages. Safekeepers receive the write-ahead log and form a quorum. Object storage holds durable page and log data. A storage controller manages tenant attachments and needs its own persistent metadata database. A connection proxy authenticates clients and finds the correct compute endpoint.
| Process | Responsibility |
|---|---|
| PostgreSQL compute | Execute queries against one tenant and timeline. |
| Pageserver | Serve database pages and manage their storage layers. |
| Safekeeper | Persist WAL and participate in the configured write quorum. |
| Storage controller | Track attachments, placement and storage membership. |
| Controller metadata PostgreSQL | Preserve the controller's decisions across restarts. |
| Connection proxy | Authenticate a client and route its session to the owned compute. |
| Object storage | Retain the configured tenant's durable objects. |
The implementation targets upstream snapshot fa504217c61bbcaf5c512d75830564541f917f8f. Neon is licensed under Apache 2.0. Its example Compose configuration is a test fixture; it is not a complete managed deployment.
Ownership and connections#
Hakopod records the platform's project, environment, immutable revision, operation and resource claims in its control database. A creation intent must be recorded before an external resource is created. Confirmation binds that intent to the resource's actual immutable identity. A retry must recover that exact operation; a matching name alone does not prove ownership.
Tenant, timeline and compute identities must stay bound together through configuration changes. The connection proxy uses server-owned endpoint records and authentication material. Applications receive their connection credentials and trust, without access to the storage controller or Kubernetes credentials. Storage and controller traffic need separate, narrowly scoped network policies.
Three safekeepers are one part of the topology. They do not prove that the controller, pageservers, object store, network or physical hosts can survive a failure. Placement labels describe the reported environment; physical zone and provider claims require separate failure tests.
Release requirements#
Source tests have passed for a candidate, and independent review found recovery, deletion, network-isolation and registration gaps. Corrections are in progress. No native Neon stack has passed the complete release checks.
Availability requires qualified component images, secure bootstrap, tenant isolation, verified client TLS, quorum failure and fencing, pageserver replacement, controller recovery, compute restart, branch lifecycle, credential rotation and revocation, bounded connections, object-store outage handling, separate-target restore and complete owned deletion.
No creation command is provided here because the runtime remains gated. Read the database architecture guide for the shared operation model and security guide for the connection requirements.