DuckDB 2.0 is now on Layerbase

DuckDB 2.0 is now available on Layerbase Cloud, and it is the default for new DuckDB databases. Create a database, open the query console or copy its connection string, and start writing analytical SQL.

You can use it to explore sales data, build reporting queries, investigate product usage, or give an internal tool a hosted analytics database. Layerbase manages the database; you bring the data and the questions.

This release also sets the stage for what comes next: DuckLake and integrations with PostgreSQL, Amazon S3, Cloudflare R2, and MariaDB are coming soon. More on those below, including what they will make possible.

A hosted DuckDB you can connect to

DuckDB is often used inside a local script or notebook. On Layerbase, you get a hosted database with a network connection, so your queries can run from your application, a SQL client, or the dashboard.

Create a DuckDB database, name it analytics, and keep version 2.0 selected. The exact engine version is 2.0.0.

For the examples below, open its query console. If you prefer a terminal, copy the connection string from Quick Connect and use it with psql:

# Set DATABASE_URL to the connection string copied from Quick Connect.
psql "$DATABASE_URL"

Layerbase serves DuckDB over the PostgreSQL wire protocol. That lets you connect with PostgreSQL clients while executing DuckDB SQL. It does not turn the database into PostgreSQL or make every PostgreSQL extension and ORM feature compatible. The DuckDB connection guide covers connection settings and imports.

Example: find which channels bring in revenue

Suppose you want to compare sales from organic search, email, and paid campaigns. Run these statements in your new analytics database:

CREATE TABLE launch_orders (
    order_id INTEGER,
    customer_id INTEGER,
    ordered_at DATE,
    channel VARCHAR,
    amount DECIMAL(10, 2)
);

INSERT INTO launch_orders VALUES
    (1, 101, '2026-10-01', 'organic', 120.00),
    (2, 102, '2026-10-01', 'email',    80.00),
    (3, 101, '2026-10-02', 'email',    60.00),
    (4, 103, '2026-10-02', 'paid',    200.00),
    (5, 104, '2026-10-03', 'organic', 150.00),
    (6, 102, '2026-10-03', 'email',    40.00);

Now group those orders by channel:

SELECT
    channel,
    count(*) AS orders,
    sum(amount) AS revenue,
    round(avg(amount), 2) AS average_order_value
FROM launch_orders
GROUP BY channel
ORDER BY revenue DESC;

channel  orders  revenue  average_order_value
organic       2   270.00               135.00
paid          1   200.00               200.00
email         3   180.00                60.00

Email generated the most orders, but organic search brought in more revenue. This is the kind of question a reporting page can answer with one query. To investigate profitability, you could add campaign costs and compare them with revenue; order totals alone do not tell you the return on ad spend.

Example: identify repeat customers

Using the same table, find customers who placed more than one order:

SELECT
    customer_id,
    count(*) AS orders,
    sum(amount) AS lifetime_revenue,
    min(ordered_at) AS first_order,
    max(ordered_at) AS latest_order
FROM launch_orders
GROUP BY customer_id
HAVING count(*) > 1
ORDER BY lifetime_revenue DESC;

Customers 101 and 102 appear in the result, with revenue of 180.00 and 120.00 respectively. You could use this query for a customer-success report or as the starting point for a repeat-purchase analysis.

Here, “lifetime” means the history loaded into this table. For a real report, import the full order history you want to measure.

Example: build a daily revenue trend

Window functions let you keep the daily totals and calculate a running total alongside them:

WITH daily_revenue AS (
    SELECT ordered_at, sum(amount) AS revenue
    FROM launch_orders
    GROUP BY ordered_at
)
SELECT
    ordered_at,
    revenue,
    sum(revenue) OVER (
        ORDER BY ordered_at
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS cumulative_revenue
FROM daily_revenue
ORDER BY ordered_at;

ordered_at  revenue  cumulative_revenue
2026-10-01   200.00              200.00
2026-10-02   260.00              460.00
2026-10-03   190.00              650.00

That result can feed a chart in an internal dashboard or a scheduled report in your own application. These examples use a small dataset so you can run them immediately. You can also bring your own data through the query console's import workflow.

Coming soon: connect analytics to more of your data

Today's launch is hosted DuckDB 2.0. The following Layerbase integrations are coming soon, with setup instructions and availability details to follow:

For example, a commerce team could analyze order data from PostgreSQL or MariaDB alongside historical exports in object storage. A product team could keep event datasets in S3 or R2 and use DuckDB to answer usage questions. These are the workflows we want the upcoming integrations to make easier.

DuckLake adds a catalog to data stored across files, providing a lakehouse model that works with object storage. Our planned DuckLake integration will extend the story beyond a single hosted DuckDB database.

We will document each integration's supported operations and setup when it ships. This announcement does not promise automatic replication or a release date for those integrations.

Existing databases keep their versions

New Cloud databases default to 2.0.0. If you need the 1.x line, select 1.5 in the picker to create a database running 1.5.6; API requests for major version 1 also resolve to 1.5.6.

Existing databases keep their exact versions. Changing the default for new databases does not force an upgrade of your existing data.

Create a DuckDB 2.0 database and try the queries above. You can start with a few rows today, build the reports you need, and follow along as the new integrations arrive.