The performance of DuckDB. The reliability you'd expect from a database that runs in production.
DuckDB is a phenomenal engine. Putting it into an app with real users is another story — concurrent reads, configuration per connection, query routing, error handling under load. We've spent months on that so you don't have to. Drop-in DuckDB-compatible Python SDK, remote execution, built for applications, not dashboards.
Same API. Same query semantics. Just remote execution that scales with your app.
import duckdb
conn = duckdb.connect("my_database.db")
result = conn.execute(
"SELECT user_id, COUNT(*) FROM events GROUP BY 1"
).fetchall()import duckgresql
conn = duckgresql.connect(
token="dkgql_...",
database="my_database",
)
result = conn.execute(
"SELECT user_id, COUNT(*) FROM events GROUP BY 1"
).fetchall()Same fetch methods (fetchall, fetchone, fetchdf, fetch_arrow_table). Same query language. Async support included. Python SDK first. JavaScript / TypeScript on the way.
Duckgresql comes from two years of running DuckDB in production. The migration from Postgres fixed analytics overnight — and opened a harder problem: making DuckDB behave under real concurrent traffic.
The managed options out there are built for analytics teams running on top of a data lake — not for an application that needs DuckDB to behave under real traffic. Duckgresql exists to fill that gap.
A DuckDB-compatible client points your application at a remote engine pool. The operational layer — connection management, configuration, query routing, error handling under concurrent load — runs on our side.
Replace import duckdb with import duckgresql. Same execution methods, same query semantics, same return types. Async-friendly, pandas-friendly, Arrow-friendly.
Connection pooling, memory configuration, query routing under concurrent load, graceful error handling. The work that takes months to get right when you DIY DuckDB in production.
Migrating from Postgres to DuckDB gradually? Need to query both systems with one SQL surface? Use the Postgres bridge. If you don't need it, ignore it — it's not in the hot path.
We're in private beta. This is the surface we're hardening with our first design partners.
Connect, execute, fetchall, fetchone, fetchdf, fetch_arrow_table, async support. The methods you already use, pointed at a remote engine.
Multiple clients, multiple queries, all hitting tuned DuckDB engines without saturating each other. The configuration work is already done.
Submit an analytical query, get a job ID, poll for completion. For the queries that take seconds or minutes, not milliseconds.
Migrate from Postgres to DuckDB gradually, or query both with the same SQL. Use it when you need it. Skip it when you don't.
We're being deliberately narrow during the beta. If this sounds like you, we want to talk.
You've seen what DuckDB can do on a single laptop, on a single notebook, on a single dashboard. You want to bring that performance to an app where dozens or hundreds of users are filtering, aggregating, exploring concurrently. You don't want to spend three months tuning configuration, writing routing logic, handling edge cases when a query OOMs and takes others down with it. You want to focus on your product.
Not your situation? We'll get to other use cases after the beta. Reach out anyway if you're curious — but we're prioritizing the profile above for now.
We're taking on five teams as design partners for the private beta. Free during the program. Direct access to the founder. In exchange, we ask for a 30-minute call every two weeks so we can build this with your real workload in mind, not in a vacuum.
We'll prioritize teams already running DuckDB in or near production.
We read each one ourselves. If you're a fit for one of the five slots, we'll set up a call within the week.