PostgreSQL Endpoint

PostgreSQL endpoints connect Eve to PostgreSQL-compatible databases such as self-managed Postgres, Amazon RDS, Aurora PostgreSQL, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, Neon, and other Postgres-compatible services.

PostgreSQL migration execution is an early-access surface. Use this page to configure endpoints, understand how Eve models Postgres traffic, and plan a migration. Coordinate production execution with the Eden team until the public guided PostgreSQL workflow is available.

What Eve Uses PostgreSQL Endpoints For

PostgreSQL endpoints support:

Direct query execution through the endpoint read/write APIs.
Protocol-aware gateway and interlay planning.
Schema, table, sequence, extension, and metadata discovery.
Transaction and write-policy design for migration planning.
Early-access migration validation, replay, and rollback design.

Basic Endpoint Shape

json

{
  "endpoint": "postgres-source",
  "kind": "postgres",
  "config": {
    "write_conn": {
      "url": "postgresql://user:password@postgres-source.internal:5432/app"
    }
  },
  "description": "Current PostgreSQL source"
}

Create it:

bash

curl -sS -X POST "$EDEN/endpoints" \
  -H "$AUTH_HEADER" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint": "postgres-source",
    "kind": "postgres",
    "config": {
      "write_conn": {
        "url": "postgresql://user:password@postgres-source.internal:5432/app"
      }
    },
    "description": "Current PostgreSQL source"
  }'

Create a target endpoint with the same shape and a different endpoint id and connection URL.

Connection Guidance

Use a database role with the minimum privileges required for the intended task:

Task	Typical privileges
Query routing	Connect and run the application queries that flow through Eve.
Schema discovery	Read catalog metadata for schemas, tables, views, indexes, constraints, sequences, functions, triggers, and extensions.
Data movement	Read source tables and write target tables. COPY-based movement needs sufficient table privileges.
DDL migration	Create schemas, tables, indexes, constraints, functions, and triggers on the target.
Two-phase commit	Use `PREPARE TRANSACTION` and `COMMIT PREPARED` if strict cross-database commit is selected.

For production migrations, separate application credentials from migration/admin credentials where possible.

Planning Checklist

Before a PostgreSQL migration, collect:

Source and target Postgres versions.
Extensions installed on source and target.
Schemas and tables in scope.
Primary keys or stable ordering keys for each table.
Large tables, hot tables, and tables with frequent updates.
Triggers, generated columns, functions, materialized views, and sequences.
Whether the application uses prepared statements, COPY, LISTEN/NOTIFY, advisory locks, or session-level settings.
Whether the target will use logical replication, dual-write, COPY backfill, or another movement path.

Migration Design Notes

PostgreSQL migrations are more sensitive to transaction and schema behavior than Redis migrations. A safe plan should explicitly choose:

Area	Decision
Schema movement	Which DDL is applied before data, during cutover, and after data.
Row movement	COPY batches, ordering, chunk size, retry behavior, and conflict handling.
Write consistency	Whether writes are source-authoritative, target-authoritative, both-required, or coordinated through two-phase commit.
Transactions	How BEGIN/COMMIT, savepoints, prepared statements, and session state are handled.
Lag and replay	How target lag, failed secondary writes, and replay queues are monitored.
Cutover	Whether traffic shifts by canary reads, blue/green toggle, or full cutover.
Rollback	How long source remains available and what happens to target-only writes.

Interlay Planning

When using an interlay, applications connect to Eve instead of directly to the source. The interlay lets Eve keep the client path stable while routing to source, target, or both.

For a production run, test:

Startup and authentication behavior.
Simple Query protocol.
Extended Query protocol and prepared statements.
Transaction pinning.
Session commands such as SET, RESET, and DISCARD.
Query cancellation behavior.
COPY usage.

Validation

Use validation checks that match the workload:

Row counts by table.
Checksums or sampled row comparison for high-value tables.
Sequence values and setval behavior.
Trigger-bearing table checks.
WAL lag or replay queue depth.
Error logs for schema mismatch, type mismatch, constraint failure, and failed secondary writes.
Application read-your-writes behavior after write failures.

Operational Status

The public guided workflow API documented in Migrations is Redis-specific today. PostgreSQL migration work should be treated as early access. Use endpoint docs, schema inventory, and architecture guidance for planning, then coordinate exact execution with the Eden team.

Last updated: October 20, 2018