postgresql 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.

but, my Postgres (+ lakehouse) is free

Fri, 13 Jun 2025 00:00:00 +0000

Disclaimer: Your Postgres and Lakehouse are free and open too. You don’t need to be (or spend like) a giant to use them.

Why Postgres + Lakehouse?

Reason #1: If you believe in AI, this is the agent stack

Agents need memory. Both working memory and longer-term knowledge.

Working memory has to be instant, reliable, and accurate, just like app state. What’s the best place to store it? Postgres. That’s true for both apps and agents. This state is typically tied to an individual user, tenant, or agent.

HTAP is Dead

Mon, 05 May 2025 00:00:00 +0000

This blog is inspired by Jordan Tigani’s blog titled “Big Data is Dead”. Jordan and I actually spent some time building an HTAP database at SingleStore.

The good old days (’80s)

Back in the ’80s, one relational database did everything. Transactions (OLTP) during the day and reports after hours (OLAP). Databases like Oracle V2 and IBM DB2 ran OLTP and OLAP on the same system; largely because data sets still fit on a few disks and compute was costly.

What does Analytics in Postgres really mean?

Sun, 23 Mar 2025 00:00:00 +0000

Few areas in databases are hotter right now than extending Postgres to support analytics queries. This isn’t a particularly novel area either –– there have been plenty of attempts in the last decade:

Here is what it means to our customers –– and why the problem remains largely unsolved, despite our first attempt with pg_mooncake.

Level 0: I just run analytics queries on my Postgres tables

You’ll be surprised how far this can go with proper indexes, statistics, query tuning, and materialized views—people really overthink this.

Clickbench says Postgres is a great analytics database

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

TL;DR: We spent a few months optimizing PostgreSQL and made it to the Top 10 on ClickBench, a benchmark typically dominated by specialized analytics databases.

What’s more, all compute is within Postgres, and all tables are managed directly by PostgreSQL—it’s not a simple wrapper. This is the story of pg_mooncake.

What Is ClickBench?

ClickBench is the definitive benchmark for real-time analytics databases, originally designed to showcase the performance of ClickHouse. It evaluates databases on their ability to handle real-world analytics workloads, including high-volume table scans and complex aggregations.

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.

pg_mooncake: Fast Analytics in Postgres with Columnstore Tables and DuckDB

Wed, 06 Nov 2024 00:00:00 +0000

pg_mooncake brings columnstore tables with DuckDB execution to Postgres for fast analytics.

It supports transactional inserts, updates, and deletes, just like regular Postgres tables. Data is written with Delta Lake (and Apache Iceberg in v0.2+) table metadata, allowing it to be queried outside of Postgres.

Why another Postgres analytics extension?

Postgres is the most popular database these days, but it’s bad at analytics. Numerous attempts have been made to address this, but with limited success so far. Fast analytics require a distinct set of techniques, such as columnar storage, vectorized execution, and late materialization, etc. Early projects like Citus & Timescale added columnar storage, but there was no good vectorized execution to leverage the format.

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).