Pranav Aurora on Mooncake

Mooncake is joining Databricks!

Wed, 01 Oct 2025 00:00:00 +0000

Thirteen months ago, we started Mooncake to bring the data intelligence stack that powers giants like OpenAI to every vibe-coded app and developer. From first prompt to IPO.

Today, we’re joining forces with Databricks. The mission continues: make Lakebase and the Lakehouse feel like one.

For a decade, we thought the final form of a database was one that could do it all. Fast updates, transactions, analytics. For database people, this was HTAP. It never quite landed. Zhou and Cheng built it. Pranav tried to sell it. It was hard.

Mooncake: a real-time storage engine for Apache Iceberg

Mon, 11 Aug 2025 00:00:00 +0000

This technical overview assumes familiarity with Apache Iceberg, an open table format for analytical datasets. Iceberg is part of the general “Lakehouse” movement, where users:

Store large datasets using open file formats (Parquet + Metadata) in Object Storage
Query them directly by engines like Spark, Trino, Flink, and DuckDB using SQL
Get the benefits of ‘database features’ like schema evolution & time-travel
Scale practically infinitely, and aren’t locked into a vendor

Iceberg was built for slow-changing data + batch analytics & processing. That world is pretty clear and only improving with engines getting better at reading open formats.

pg_mooncake v0.2: what we're cooking

Tue, 11 Feb 2025 00:00:00 +0000

With v0.1, we proved that Postgres can deliver great analytics performance. Our approach combined two key pieces—DuckDB vectorized engine and a columnstore table—making pg_mooncake the only extension in Postgres that integrates both.

The results speak for themselves: pg_mooncake ranks in ClickBench’s top 10, and we built the fastest Parquet-based engine along the way.

Now, with v0.2, we’re tackling the next big challenge; we call it out-of-the-box analytics.

First, why in-Postgres analytics?

Applications often have their first analytics needs far before they have their first data warehouse or analytics system.

How to improve DuckDB performance on Parquet

Wed, 22 Jan 2025 00:00:00 +0000

Last week, we ran ClickBench on Postgres and ranked in the top 10. We showed that Postgres can be extended with pg_mooncake to support serious analytics workloads.

In the announcement, we got a lot of questions on how pg_mooncake outperforms DuckDB on Parquet files even though internally, it embeds DuckDB in Postgres and stores data in Parquet format.

See also the discussion on X / Twitter.

The best part: pg_mooncake does not modify DuckDB at all…

The easiest way to Analytics in Postgres: pg_mooncake v0.1

Sat, 11 Jan 2025 00:00:00 +0000

We announced pg_mooncake to the world on Day 60.

Today, Day 131, pg_mooncake comes out of beta.

pg_mooncake wins on ease and performance. So, we doubled down for v0.1. That’s it.

The Easiest Way to Fast Analytics in Postgres

With a native columnstore table in Postgres, pg_mooncake brings familiar table semantics to the way you run analytics. Columnstore tables support transactional operations like INSERT, SELECT, UPDATE, DELETE, and COPY, alongside joins with regular Postgres heap tables.

pg_mooncake 🤝 drizzle: typed SDKs for your analytic workloads

Wed, 08 Jan 2025 00:00:00 +0000

A thing that surprised us in the pg_mooncake launch was how much developers cared about ORMs for their analytical workloads. We saw two typical requests:

“I have a bunch of Parquet files. I want full ORM support over them.”
“I use Drizzle/Prisma for my transactional database. I also want to use it for my analytics and dashboards.”

We’ve always believed that columnar storage in Postgres must look and feel like a regular heap table. It’s where we innovated with pg_mooncake columnstore tables; you can run transactions, updates, deletes, and joins with heap tables.

pg_mooncake + Neon: serverless analytics in Postgres

Tue, 07 Jan 2025 00:00:00 +0000

pg_mooncake launched in beta two months ago. It adds columnar storage and a vectorized engine to Postgres.

Over the last two months, with our customers, we’ve realized we accidentally built the best serverless database for analytics. Here’s the story:

1. pg_mooncake 🤝 Neon storage engine

Neon innovated significantly on its storage engine.

There’s a great thread by Nikita on this. This storage engine is how Neon can achieve true separation of storage & compute. This leads to an exceptional DX around branching, scale-to-zero, read replicas, instant provisioning… All of these are goodies of a true serverless Postgres.

Mooncake: next-gen search and analytic systems

Wed, 30 Oct 2024 00:00:00 +0000

We are Zhou, Cheng, and Pranav. And we’ve spent the last decade building databases at MemSQL (now SingleStore).

We love complex systems, deep-tech engineering, and naturally – physics 🙂 Data systems, much like physics, are built on certain principles. The principles need to be unanimous and durable.

Building systems that are simply ’technically’ better is futile. The success of a data system depends on the principles it embodies, and changing them along the way is extremely difficult. Closed-source companies can’t go to open source and expect adoption. Databases can’t just abandon their storage format and be effective stateless engines.

Things we learnt

Sun, 08 Sep 2024 00:00:00 +0000

The title should really be “Things we learnt, the hard way”.

As we start this new journey, we spent some time thinking about the axioms of data today. These are things we (or no one for that matter) can dispute.

1. If Postgres can do it, Postgres will do it

We’ve seen this one plenty of times now – it started with JSON, then moved to geo-spatial (PostGIS), and now we’re seeing it with vector search (pgvector).