On 25 August 2026 Databricks put LTAP Direct Writes into beta. The release note is a paragraph long. When you create a synced table, Lakebase loads a full copy of the Unity Catalog table into your Postgres branch, and Direct Writes speeds up that initial load and any full refresh by writing to the storage layer directly instead of through the compute endpoint, so a large load finishes faster and stops competing with your queries. It needs a project on Postgres 17 and a workspace admin turning it on from the Previews page.
That is a small feature with a large word in its name, and the word is the reason to read on.
What LTAP claims, in one sentence #
The LTAP chapter sets out the claim: transactional and analytical workloads on one copy of the data, with the unification happening at the storage layer rather than in the engine, which is what HTAP tried, or in a vendor-run pipeline, which is what Zero ETL does. The trouble with a claim like that is that most of it is architecture, and architecture is hard to measure. You can't time a diagram.
Direct Writes is the first piece you can time. A synced table load is the moment the analytical side of the platform pushes data into the transactional side, and until August it went through the same compute endpoint your application queries use. That is the HTAP failure mode in miniature, two workloads competing for one machine. Writing straight to storage is the LTAP thesis in miniature, the two sides sharing a copy without sharing compute.
Why a load path is the interesting part #
Nobody buys a platform for how fast it does a full refresh. They buy it for what happens to the application while the refresh runs. If the transactional latency holds flat while a large table lands beside it, the storage-layer argument has evidence behind it. If latency climbs, the argument is still a diagram. Either way you learn something the chapter said was worth an afternoon to learn, and now there's a switch that isolates exactly the variable in question.
The beta also tells you where Databricks is spending. A load path rewritten to bypass compute is not a feature a product team ships for a demo. It's plumbing, the kind you build when synced tables are carrying enough data for the old path to hurt.
How to test it in an afternoon #
Take a non-production workspace and create a Lakebase project on Postgres 17. Pick the largest gold table an application of yours would plausibly read, and create a synced table from it with Direct Writes off. Time the initial load. Run a steady transactional workload against another table in the same branch and record its latency during a full refresh. Then have an admin enable Direct Writes from the Previews page and repeat all three measurements. You will have four numbers, and they are the whole argument.
What is still a claim #
Direct Writes covers loads and full refreshes. It says nothing yet about incremental sync latency, about writes originating on the Postgres side flowing back to the lake, or about the cross-cloud recovery and branching the LTAP announcement named alongside it. Those stay in the chapter's "coming soon" column until a release note moves them, and when one does, it belongs in this note as a dated update rather than as a new one.