DuckDB and DuckLake,
as a governed service.
Quack on Demand puts one multi-tenant, access-controlled, horizontally-scaled SQL endpoint in front of many DuckDB engines sharing DuckLake catalogs.
# One endpoint, JDBC / ADBC / ODBC / PyArrow
conn = flight_sql.connect(
"grpc+tls://gateway:31338",
db_kwargs={
"username": "alice", "password": "•••",
tenant: "acme", pool: "analytics"})
# routed to the least-loaded node for the tenant
cur = conn.cursor()
cur.execute("SELECT count(*) FROM orders")
cur.fetchone()
(1500000,)
What the gateway adds to DuckDB
Multi-tenant by design
Tenants own databases and pools of DuckDB nodes. Each tenant gets its own catalog, users, and auth provider, isolated by storage layout and by access control.
Access control on every query
Authentication via database, JWT, or OIDC, plus role-based, per-statement table permissions. A statement is authorized before it ever reaches a node.
Horizontal scale, one endpoint
Statements are classified read or write and routed to the least-loaded node that can serve them, with transaction pinning and retry-on-failure, all behind a single Flight SQL endpoint.
DuckLake catalogs
Nodes read and write Parquet through shared DuckLake catalogs on a filesystem or S3-compatible object store, so a pool presents one consistent view.
Federation, same ACL
Attach external catalogs, Postgres, S3, Iceberg, anything DuckDB can ATTACH, under the same SQL surface and the same role-based access control.
Built to operate
Prometheus and cloud metrics, a config manifest for backup and restore, and an admin UI for tenants, pools, users, and grants.
Reach for it when sharing matters.
Many users on shared DuckDB/DuckLake data, access control on every query, horizontal scale, tenant isolation, or federation. Querying one local file? Use DuckDB directly.