HN Reader

The DuckDB-as-a-storage-engine approach is clever because it lets you keep your existing MySQL connections, tooling, and replication topology while routing analytical queries to a columnar engine underneath. That's a much easier sell operationally than standing up a separate analytics database and building a sync pipeline. The real question is how they handle consistency between the InnoDB and DuckDB copies of the same data, that's where every hybrid OLTP/OLAP system either shines or quietly loses rows.

Curious how it stacks up to pg_duckdb. (pg_duckdb seems pretty clean, due to Postres' powerful extension mechanisms)

FoundationDB Record layer doesn't get much attention here but I have found that all my use cases are satisfied by it.

And I get the benefit of resiliency and DR for free.

If you are a developing for My SQL and you are using Java/kotlin/closure/scala consider this as well.

Does this feed DuckDb continuously data from transactional workloads, akin to what SAP hana does? If so that would be huge - people spend lots of time trying to stitch transactional data to warehouses using Kafka/debezium.

BTW, Would be great to hear apavlo’s opinion on this.

having an embedded column database for analytics in your traditional db is a massive win for productivity + operations simplicity.

at the moment I use PG + Tiger Data - couldn't find a mysql equivalent

so this as one.

Wonder how DuckDB compares here to what TiDB did using Clickhouse instead

On a drive-by-glance it looks like if you had a tighter integrated version of PSQL FDW for DuckDB and Vector Storage - meets Vespa. I find it interesting they went with extending MySQL instead of FDW route on PSQL?

How I see SQL databases evolving over the next 10 years:

    1. integrate an off the shelf OLAP engine
       forward OLAP queries to it
       deal with continued issues keeping the two datasets in sync
    2. rebase OLTP and OLAP engines to use a unified storage layer
       storage layer supports both page-aligned row-oriented files and column-oriented files and remote files
       still have data and semantic inconsistencies due to running two engines
    3. merge the engines
       policy to automatically archive old records to a compressed column-oriented file format
       option to move archived record files to remote object storage, fetch on demand
       queries seamlessly integrate data from freshly updated records and archived records
       only noticeable difference is queries for very old records seem to take a few seconds longer to get the results back

HTAP is here! It seems like these hybrid databases are slowly gaining adoption which is really cool to see.

The most interesting part of this is the improvements to transaction handling that it seems they've made in https://github.com/alibaba/AliSQL/blob/master/wiki/duckdb/du... (its also a good high level breakdown of MySQL internals too). Ensuring that the sync between the primary tables and the analytical ones are fast and most importantly, transactional, is awesome to see.

How easy will this be to combine with https://github.com/mysql/mysql-operator for deployment?

the commits history looks a bit weird, 2 commits in 2022, 1 in 2024 and 2025, and 5 in 2026 (one is "First commit, Support DuckDB Engine")

I get the feeling that Oracle is abandonning MySQL.

Let's all hope Ali will pick it up :)

I'm fully invested on Postgres though.

I hope the poor devs that built this wernt subjected to the brutal 996 culture (9am-9pm, 6 days per week)