<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Announcement | From monolith to Lakebase to LTAP: rethinking the database from storage up in Lakebase Articles</title>
    <link>https://community.databricks.com/t5/lakebase-articles/announcement-from-monolith-to-lakebase-to-ltap-rethinking-the/m-p/162942#M72</link>
    <description>&lt;P&gt;&lt;SPAN&gt;Databricks has shared a deeper look at how &lt;/SPAN&gt;&lt;STRONG&gt;Lakebase&lt;/STRONG&gt;&lt;SPAN&gt; rethinks database architecture by separating Postgres compute from storage, and how that design leads to &lt;/SPAN&gt;&lt;STRONG&gt;LTAP&lt;/STRONG&gt;&lt;SPAN&gt;, a model where transactions and analytics can run on the same underlying data without traditional ETL pipelines or separate copies.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size="4"&gt;&lt;STRONG&gt;What’s new&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;
&lt;UL&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Why traditional databases hit limits&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks argues that many database pain points trace back to a monolithic design where the write-ahead log and data files live on one machine, making durability, scaling, replicas, and workload isolation harder than they need to be.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Lakebase separates compute from storage&lt;/STRONG&gt;&lt;SPAN&gt;: In Lakebase, Postgres compute becomes stateless while storage is externalized, with data living in low-cost cloud object storage and compute scaling independently on top.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;That architecture unlocks practical benefits&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks highlights elastic serverless compute, durable storage, instant branching and cloning, and a more flexible operating model for transactional workloads.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Lakebase also improves the path to LTAP&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks says LTAP unifies transactional and analytical processing at the storage layer, so operational and analytical workloads can work from a single governed copy of data in the lake instead of relying on ETL, replicas, or hidden sync pipelines.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Storage-layer unification is the key idea&lt;/STRONG&gt;&lt;SPAN&gt;: Rather than forcing one engine to do everything, Databricks keeps Postgres for transactions and lakehouse engines for analytics, while making the data underneath shared, current, and governed through Unity Catalog.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;&lt;SPAN&gt;Databricks also points to performance work already happening in Lakebase itself. In one architecture update, the company said Lakebase can deliver up to &lt;/SPAN&gt;&lt;STRONG&gt;5x faster Postgres writes&lt;/STRONG&gt;&lt;SPAN&gt; by pushing certain recovery-related work into its distributed storage layer instead of leaving it on the compute node.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="p8i6j01 paragraph"&gt;&lt;A style="background-color: #ff3621; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; font-weight: bold; display: inline-block;" href="https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage" target="_blank" rel="noopener"&gt; &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_right:"&gt;👉&lt;/span&gt; Read the full post here &lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Tue, 14 Jul 2026 12:32:44 GMT</pubDate>
    <dc:creator>Tushar_Parekar</dc:creator>
    <dc:date>2026-07-14T12:32:44Z</dc:date>
    <item>
      <title>Announcement | From monolith to Lakebase to LTAP: rethinking the database from storage up</title>
      <link>https://community.databricks.com/t5/lakebase-articles/announcement-from-monolith-to-lakebase-to-ltap-rethinking-the/m-p/162942#M72</link>
      <description>&lt;P&gt;&lt;SPAN&gt;Databricks has shared a deeper look at how &lt;/SPAN&gt;&lt;STRONG&gt;Lakebase&lt;/STRONG&gt;&lt;SPAN&gt; rethinks database architecture by separating Postgres compute from storage, and how that design leads to &lt;/SPAN&gt;&lt;STRONG&gt;LTAP&lt;/STRONG&gt;&lt;SPAN&gt;, a model where transactions and analytics can run on the same underlying data without traditional ETL pipelines or separate copies.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;FONT size="4"&gt;&lt;STRONG&gt;What’s new&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/P&gt;
&lt;UL&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Why traditional databases hit limits&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks argues that many database pain points trace back to a monolithic design where the write-ahead log and data files live on one machine, making durability, scaling, replicas, and workload isolation harder than they need to be.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Lakebase separates compute from storage&lt;/STRONG&gt;&lt;SPAN&gt;: In Lakebase, Postgres compute becomes stateless while storage is externalized, with data living in low-cost cloud object storage and compute scaling independently on top.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;That architecture unlocks practical benefits&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks highlights elastic serverless compute, durable storage, instant branching and cloning, and a more flexible operating model for transactional workloads.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Lakebase also improves the path to LTAP&lt;/STRONG&gt;&lt;SPAN&gt;: Databricks says LTAP unifies transactional and analytical processing at the storage layer, so operational and analytical workloads can work from a single governed copy of data in the lake instead of relying on ETL, replicas, or hidden sync pipelines.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;LI style="font-weight: 400;" aria-level="1"&gt;&lt;STRONG&gt;Storage-layer unification is the key idea&lt;/STRONG&gt;&lt;SPAN&gt;: Rather than forcing one engine to do everything, Databricks keeps Postgres for transactions and lakehouse engines for analytics, while making the data underneath shared, current, and governed through Unity Catalog.&lt;/SPAN&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;&lt;SPAN&gt;Databricks also points to performance work already happening in Lakebase itself. In one architecture update, the company said Lakebase can deliver up to &lt;/SPAN&gt;&lt;STRONG&gt;5x faster Postgres writes&lt;/STRONG&gt;&lt;SPAN&gt; by pushing certain recovery-related work into its distributed storage layer instead of leaving it on the compute node.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="p8i6j01 paragraph"&gt;&lt;A style="background-color: #ff3621; color: white; padding: 10px 20px; text-decoration: none; border-radius: 5px; font-weight: bold; display: inline-block;" href="https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage" target="_blank" rel="noopener"&gt; &lt;span class="lia-unicode-emoji" title=":backhand_index_pointing_right:"&gt;👉&lt;/span&gt; Read the full post here &lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 14 Jul 2026 12:32:44 GMT</pubDate>
      <guid>https://community.databricks.com/t5/lakebase-articles/announcement-from-monolith-to-lakebase-to-ltap-rethinking-the/m-p/162942#M72</guid>
      <dc:creator>Tushar_Parekar</dc:creator>
      <dc:date>2026-07-14T12:32:44Z</dc:date>
    </item>
  </channel>
</rss>

