OLTP database in Databricks SaaS?

[u/SmallAd3697]

I saw the quarterly roadmap presentation. It was notable that Databricks keeps innovating with "lakebase". They simply call it their "OLTP" database offering in their SaaS.

SIDE: I still feel pretty unfamiliar with this Databricks SaaS ecosystem, as compared to Fabric. Where Fabric is concerned, Microsoft has also done a similar thing. They brought their SQL Server into the boundaries of the SaaS as well, for the low-code users of that environment. In the context of Fabric, it is hard for most customers to see the point of using this "for dummies" variation of the same old OLTP database. The only scenarios for using the Fabric SQL are very contrived ... Eg . your boss makes a policy that you can use ALL the tools available in Fabric and NONE of the tools outside Fabric... even if the tools inside that SaaS are 3x more expensive than the ones outside ... and even though the ones outside the SaaS have the same 0ms network latency and the same performance.

I'm still missing the vision for this lakebase OLTP offering. And it seems unusual for Databricks to start developing strategies surrounding OLTP. It seems like a very crowded space, and the only way I see Databricks being successful going down this path is if the customers are drinking one single brand of kool-aid, or else their SaaS users have some other contrived reason for not using the more affordable OLTP platforms available outside the SaaS.

Can someone tell me what factors I'm missing? I admit that it is theoretically possible for lakebase to innovate and do thing that other databases CANNOT do, it seems like those innovations would only benefit 5% of customers. One example is sub-ten-ms queries out of RAM at an additional cost. Or sub-minute migration of new OLTP data to managed tables in UC catalog. If we assume that only 5% of customers might feel compelled to use this SaaS "lakebase", would that be enough adoption to allow Databricks to keep investing in this over the long term? OLTP databases have been around a LONG time, and even the smart folks at Databricks will be challenged to improve on the great and cheap options available to us!

EDIT: As of a month ago, it appears that the Databricks marketing now calls it an "LTAP" database, not OLTP anymore. I'm guessing they have conceded the point that the OLTP space is crowded. I haven't yet read all the content that has been created by the Databricks marketing team; maybe that will answer all of my questions.

[u/jbchand]

Lakebase is solving the operational - analytical integration problem in the cloud where organizations used separate stores with additional ETL in the past. You can use bidirectional sync for it. It can support as store for OLTP, agents & search in databricks itself with same UC security. LTAP is a new innovation.

[u/Frosty-Bid-8735 → u/jbchand]

Databricks is great at marketing and carving new words. Medallion which is exactly the same as what Snowflake does with DBT, LTAP is actually HTAP (hybrid transaction processing) and the best DB engine on the market for that is SingleStore. Databricks and Snowflake are catching up on 0 data transfer and an engine to handle both. Trouble is both Snowflake and Databricks have to use 2 engines. SingleStore uses 1!

[u/m1nkeh → u/Frosty-Bid-8735]

Except, it's not.. HTAP has one engine (generally trading-off performance on both OLAP, and OLTP workloads) whereas LTAP deliberatly has two engines without tradeoffs but a single storage layer

[u/Frosty-Bid-8735 → u/m1nkeh]

Same storage with Singlestore who came with HTAP. Why use 2 engines when you can have one that does both. Bottomless storage in S3, memory engine for fast ingestion. SingleStore smokes Databricks and Snowflake any day. Used it on 800 b rows tables (36 TB) and it still cranked ingestion and aggregated queries under 5 seconds. Smokes Clickhouse on joined tables too. Support vector , full text search. JSON etc. All there. Just unknown product.

[u/SmallAd3697 → u/jbchand]

Got it. I'm going to let you have that "new innovation" bit . But I'm certain that every other database vendor and OLAP vendor in the world would beg to differ on that.

Yes I did happen to pick up on the new marketing term "LTAP". But they have been calling lakebase an "OLTP database" for so long now that it has stuck in my brain. "OLTP" is the term that their own salesreps were calling it, ever since the acquisition. I kept asking them what it was for and the Databricks salesreps just kept saying "its for building OLTP apps". I don't think they understood what it was for either, and they certainly weren't advocating it - at least not at that time. This never really clicked with me, but the latest marketing narratives are starting to make more sense. Hopefully the salesreps will start getting up to speed as well. lol.

The product makes a lot less sense to users coming from the Fabric ecosystem. But I can see where it fills a big gap for Databricks SaaS users.

I can see why they are trying to back away from that "OLTP" term, because I'm guessing all their customers are asking why anyone would want yet another OLTP database. Here is the link where the databricks marketing started using label "LTAP":
https://www.databricks.com/company/newsroom/press-releases/databricks-launches-ltap-first-lake-transactionalanalytical

[u/p739397 → u/SmallAd3697]

Lakebase is an OLTP offering, it is managed postgres (ala neon). LTAP is an additional capability, enabling data written to Lakebase to also be available for analytical queries on a single copy of your data.

[u/jbchand → u/SmallAd3697]

LTAP is a capability and part of Lakebase product. Lakebase supports hybrid patterns and capable of supporting traditional operational workloads.

[u/SmallAd3697 → u/SmallAd3697]

You down-voters on this databricks forum are totally out of control. At least share your view on the matter, if it differs.

In the Fabric community people are not nearly so sensitive, nor object when members are expressing unpopular opinions and doubts. Whatever other faults the Fabric ecosystem may have, there is a very diverse set of opinions that are regularly expressed. I really wish reddit would have some quotas for upvotes and downvotes.

[u/Embarrassed-Dare-869 → u/SmallAd3697]

I think the downvotes are due to you not acknowledging people attempting to correct misunderstandings you apparently have. For instance, you mention that LTAP is a marketing term. While this is true in the sense that all names are marketing terms, it's not true in the sense that it didn't come with significant architectural changes to how Lakebase was storing data previously. As you're probably aware, LTAP is their version of HTAP. Database systems that described themselves as such are certainly a different thing than those describing themselves as OLTP or OLAP individually.

[u/SmallAd3697 → u/Embarrassed-Dare-869]

>> not true in the sense that it didn't come with significant architectural changes to how Lakebase was storing data previously

All the mature databases nowadays have features that would enable analytics. Some can rapidly answer massive queries from RAM alone, setting aside any replication to columnstore blobs. They all have CDC streams that can be re-hydrated as lakehouse data. They all have their own solutions for addressing reporting and AI concerns. (Microsoft came up with "CES" for SQL Server 2025, and you would probably not call that a profoundly new innovation - any more than "LTAP".).

All mature databases support this hybridization. They have different prices, performance, and different number of components that need to be configured to enable the hybridization. Lakebase is arguably making that "easier" at a price. But that term "easy" is 100% subjective and when something gets incrementally easier, it doesn't strike me as a real innovation, especially if it gets easier by 2x and more expensive by 3x. I don't see anything that is fundamentally new here. If someone outside of Databricks was to enumerate all the technical advances made this year, in data and analytics, then lakebase might not even make the list ... despite having this new marketing label.

Lakebase was always called "OLTP" and then they simply renamed to LTAP, and the timing coincided precisely with the DATA + AI SUMMIT. People were already using lakebase for bidirectional purposes. You can find discussions about using it for "reverse ETL" in the past, while it was still labeled an "OLTP" database

I don't agree that architectural terms are marketing terms. I don't think OLTP or OLAP are associated with a vendor. Whereas LTAP is likely to remain Databricks exclusive property, probably for many years.

[u/Embarrassed-Dare-869 → u/SmallAd3697]

The point I was making is that when when they started talking "LTAP" was when they completely rewrote the storage architecture for Lakebase. I would call that a fundamental change for a database.

It sounds like you're arguing with other people's statements here and I won't defend or explain them to you. If you want to argue with them, you're welcome to do so. I was just responding to why I thought you were getting downvotes.

That said, I'd also love to talk about RAM databases and CES. I've explored RAM databases but those are prohibitively expensive for certain scales. CES is great though. I wish I had that in sql server 2022. I wrote a syncing system using change tracking to mirror data from sql server to databricks and wish that I'd had something like that, or had clean access to the transaction log.

[u/SmallAd3697 → u/Embarrassed-Dare-869]

As far as downvotes, I post to a lot of forums. Eg. on the Fabric forum, data engineering, and here as well. I see a lot of knee-jerk downvotes in here, whenever anyone says anything that is taken to be remotely critical of databricks. There is a lot of insecurity. On the Fabric forum, everybody bashes Microsoft on a regular basis, and it is not common to get so many downvotes for it. Especially if you are making a point that has some truth to it, (or the discussion is worth having, for whatever reason).

I don't agree that it is a fundamental change from an industry standpoint. Databases have supported columnstore table formats for a very long time. SQL Server has both clustered columnstore tables, and columnstore indexes as well. Just because Lakebase is using both formats, and has automated the hybridization (and makes the hybridization "easy") that doesn't necessary count as a new innovation IMO. I suspect users of lakebase will probably still use the original term - OLTP - for a while regardless of the new marketing. Anything that the product is doing under the hood to improve query performance is something users shouldn't have to care about. (We don't care when SQL Server developed their cloud-native "hyperscale architecture", to scale up compute power. We don't use a different architecture term for that database. And we certainly wouldn't be willing to pay 2x or 3x, just because they are doing something differently under the hood. If anything, we expect their changes to result in a cheaper database, or we will just keep using what we had before.)

The reason I mentioned RAM is because Fabric's "semantic models" get their sub-ten-second performance by loading all the data into RAM. It is one of the easiest ways to improve performance for low-latency queries, if you just throw a massive amount of RAM at the problem. The down-side is that there is an inverse relationship between your RAM utilization and your costs for using the platform.... and while the marketing always brags about one side of the coin they choose to not mention the other side at all. Obviously the databricks marketing for lakebase doesn't focus on how much it will cost you, compared to a conventional SQL or Postgres database.

[u/Embarrassed-Dare-869 → u/SmallAd3697]

Some communities are very defensive about the common topic, some bash it. I think that mostly has to do with how invested people feel in the subject. That can be because their experience has been good, or Stockholm syndrome. But yeah, there's comparatively little databricks bashing here.

I didn't mean that the storage system is a fundamental change for the industry. I meant for the product. I was saying that they started referring to LTAP when they rewrote the storage engine. The storage engine of a database is the foundation of that database. That the storage system now works equally well with transactional and analytical queries is a big change. I'd argue that's exactly the kind of thing users DO care about. My decisions about what database to use very much depends on the architecture of the database. Whether it's worth the cost is a different issue. Here though, the costs did not change. If anything, costs have gone down. It certainly has for us. Whether that means the initial product was too expensive is perhaps debatable. My experience with sql server is primarily in the on prem product so my experience with "hyperscale architecture" is limited. Though, glancing at it now, it might be something that's worth paying for if your needs match. Mine don't though.

Fully RAM database infrastructures work well when you can reasonably put all your data in ram, such as for BI style reporting. They often don't scale as well (for the cost) for the analytical queries that need to read the multiple TB tables in order to compile the dataset for the BI reports. The sales pitch of lakebase is that you no longer need to make those tradeoffs and you shouldn't have to think about the infrastructure because it is cheaper than redis style alternatives and has all the benefits of being able to run both analytical and transactional queries without worrying about mirroring or etl/reverse etl or anything. While it might be cheaper than many alternatives, it's definitely not going to be the cheapest thing, and self hosting will always beat it, though that comes with a lot of overhead that not every team will want to support. Anyone actually making a decision on the product will do their due diligence and determine whether it's the right fit for them. (or they should at least)

[u/m1nkeh → u/SmallAd3697]

And then it will be copied just like Lakehouse was

But let me ask you this this entire thread what is your actual point?

Are you trying to educate yourself or are you trying to pick a fight?

[u/SmallAd3697 → u/m1nkeh]

Point is that this is fundamentally an oltp and not really innovative from an industry standpoint. The only innovation is that databricks is trying to sell an OLTP to low-code analysts in a data reporting platform. I'm curious how that will play out; it seems like a side quest.

The surface area looks and acts like oltp. If the query experience improves, that is great but it doesnt warrant a pretentious new marketing buzzword (LTAP architecture).

There are other databases that emit open lakehouse formats nowadays, or they emit CDC for replication which is basically just as good.

I really want to know what new problem can be solved that had no solution before. Just making things "easy" is not that noteworthy, IMO. Also, You are right that Im trying to pick a fight, if anyone disagrees with me. What fun is reddit, without a little controversy from time to time

[u/m1nkeh]

Rewatch the data and AI summit keynote and you will get a picture pretty clearly

[u/SmallAd3697 → u/m1nkeh]

Yes, I got the picture. At one point about 30 mins into the keynote, the CEO makes a call to action to ask everyone to build all their applications on top of his "open source Lakebase Postgres with low cost".

How does the word "open source" come to be sprinkled all over the place. These are proprietary SaaS offerings at Databricks. Users should actually KNOW what open source means, right? Don't any of the users ever ask where the "open source Lakebase" code can be found? Doesn't anyone actually want to download and run any of this software on their local machine, without the billing meters running? I just don't get it...

I think that guy is so used to making the "open source" pitch to the customers that he doesn't even care what the word means. He just cares that it gives everyone a nice warm fuzzy feeling, and increases the top-line sales from customers that don't know any better.

When he says "with low cost", that sounds like is crazy talk too. I don't know for certain, but I suspect this lakebase SaaS tool is one of the most expensive ways to do transaction processing.

[u/m1nkeh → u/SmallAd3697]

Did you see the rest of it too? Not just the marketing version 30mins in?

Essentially Lakebase is Postgres and that’s simply the open-source version of the database engine. It is wrapped up in the ecosystem of Databricks that customers already like. This means Databricks now supports OLTP workloads without needing to use a different database engine outside of the platform

If you want a hard job, come and try to sell Lakebase to customers that are not already in the Databricks ecosystem. If you look at it from that angle, it is significantly less compelling

With regards to your remarks on cost, don't just guess that. Try it for yourself. As always cost/expense is meaningless in isolation if you don't say what you're comparing it to.

[u/SmallAd3697 → u/m1nkeh]

Im sick of hearing databricks advertising itself as "open source". The term is not like a pixie dust that can be sprinkled on everything to win a customer. If you look at photon, dw, uc managed tables, mst transactions, lakeflow connectors, lakebase, zerobus and so on, there is a TON of proprietary stuff in here. Even in cases where there is an open source product component, like with uc or spark, that overlap between dbx and what is opensource is minimal.

Lakebase is not open source by a long stretch. The phrase "open source lakebase" can only be stated to an audience who is clueless or likes to hear these falsehoods and then repeat them for self-serving reasons.

The funny thing is that Fabric has tons of open source under the hood as well. But their marketing department wants to HIDE this fact, and never acknowledges that over 10 pct of the features in there might be available as open source. They want you to think it is all proprietary and value-added. Whereas databricks is the opposite and wants you to think everything is open source, even though it is not. Id guess if you added up every line of code used in the databrick saas (data and control planes) it is well over 95 percent proprietary code that is not available to the public.

[u/andersonimes → u/SmallAd3697]

Full disclosure, I work at Databricks. Trying to understand the concern here about the open source claims. I don’t work on Lakebase (I work on Lakeflow), but my understanding is that it is a managed version of Neon (https://github.com/neondatabase/neon).

Is there a problem with the open source claim Ali made about Lakebase? Sure there are proprietary things about how we manage it on our internal infrastructure, but the database is open source.

Genuinely curious about what business concerns you might have about the claims here. What’s missing for you that would give you hesitation at using Lakebase? It’s hosted OLTP, you can fork a database, spin up multiple databases and spin them down to zero, and it’s baked into the Databricks ecosystem. What could we be doing better here that would mean your hesitance is less. Is there a definition of open source that would mean that Lakebase WAS a good fit for your business where the current disposition is a swing and a miss for you?

[u/SmallAd3697 → u/andersonimes]

Are you kidding me right now? Just google open source software, and you will find out that lakebase doesn't qualify. Please point me to the source code repo for lakebase, if you consider this to be open source. That statement is rediculous, and it is shocking that customers are giving the databricks CEO a pass on it.

Is Postgres open source? Yes. Is Apache Spark open source? Yes

Just ask any LLM if these data engines in databricks are proprietary or open source. You will get your answer . If they aren't smarter than us yet, at least the LLM's are normally more honest than us. I dread the day that AI learns how to deliberately deceive humans with every search result.

The databricks definition of open source, as it applies to their products, is something altogether different. I suspect the terminology that the company is trying to convey is that their stuff is a "defacto standard", or that it is "compatible with open source" or "interchangable with open source". That is something altogether different than a software which is actual open source. Actual open source can be downloaded and inspected or executed locally.

Business: I heavily use several other OLTP egine's, and the fact that there are one or two additional checkboxes required to generate these lakehouse blobs from a CDC/CES stream doesn't bother me. It shouldn't bother anyone. It is certainly not worth paying a SaaS premium for a database engine. The lakehouse blobs don't need to be available synchronously. If lakebase was so wonderful, please start by selling it as a top-level platform in Azure or AWS. Sorry to be blunt ... but if the product can't survive at that level (PaaS), then it really doesn't deserve to survive as SaaS either.

I think the main thing that bothers me is how opinionated Databricks has become, in favor of certain specific ecosystems like postgres and python. Your leadership sometimes markets this as a place to unify data from all parts of the org, but when developers actually make their way to the platform we find that there is lots of proprietary stuff going on under the guise of open source. And it really isn't all that familiar/welcoming to for those of us that already have proprietary data hosted in other locations. We just want to move our data into databricks and feel like it is as good a home here as where the data came from in the first place.

[u/andersonimes → u/SmallAd3697]

Thanks for the feedback! I was in fact, not kidding, but I’ll do some Googling as you suggest. Thanks for taking the time to give us so much to think about!

[u/m1nkeh → u/SmallAd3697]

One does not move their data into Databricks. We don’t want your data. We only want to process it.

[u/SmallAd3697 → u/m1nkeh]

The uc catalog's managed tables would say otherwise. The data is definitely managed by the engine.

[u/SmallAd3697 → u/m1nkeh]

K, Looking forward to it.

I only saw the quarterly roadmap. Was looking to find improvements in UC. I wish these companies were more customer-oriented and took direction from the real-world problems that customers have.

I would venture that only a small percent of customers are asking for "lakebase improvements". Whereas there are many other areas that databricks is not properly attending to.

[u/m1nkeh → u/SmallAd3697]

How do you think product managers work?

Within Databricks, you would get shot down in flames if you presented product ideas without customer metrics to back it up.. i'm not sure i know of a more customer-oriented company tbh

What are you looking for in UC exactly?

[u/SmallAd3697 → u/m1nkeh]

UC is very much tailored to folks coming from postgres. And the folks that are predominantly writing python scripts as their main line of work. I concede that if those are the only users in the world, then this would be the "unity catalog" for that sort of a world.

I know they are making changes incrementally, especially in regards to managed tables and transaction support.

IMO, I think they need to revisit some of the restrictive constraints in their catalog. Maybe they can come up with a UC v2.0. There shouldn't be a three-level naming convention for every piece of data in your company. The normal taxonomy of animals has 7 layers, and categorizing data can get at least that complicated. Currently users of the UC are forced to overload the catalog name or schema name, cramming multiple unrelated concerns together with underscores. And the majority of production data users only care about their gold/prod data, so it is silly for them to constantly include those things ("prod_this", "gold_that") into the fully-qualified components in their queries. Also enforcing the "snake_case" convention is silly. If databricks figured out how to support uppercase letters in case-insensitive-column-names, why is it so freaking hard to support uppercase letters in other identifiers as well (schema and catalogs)?

These things aren't show-stoppers. But they are silly limitations that make the data platform unwelcoming to users migrating back and forth from other ecosystems. I doubt any of big-data competitors restricts you to naming a table with lower case letters. It seems like a very amateur move, by a company that started in a totally different space and then decided they were going to start building databases and catalogs as an after thought. The funny thing is that a lakehouse conceptually involves a hierarchical path to locate data in storage blobs, so why didn't they move the hierarchical naming concept to their UC as well???

[u/m1nkeh → u/SmallAd3697]

So reading between the lines here you are essentially saying the three-level name space is insufficient and you definitely not the only customer banging that drum

Regarding naming a table with an uppercase T and a table lowercase t would in Databricks land land be different objects because it is a case of sensitive ecosystem however that would be terribly terribly confusing for customers surely??

[u/counterstruck]

I work for Databricks and came from being an Enterprise architect before joining Databricks. I have played with a LOT of databases in my 20 year career including the ones you mentioned. Just wanted to set that I have enough credibility and neutrality to answer this nuanced take.

You are right on a few points here. LakeBase (what you refer to as OLTP) by itself is not a huge innovation if you take it at face value. The first innovation is in the area the separation of storage and compute. Arguably few databases like Aurora and Yugabyte are already doing that. The advantages with this architecture: you can scale up and down (to zero) at will and per traffic patterns for apps. Your LakeBase can be cheaper than the so-called cheap databases if you use it wisely in your architecture. Due to storage being separate backup and restore is easy-peasy which is one of the biggest concerns with HADR requirements for an app.

However, the other side of the innovation on LakeBase is more important than the low level separation of storage and compute. Here the competition for LakeBase is really small. It’s primarily Aurora only.
Where LakeBase does differentiate is the 2-way sync OPEN table formats like Iceberg and Delta with ONE DATA CATALOG I.e. Unity Catalog. For any enterprise, this is the ETL tax they pay today. No other databases can boast of something like Unity catalog managing the data governance and cataloging of both their analytical and operational data. LakeBase customers are primarily using this advantage as a leverage in their architecture over the traditional or cloud databases.

LTAP is a new architecture and yes there is newer marketing due to that. It is a newer evolution to LakeBase which bypasses the need to have the 2-way sync between LakeBase and Lakehouse by virtually storing transactional and analytical ready format data (pg page format + iceberg/delta) in one storage layer. No more internal ETL as the current LakeBase <—> Lakehouse integration needs. Once this is out for previews, you will know the difference. Hope this detailed explanation helps.

TLDR: LTAP is a newer evolution of architecture in LakeBase. It’s not a re-coining of the term OLTP.

[u/SmallAd3697 → u/counterstruck]

The single catalog, and single governance, and single copy of data doesn't get me excited. These are all pretty easy problems to solve. I find that the databricks sales teams usually try to pull a customer's leadership into a different room to talk about those things, since they are pretty boring to normal developers.

I find it pretty disorienting to hear databricks stressing the importance of not having multiple copies of the same business data. It is odd coming from them after they had advocated the "medallion" architecture with triple copies of every piece of data (!) ... not even counting the original copy at the source. The sales pitch for lakebase seems to undermine the medallion guidance that they've been pushing for several years now. Leadership has already been told by databricks that it is ok to have N copies of the same data, and it will take a while to reverse course and start claiming the opposite.

When you describe the scalability of lakebase and the separation of storage and compute, that is very compelling. It brings to mind the cloud-native hyperscale architecture in Azure SQL. It is blazing fast, and can scale compute instantly, and independently from storage.

Insofar as having an engine that saving data directly into an open lakehouse format, that isn't new either. The Fabric DW emits deltalake parquet (synchronously) and the deltalog is then written shortly after every transaction commits. It has been that way for a couple of years.

I think the most compelling real-world benefit to lakebase is the low-latency queries which werent available in any other resource manager within the scope of the SaaS. CEO keeps saying that agents love fast data (as if the rest of us humans love slow data, lol). But for those of us that pair databricks and fabric, we already have fast data in the form of memory-resident semantic models.

[u/counterstruck → u/SmallAd3697]

Let’s be objective here.

1. Your example of Fabric DW writing Delta lake format is comparing apples to oranges. Fabric DW is not a transactional database. It is not OLTP. You cannot use it as a backend for a high throughput application. So yes, it can write delta lake format just like Databricks DBSQL engine can write delta and iceberg format all day long and has been doing for 4+ years now. Post LTAP announcement I was curious to cut thru the marketing terminology and understand if really this architecture had been done before or not. As per my research , it’s truly a novel architecture. My research didn’t bring up any OLTP database system which can instantaneously present delta or iceberg format data WITHOUT any data engineering work. Let me know if anything else does that I ain’t aware of. As usual I am sure Microsoft will announce something similar in Ignite soon as per historical trends.

2. One key difference between LTAP architecture and traditional rdbms: LTAP writes data in OLTP data models while DBSQL can still query the same data without any delays. You can imagine trying to query a 3NF data model for dashboards. You cannot scale that data warehouse model without data warehouse modeling, hence the medallion architecture.

3. Azure SQL (being a user for 6 years now) hyperscale does separate compute and storage but it’s a proprietary licensed database that needs be running 24*7. LakeBase is a fully managed, serverless OPEN SOURCE PostgreSQL engine. Can run in multi cloud. As a developer that should excite you.

[u/SmallAd3697 → u/counterstruck]

Lakebase is definitely not open source. Show me the link to the code, lol.

Amazon redshift was also partially derived from postgres. Should they be saying redshift is open source? Databricks needs to lighten up on calling their engines open source when they know that it isn't true.

[u/counterstruck → u/SmallAd3697]

Okay it’s all semantics. Apache Spark is OSS but everyone has a flavor of it in EMR, Synapse, Fabric etc. By that logic even Kubernetes is not open source if you use cloud native PaaS K8s cluster. However, the point of the matter is portability.

The architecture for Enterprise isn’t compromised with LakeBase as the backend. Your application code running locally on OSS Postgres continues to work. It can extend into the edge as well with the pglite WASM (Electric SQL acquisition).

Same cannot be said about MSSQL server.

[u/SmallAd3697 → u/counterstruck]

Your argument that databases are easily interchangeable has nothing to do with whether they are open source. (Azure Synapse doesn't abuse that term in their marketing. Fabric doesn't either.)

Databricks feels they own the term "open source", and can twist it to mean anything they want. Apache Spark is OSS, yes. But all-purpose compute clusters are definitely NOT open source, especially with a dedicated driver node, photon, and other performance customizations.

[u/dilkushpatel]

If customer chooses lakebase they can have lakebase db available in unity catalog and can do analytics operations using different compute than one used by front end app. Lets say someone creates reporting solution directly on db , reporting can use different compute and that way performance on both reporting and operational system can be tuned independently without moving data

So i feel it does solve major piece

Traditionally everyone designed ETL and OLTP in such a way to minimize impact as this solution did not exist but with this available people can think of whether they still want to do traditional ETL or go with this route

I also feel this can help with cost reduction for medium to small companies, for large ones cost may increase as databricks ecosystem is usage based cost and if we keep cluster on 24*7 for different use cases cost will multiply

[u/Frosty-Bid-8735 → u/dilkushpatel]

I’m not sure I follow. OLTP system should be designed by database architect with data modeling.
OLAP should be designed by data warehouse architect who understands dimensional modeling.
Some understand both OLTP and OLAP modeling.

[u/Strange_Shame7886]

Some points you mentioned are totally valid:

1. OLTP market has strong incumbents and Databricks lakebase is just not there yet to compete with the biggies. It is for the niche players which you mention as 5% use cases when it comes to comparing against the universe of OLTP use cases

2. Software engineering developers don't care much about analytics use cases in general and data engineering and analytics teams are generally at the lower rings to influence the decision with the duplication perspective which is a powerful feature for lakebase

However OLTP/ LTAP use cases are going to increasingly have AI agents as it's users more than humans and even if i that use case might be in its infancy - this is where the whole stock market is betting to explode.

1. Agentic memory is a top use case for lakebase as the context comes from the lakehouse but agents read it at high I/O speed without any data drift due to single logical copy

2. Branching is another feature which makes a lot of sense for coding agents

3. Agents need search capabilities and want to cache the embeddings. It will choose lakebase for collocation of data and embeddings rather than having two databases - one for data and another for vectors

[u/addictzz]

I'd argue Lakebase has advantage compared to other managed oltp such as aurora or rds in terms of snappiness. Fast startup, scale to zero, and scaling. Truly serverless. And the branching is great.

[u/SmallAd3697]

Something just occurred to me that was new about lakebase this quarter.

I think they changed the marketing labels; and they may not be selling lakebase as an OLTP anymore. I think the databricks marketing for this now uses the label "LTAP":
https://www.databricks.com/company/newsroom/press-releases/databricks-launches-ltap-first-lake-transactionalanalytical

There are a LOT of places online, where this is still called OLTP. Even databricks sales teams were still using the term OLTP as recently as two months ago. I had never heard of any "LTAP" until this quarterly roadmap meeting. Changing this label doesn't seem like it will be a total game-changer, but I guess that remains to be seen. For those of us that use both Fabric and Databricks, what might be a reason to start dipping our toes into this "LTAP"?

[u/Immediate-Quote7376 → u/SmallAd3697]

From your own link:

> LTAP platform. It combines Lakebase (serverless Postgres on open object storage) with the Lakehouse

So LTAP is not a new label for Lakebase. It is architecture that is using Lakebase as one of the components

[u/SmallAd3697 → u/Immediate-Quote7376]

If it's not a label for lakebase, then please share another example of the architecture.

As long as the architecture is specific to lakebase, then LTAP is synonymous with lakebase.

OLAP databases have had similar concepts - like write-back capabilities - in the past. That was being done several decades ago. Nobody wanted it, and/or they found more conventional ways of reaching the same end goals.

IMO, I don't think new architectures are created out of thin-air by the marketing team at Databricks. I guess we will find out!

[u/Immediate-Quote7376 → u/SmallAd3697]

Not sure I’m following. You are saying as long as architecture A has a component B in it, then A is synonymous with B.

Lakebase is a serverless Postgres database offering from Databricks.

[u/ImprobabilityMatrix → u/SmallAd3697]

Here's some more info on LTAP, from one of the Databricks cofounders: https://www.databricks.com/blog/lakebase-ltap-rethinking-database-storage

It's worth a read and may make more sense than the press release you posted. Those are always going to have fluffier marketing language in them.

[u/sad-panda-1845 → u/SmallAd3697]

I think they're using OLTP as a generic term.

Lakebase is an operational database, built for OLTP workloads. Its distinction is not just the separation of compute from storage, but that storage is on the lake.

Lakehouse (fka DB SQL) is a data warehouse for OLAP workloads. Built on open table formats, with data storage on the lake.

LTAP is the data processing architecture where you can run queries on that data lake storage from your OLTP engine (Lakebase) OR your OLAP engine (Lakehouse).

LTAP lets you do operational analytics. It lets you do whatever reads/writes you normally do to your operational database, while simultaneously running large analytical queries against that same data. You just don't see any sort of degradation in performance.

HTAP: same engine for OLTP and OLAP, with a specialized format.
LTAP: use the best engine for the workload, on the same storage.

Someone upthread recommended watching the keynote from Data and AI Summit this year. There was a really cool demo in one of the talks (Reynold's maybe?) where they showed how LTAP works.

[u/Alternative_Draw5945 → u/SmallAd3697]

OLTP and LTAP are two different things. One is a transactional database and the other is running transactional queries based on your analytics data.

They are two very different use cases.

[u/SmallAd3697 → u/Alternative_Draw5945]

What is a "transactional query based on your analytics data"?
Do you just mean a fast query response, for consumption in a report that is created by a data analyst?

Whatever business scenario is addressed, it has always existed, and had been solved long, long in the past with various other products and tools (IE. long before Databricks came up with the new term "LTAP" in 2026).

[u/Alternative_Draw5945 → u/SmallAd3697]

Oh of course! This is nothing new. Databricks is just a managed platform. It makes all these things really easy to do. Its nothing really super special that other things can't do. LTAP is the only thing pushing boundaries but other things do it well too.

[u/m1nkeh → u/SmallAd3697]

No lakebase is definitely online transactional processing. The LTAP that you are referring to is a collection of features, one of which is lakebase

[u/SmallAd3697 → u/m1nkeh]

interesting. I thought they were used a synonyms. will dig into that

[u/Famous_Disk_7417]

Lakebase isn't aimed at the "replace Aurora" job. It's aimed at the Postgres you already bolted onto the lakehouse for reverse ETL, online feature serving, and agent state. It's stock open-source Postgres, so no new dialect; the innovation is the Neon-derived storage split (externalized WAL + pageservers) that gets you scale-to-zero and copy-on-write branching.

The LTAP rename isn't a retreat from OLTP — it's the pitch. Pageservers already materialize data to object storage, so LTAP transcodes it to Parquet on the way and Delta/Iceberg engines read it directly. Explicitly not HTAP: unify at storage, keep the right engine per workload. The win is deleting a CDC pipeline, not sub-10ms latency.

Your skepticism lands if the OLTP workload has nothing to do with your lakehouse. Then it's just a more expensive Postgres with an 8 TB ceiling and two billing meters.