Skip to main content

Neon

Neon is serverless Postgres with branching and autoscaling. Load data into MotherDuck with DuckDB's PostgreSQL extension, reading from a Neon branch or read replica to keep analytics off your application compute.

Neon is serverless Postgres with branching and autoscaling. Because it's Postgres on the wire, DuckDB's PostgreSQL extension attaches it like any other Postgres database, and everything on Loading data from Postgres applies.

Attach a Neon database​

Install and load the postgres extension, then attach your Neon connection string. Neon requires TLS, so keep sslmode=require in the string:

INSTALL postgres;
LOAD postgres;
ATTACH 'md:';

ATTACH 'postgresql://<user>:<password>@<endpoint>.neon.tech/<database>?sslmode=require'
    AS neon_db (TYPE postgres, READ_ONLY);

CREATE DATABASE IF NOT EXISTS analytics;

CREATE TABLE analytics.main.orders AS
SELECT * FROM neon_db.public.orders;

Attaching read-only is a good default: it makes accidental writes back to your application database impossible.

To avoid putting credentials in the ATTACH string, store them in a secret first:

CREATE SECRET neon_secret (
    TYPE POSTGRES,
    HOST '<endpoint>.neon.tech',
    PORT 5432,
    DATABASE '<database>',
    USER '<user>',
    PASSWORD '<password>'
);

ATTACH '' AS neon_db (TYPE postgres, SECRET neon_secret, READ_ONLY);

Read from a branch or replica​

Neon's branching and read replicas both help here:

  • Read replica. Point the load at a read replica endpoint so a large scan doesn't compete with application traffic on your primary compute.
  • Branch. Create a branch for the load when you want a stable, point-in-time snapshot of the data, for example for a backfill that has to be reproducible.

Both are separate endpoints in the Neon console, so switching is a connection-string change.

Load on a schedule​

For a recurring load, run the same extract from a Flight so it executes on MotherDuck compute on a cron rather than on a machine you maintain. The Postgres ingest Flight recipe is a ready-made starting point: point it at your Neon endpoint and store the credentials as a Flight secret.

For append-only tables, extract incrementally with a watermark instead of reloading the table. See Data loading patterns.

Things to know​

  • Compute cold starts. A Neon compute that has scaled to zero takes a moment to wake up, so the first query of a scheduled load can be slow or time out. Retry once rather than treating it as a failure.
  • pg_duckdb is not available on Neon. The pg_duckdb route, where Postgres itself connects out to MotherDuck, needs the extension installed server-side. Neon's extension list doesn't include it, so use the DuckDB-side ATTACH above instead. For a comparison, PlanetScale does offer pg_duckdb.
  • Row-by-row transfer has a ceiling. The postgres extension is well-suited to one-time loads and backfills. For continuous replication of a busy table, use a change-data-capture tool such as Estuary or Streamkap.

Related content​