<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>musings on Mooncake</title>
    <link>https://mooncake.pgsty.com/tags/musings/</link>
    <description>Recent content in musings on Mooncake</description>
    <generator>Hugo</generator>
    <language>en-US</language>
    
    
    
      <lastBuildDate>Thu, 05 Nov 2026 19:17:16 +0800</lastBuildDate>
    
    
      <atom:link href="https://mooncake.pgsty.com/tags/musings/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
        <title>No, Iceberg won’t fix your data stack.</title>
        <link>https://mooncake.pgsty.com/blog/post/iceberg-is-terrible/</link>
        <pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate>
        
        <guid>https://mooncake.pgsty.com/blog/post/iceberg-is-terrible/</guid>
        <description>&lt;p&gt;Life is expectations vs reality. Here is one for Apache &lt;a href=&#34;https://iceberg.apache.org/&#34;&gt;Iceberg&lt;/a&gt; – a favorite amongst the data community.&lt;/p&gt;&#xA;&lt;h2 id=&#34;expectations-iceberg-is-the-solution-to-all-my-data-pains&#34;&gt;Expectations: Iceberg is the solution to all my data pains&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;See, the core of Iceberg is pretty neat:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;Keep all data in object storage in open file formats like Parquet.&lt;/li&gt;&#xA;&lt;li&gt;Fool any execution engine (DuckDB, ClickHouse, Spark, Snowflake, etc.) into thinking these files are a table and query them with SQL directly.&lt;/li&gt;&#xA;&lt;li&gt;&lt;em&gt;[Ongoing progress]&lt;/em&gt; Get exceptional performance on these tables, without having to load data into a system-specific format.&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;And with clever design you get:&lt;/p&gt;</description>
      </item>
    <item>
        <title>HTAP is Dead</title>
        <link>https://mooncake.pgsty.com/blog/post/htap-is-dead/</link>
        <pubDate>Mon, 05 May 2025 00:00:00 +0000</pubDate>
        
        <guid>https://mooncake.pgsty.com/blog/post/htap-is-dead/</guid>
        <description>&lt;p&gt;This blog is inspired by Jordan Tigani&amp;rsquo;s blog titled &lt;a href=&#34;https://motherduck.com/blog/big-data-is-dead/&#34;&gt;&amp;ldquo;Big Data is Dead&amp;rdquo;&lt;/a&gt;. Jordan and I actually spent some time building an HTAP database at SingleStore.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-good-old-days-80s&#34;&gt;The good old days (&amp;rsquo;80s)&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;Back in the &amp;rsquo;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.&lt;/p&gt;</description>
      </item>
    <item>
        <title>What does Analytics in Postgres really mean?</title>
        <link>https://mooncake.pgsty.com/blog/post/why-postgres-analytics/</link>
        <pubDate>Sun, 23 Mar 2025 00:00:00 +0000</pubDate>
        
        <guid>https://mooncake.pgsty.com/blog/post/why-postgres-analytics/</guid>
        <description>&lt;p&gt;Few areas in databases are hotter right now than extending Postgres to support analytics queries. This isn&amp;rsquo;t a particularly novel area either –– there have been plenty of attempts in the last decade:&lt;/p&gt;&#xA;&lt;img class=&#34;td-image&#34; src=&#34;https://mooncake.pgsty.com/images/blog/pganalytics-timeline.jpg&#34; alt=&#34;Timelines&#34; loading=&#34;lazy&#34; decoding=&#34;async&#34;&gt;&lt;p&gt;Here is what it means to our customers –– and why the problem remains largely unsolved, despite our first attempt with &lt;a href=&#34;https://mooncake.pgsty.com/docs/intro/&#34;&gt;&lt;code&gt;pg_mooncake&lt;/code&gt;&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;h2 id=&#34;level-0-i-just-run-analytics-queries-on-my-postgres-tables&#34;&gt;Level 0: I just run analytics queries on my Postgres tables&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;You&amp;rsquo;ll be surprised how far this can go with proper indexes, statistics, query tuning, and materialized views—people really overthink this.&lt;/p&gt;</description>
      </item>
    <item>
        <title>Things we learnt</title>
        <link>https://mooncake.pgsty.com/blog/post/things-we-learnt/</link>
        <pubDate>Sun, 08 Sep 2024 00:00:00 +0000</pubDate>
        
        <guid>https://mooncake.pgsty.com/blog/post/things-we-learnt/</guid>
        <description>&lt;p&gt;The title should really be &amp;ldquo;Things we learnt, the hard way&amp;rdquo;.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;h2 id=&#34;1-if-postgres-can-do-it-postgres-will-do-it&#34;&gt;1. If Postgres can do it, Postgres will do it&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;We&amp;rsquo;ve seen this one plenty of times now – it started with JSON, then moved to geo-spatial (&lt;code&gt;PostGIS&lt;/code&gt;), and now we&amp;rsquo;re seeing it with vector search (&lt;code&gt;pgvector&lt;/code&gt;).&lt;/p&gt;</description>
      </item>
    
  </channel>
</rss>
