MotherDuck alternatives: managed DuckDB without lock-in

Short version: if what you want is DuckDB itself, hosted, without a proprietary layer on top, Layerbase Cloud runs plain DuckDB behind a Postgres wire proxy, so any pg client connects and none of your queries get rewritten. If what you want is MotherDuck's hybrid execution, where a query splits between your laptop and their cloud, nothing else offers that and you should use MotherDuck. And if the data already lives in the same process as the code querying it, embed the DuckDB library and skip hosting entirely.

DuckDB is one of my favorite databases. It's an embedded analytical engine that does for OLAP what SQLite did for OLTP: takes a category that used to require a server and makes it a library you pip install or pnpm add. The columnar storage is fast, the SQL dialect is generous, and the ability to query CSV and Parquet files directly from disk without any import step is genuinely revolutionary for anyone who's spent a career building ETL pipelines.

The hosting story for DuckDB is more complicated. MotherDuck is the company started by some of the DuckDB team to commercialize it as a cloud service. It works well and has real product polish. But MotherDuck is not a thin managed layer over DuckDB. It's a hybrid execution engine that adds a proprietary layer on top, with its own pricing model (compute units, dual execution), its own SQL extensions, and its own lock-in. That bothers some people and not others. If you're in the bothered camp, this post is for you.

Contents

• What MotherDuck is and isn't
• Option 1: Layerbase Cloud
• Option 2: Run it locally with the Layerbase CLI
• Option 3: Layerbase Desktop
• Option 4: Embed DuckDB in your app
• Option 5: DuckDB on a single VM
• FAQ
• Which one to pick

What MotherDuck is and isn't

MotherDuck is two things at once. It's a hosted DuckDB you can run queries against, and it's a proprietary "hybrid execution" engine that splits work between your laptop and their cloud based on where the data lives. The hybrid execution is the clever part. It's also the part that means MotherDuck is not interchangeable with plain DuckDB.

A few things that surprise people coming from open-source DuckDB:

The SQL dialect is mostly compatible but adds MotherDuck-specific extensions. Cross-database queries between your local DuckDB and MotherDuck's cloud use syntax that doesn't exist in vanilla DuckDB. If your queries lean on those features, migrating off MotherDuck takes work.

The pricing model is compute-unit based. Predicting cost requires understanding when queries run locally versus in the cloud, which involves their hybrid execution logic.

Lock-in is real even though it doesn't look like it. You can export your data anytime (it's just DuckDB underneath), but rewriting queries that relied on MotherDuck-specific features takes effort.

None of this is bad. MotherDuck is a real product solving real problems. It's just not what some people think they're signing up for when they search "hosted DuckDB."

Option 1: Layerbase Cloud

Layerbase Cloud hosts plain DuckDB. No hybrid execution, no proprietary SQL extensions, no compute-unit pricing. Just DuckDB behind a PostgreSQL wire protocol proxy so you can connect with any standard pg client.

psql "postgresql://layerbase:password@<your-host>.cloud.layerbase.dev/duck1?sslmode=require&sslnegotiation=direct"

How this works: DuckDB itself doesn't have a server. It's embedded. To make it network-accessible, we run duckgres (a PostgreSQL-wire proxy in front of DuckDB) inside the container. From the client side, it looks like a Postgres database. From the server side, queries are running through the DuckDB engine with its full feature set.

What you get:

• Standard DuckDB SQL, no extensions or rewrites.
• Direct CSV/Parquet querying from S3 or HTTP works the same as local DuckDB.
• PostgreSQL drivers everywhere. Drizzle ORM, Prisma's PG adapter, the pg npm package, psql, DBeaver, all work.
• Scale-to-zero for free instances. DuckDB cold-starts fast.

What you don't get:

• MotherDuck's hybrid execution. If your workload requires splitting work between a local DuckDB and a cloud one, this isn't a substitute. For pure cloud workloads it's fine.
• Multi-user concurrency at MotherDuck's scale. DuckDB is single-writer, multiple-reader by design. For a personal or small-team analytics workload, this is rarely the bottleneck. For a large customer-facing analytics product, ClickHouse is the better fit.

For anyone who likes DuckDB and wants it managed without rewriting queries, this is the option to try first.

Option 2: Run it locally with the Layerbase CLI

DuckDB is an embedded database, so "running it" usually means import duckdb in Python or pnpm add duckdb in Node. That works great for most use cases. But sometimes you want DuckDB as a process you can connect to from multiple clients on your laptop, and that's what the Layerbase CLI (formerly SpinDB) gives you. (What is the Layerbase CLI?)

npm i -g layerbase     # npm
pnpm add -g layerbase  # pnpm

Create a DuckDB instance:

lbase create duck1 -e duckdb --start

Get the connection URL:

lbase url duck1

postgresql://127.0.0.1:5432/duck1

That's a real DuckDB running behind a PG-wire proxy on your machine. Same setup as Layerbase Cloud, but local. You can connect from any tool that speaks PostgreSQL: psql, DBeaver, TablePlus, the pg npm package, the Postgres adapter in your favorite ORM.

lbase stop duck1
lbase start duck1
lbase list

Use cases where this beats the embedded DuckDB library:

• You want to run queries from multiple clients at once (e.g., a Jupyter notebook and a Node script).
• You want to inspect DuckDB tables with a GUI database tool without writing a Python script.
• You're testing what a Postgres-wire DuckDB feels like before deploying to Layerbase Cloud.

For pure scripting and ETL, the embedded library is still simpler.

Option 3: Layerbase Desktop

Layerbase Desktop wraps SpinDB in a desktop app. For DuckDB, it's especially useful because it gives you a stable hostname/port for a local instance you can leave running. New instance, pick DuckDB, copy the connection string into TablePlus or DBeaver.

If you do a lot of ad-hoc analytical work and don't want to fight with Python environments or Jupyter kernels just to run a SELECT, this is a comfortable way to keep a DuckDB around for query work.

Option 4: Embed DuckDB in your app

This is the option DuckDB was actually designed for. pnpm add duckdb (or the Python, Go, Rust, or .NET equivalent) and you have a database. No server, no connection string, no managed anything.

import duckdb from 'duckdb'

const db = new duckdb.Database(':memory:')
const conn = db.connect()

conn.all(`
  SELECT category, SUM(quantity * price) AS revenue
  FROM read_csv_auto('sales.csv')
  GROUP BY category
  ORDER BY revenue DESC
`, (err, rows) => {
  if (err) throw err
  console.log(rows)
})

That's a complete DuckDB program. No daemon to start, no port to allocate. The data lives in a single .duckdb file (or in memory if you pass :memory:), and your application talks to it through the embedded API.

When this is the right choice:

• The data lives in the same process as the code that queries it.
• You don't need network access to the database.
• You're doing batch analytical work, not serving concurrent dashboard users.

For data engineering pipelines, internal CLI tools, and analytics inside web app backends where you're loading data on the fly, embedded DuckDB is almost always the right answer. The managed and local-server options become useful when the embedded model doesn't fit (multiple processes, GUI tools, network access).

Option 5: DuckDB on a single VM

If you want to self-host DuckDB as a network-accessible service, run duckgres yourself on a small VM. It's a Postgres-wire proxy that wraps a DuckDB file. Stand up a VM, install DuckDB, run duckgres, point it at your DuckDB file, expose the Postgres port.

You're doing roughly what Layerbase Cloud does internally for DuckDB instances. The trade-off is that you're now responsible for TLS, backups, restarts, monitoring, and disk pressure. For most people, the managed version is worth the price.

FAQ

Is MotherDuck the same thing as DuckDB?

No. MotherDuck is two things at once: a hosted DuckDB you can query, and a proprietary hybrid execution engine that splits work between your laptop and their cloud based on where the data lives. The hybrid part is the clever part, and it is also the part that makes MotherDuck not interchangeable with plain DuckDB, because it comes with MotherDuck-specific SQL extensions on top of the standard dialect.

How much does MotherDuck cost?

The Lite plan starts at $0 and includes 10 GB of storage and 10 hours of Pulse compute a month. Business is $250 per organization per month plus usage. Compute is billed per second by instance size, running from $0.60 per hour for Pulse up to $2.40 for Standard, $4.80 for Jumbo, $12.00 for Mega and $24.00 per hour for Giga, with storage at $0.04 per GB-month. Predicting the bill means understanding when a query runs locally versus in their cloud, which is a function of their hybrid execution logic rather than something you set.

MotherDuck rates verified 2026-08-25 from motherduck.com/product/pricing.

Can I run DuckDB as a server?

Not on its own, because DuckDB is embedded and has no server component. The usual approach is to put a Postgres-wire proxy in front of it: duckgres wraps a DuckDB file and makes it look like a Postgres database to any client. That is what runs inside the container on Layerbase Cloud, and it is also what you would install yourself on a VM.

How do I connect to hosted DuckDB?

With any PostgreSQL client, because the wire protocol in front is Postgres. psql, DBeaver, TablePlus, the pg npm package, Drizzle ORM and Prisma's PG adapter all work without anything DuckDB-specific. Queries still execute in the DuckDB engine with its full feature set, so direct CSV and Parquet reads from S3 or HTTP behave exactly as they do locally.

Is it hard to migrate off MotherDuck?

Getting the data out is easy; getting the queries out is the work. Your data is DuckDB underneath and you can export it whenever you like. What takes effort is rewriting anything that leaned on MotherDuck-specific features, cross-database queries between a local DuckDB and their cloud most of all, since that syntax does not exist in vanilla DuckDB.

Should I use DuckDB or ClickHouse?

DuckDB for personal and small-team analytics, ClickHouse when the workload is a large customer-facing analytics product. DuckDB is single-writer and multiple-reader by design, which is rarely the bottleneck for a notebook, a pipeline or an internal dashboard, and squarely the bottleneck when many users are hitting it concurrently.

Which one to pick

The general framing: MotherDuck is great when MotherDuck-specific features are the reason you're picking it. Plain hosted DuckDB is great when you want DuckDB itself and don't want to learn a new product surface to get it. Both are legitimate choices.

If you want a deeper walkthrough of DuckDB itself, getting started with DuckDB covers the engine in detail with a real example, and the ClickHouse vs DuckDB comparison lays out when to pick DuckDB versus a production analytics server.