MotherDuck Now Speaks Postgres

For customer-facing applications

We meet many Postgres users here at MotherDuck, most of whom have struggled to tune their Postgres database to handle both transactional and analytical workloads. When faced with the status quo or a significant refactor to add an OLAP database, both options feel daunting.

The Postgres endpoint changes that calculus. Your application backend already knows how to talk to Postgres. You keep your existing connection pooler, your existing driver, and your existing query patterns. You just point a new connection at MotherDuck and start running analytical queries against your data — no DuckDB library required. Here's an example of a simple local connection to MotherDuck via the Postgres endpoint, running a query with multiple joins that would be tough for Postgres alone.

The endpoint makes MotherDuck a natural fit for customer-facing analytics applications: embedded dashboards, usage reporting features, or any workflow where your backend needs to serve fast query results to end users. Because MotherDuck handles all the analytical compute, your Postgres cluster can stay lean, and your analytical queries no longer compete with your transactional workload.

Popular drivers like JDBC, rust-postgres, node-postgres, and many more are supported out of the box, making it easier to extend your existing application for analytics on MotherDuck. For example, you can use a configuration object in node-postgres to connect:

Copy code
import pg from "pg";

const client = new pg.Client({
  host: "pg.us-east-1-aws.motherduck.com",
  port: 5432,
  user: "postgres",
  password: process.env.MOTHERDUCK_TOKEN,
  // 'md:' uses your default db, or you can choose a specific db
  database: "md:",
  ssl: { rejectUnauthorized: true },
});

await client.connect();
const { rows } = await client.query(
  "SELECT title, score FROM sample_data.hn.hacker_news WHERE type='story' LIMIT 10"
);
console.log(rows);
await client.end();

When using the Postgres endpoint, you'll write queries using DuckDB's SQL syntax. While there are some differences, DuckDB's SQL dialect closely follows the conventions of PostgreSQL; this makes migration a simpler experience than other analytics databases with specialized SQL dialects. You can move data to MotherDuck from Postgres via ETL solutions like Estuary, dlt, or by embedding the pg_duckdb Postgres extension into your Postgres database.

The Postgres endpoint also opens up serverless architectures, like those running on Cloudflare Workers, Vercel Serverless Functions, or AWS Lambda. These environments often can't install native dependencies or have aggressive limits, ruling out the DuckDB client entirely. But Postgres drivers are available everywhere — including in lightweight serverless runtimes. Pair the Postgres endpoint with an external connection pooler like Cloudflare Hyperdrive or Vercel's built-in pool management, and you get predictable connection behavior even as your serverless containers scale up and down.

You can find a guide to using Cloudflare Workers and Vercel + Next.js in the documentation; we've also created example projects for both to help with getting started.

Vercel users who don't have a MotherDuck account yet can get started quickly through the native integration, run vercel integration add motherduck to create an account, provision a database, and inject your credentials as environment variables in one step.

Expanding the ecosystem

Many business intelligence tools, like Hex and Omni, already support native connections to MotherDuck. But the data ecosystem is large, and Postgres is already a well-supported integration.

We're currently adding support for the most popular data tools requested by MotherDuck users via the Postgres endpoint. Often these tools require functions or metadata tables that are not natively available in DuckDB, and thus require some additional work on our side. Keep an eye on our release notes to be the first to hear when these tools can be used with the Postgres endpoint.