Delta-Kernel-RS: Unparalleled Interoperability Across Query Engines

Summary

• Rust Native Delta Implementation: Delta-Kernel-RS provides a native Rust implementation of the Delta Lake protocol with C and C++ FFI support for seamless engine integration.
• Consistent Protocol Enforcement: Maintaining a single source of truth for Delta protocol implementation eliminates fragmentation from multiple reimplementations across query engines.
• Performance Optimization Without Rewrite: Query engines gain data skipping improvements and other optimizations automatically by leveraging Delta-Kernel-RS, reducing custom development burden.

Delta-Kernel-RS: Unparalleled Interoperability Across Query Engines

Talk by Robert Pack, Staff Developer Advocate, Databricks ; Zach Schuermann, software engineer/ski bum, databricks
Join us as we introduce Delta-Kernel-RS, a new Rust implementation of the Delta Lake protocol designed for unparalleled interoperability across query engines. In this video, we will explore how maintaining a native implementation of the Delta specification — with native C and C++ FFI support — can deliver consistent benefits across diverse data processing systems, eliminating the need for repetitive, engine-specific reimplementations. We will dive deep into a real-world case study where a query engine harnessed Delta-Kernel-RS to unlock significant data skipping improvements — enhancements achieved “for free” by leveraging the kernel. Attendees will gain insights into the architectural decisions, interoperability strategies and the practical impact of this innovation on performance and development efficiency in modern data ecosystems.
Here's more to explore:
Databricks named a leader in the 2024 Gartner® Magic Quadrant™for Cloud DBMS: https://www.databricks.com/resources/analyst-paper/databricks-named-leader-by-gartner
An open, unified approach to your data, BI and AI workloads: https://www.databricks.com/product/databricks-sql
See all the product announcements from Data + AI Summit: https://www.databricks.com/events/dataaisummit-2025-announcements

FAQs

What is Delta-Kernel-RS and why is it important for query engine interoperability?

Delta-Kernel-RS is a native Rust implementation of the Delta Lake protocol designed to enable consistent interoperability across different query engines. By providing a single source of truth for Delta protocol implementation, it eliminates duplicated, divergent reimplementations that can cause fragmentation.

What performance benefits does Delta-Kernel-RS provide?

Query engines using Delta-Kernel-RS automatically gain optimizations like data skipping improvements without requiring engine-specific implementations. This approach reduces development effort while delivering consistent performance benefits across all engines using the kernel.

How does Delta-Kernel-RS support different programming languages?

Delta-Kernel-RS provides native C and C++ FFI (Foreign Function Interface) support, enabling integration with query engines written in various languages. This flexibility allows different systems to leverage Delta while using their preferred technology stack.

What architectural decisions guided Delta-Kernel-RS design?

The kernel was designed with interoperability as the primary goal—implementing just what's needed to read and write Delta tables without imposing constraints on query engine internals. This design philosophy ensures engines can integrate Delta while maintaining their unique strengths and design choices.

Full transcript

Thanks everyone for coming. Uh. I am an engineer at Databricks. I've been working on storage for the past 4 years. Yeah, hi. I'm with developer relations and I'm responsible for many of the open source projects out there, including Delta. And uh, so we have a talk today all about Delta kernel, specifically the Rust kernel and how you can interoperate with um, effectively any variety of query engine. So before we get started, uh, just want to say a quick thank you.
Um, we're presenting the work of many others. Uh, so some of which are in this room. So thank you all for contributing. We have 38 contributors on GitHub and we are just always looking for more and trying to grow and improve the project. Yeah. So let's dive a little bit into why kernel and why this project exists. And I think the makers of Nimble, and for those of you who don't know, Nimble is a new file format that is being developed at Delta, well, I think they really sort of hit the nail on the head when they put out this quote in their readme, which says, "We strongly discourage developers to re-implement Nimble spec to prevent environmental fragmentation issues observed in similar projects in the past."
And this is, as an open source contributor who tried to keep up with the Rust uh, with the the JVM implementation of Delta, is actually something I felt firsthand. And kernel tries, by focusing on inter- interoperability between query engines, to achieve exactly that, right? To implement just what's needed to read and write Delta, but not impose any constraints on the query engine, so that there can be sort of a single source of truth for the implementation of Delta.
And again, some of the challenges that were encountered is to a certain extent, the ecosystem is determined by the weakest link in the chain, right? So, all the clients out there, they either support protocol features or they don't. So, any writer out there must make a choice, do I write advanced features breaking clients who do not support those features? Or do I limit myself to, let's say, almost legacy Delta, um but do not do not gather all the benefits that that come from that, right?
That come from these modern features. So, Kernel tries to mitigate some of these issues. Also, as you optimize systems, usually, it gets more and more complex. Um the implementations of more advanced features require more and more software engineering, actually exacerbating the aforementioned kind of challenges that come because it's harder to follow suit, especially for open source projects. And then, there may be a lot of duplication within the community, and you may see implementation at varying levels of quality.
And Kernel tries to address some, if not all of these challenges. And there are some great examples out there of projects or technologies that solved similar problems in the past. So, a long time ago, image formats were a real pain, right? JPEG, PNG, EPS, what have you. You you had to make very deliberate choices when to choose what. And email, I think, uh today shows you really really well how this just disappeared, right?
You just drag and drop anything into an email, and it gets sent around. And this is, I think, a huge success story of eliminating this need to think about some of the specific of how do I do which what. Then ODBC is another great example. And to be honest, I'm not the biggest expert on ODBC or managing systems that consume ODBC, but to my understanding, for the most part, updating an ODBC driver is a very painless procedure.
Admins are willing to just okay, I'll just bump the version and fine, let's run some tests. You're done. And Kernal is aiming for exactly that experience that okay, you'll just update Kernal. Granted, we're not there today yet. So, I'm not claiming we are there, but it's it's the guiding light um that that we're striving for. And then Open Telemetry, and this is also from my past experience. In my previous life before Databricks, I needed to deal a lot with Telemetry in in uh distributed systems.
And there was a time when there was two systems out there, Open Census and Open Tracing. And this was a complete bifurcation of the ecosystem, both in terms of the SDKs, but also in terms of which vendor supported what. And Open Telemetry was really really successful in just unifying this and putting this burden completely out of the minds of um of the developers themselves. So, I think these are in in in spirit three great success stories that we're striving to replicate with Kernal.
So, let's look into what we're going to talk about today. First of all, we'll dive quickly into what's new here. We'll see what Open Lakehouse and Composable System have to do with all of this. Um we'll go deeper into the architecture, and we'll we'll brush on some of the integration examples. Here, it's very important for us that these are not our favorite integrations or the most important ones. These are just some integrations that highlight some of the features um of Kernal and how they work well in this in this ecosystem.
So, what we're not going to go into too deep is what actually is Delta. Actually, as we were working on the slides, we realized to a certain extent that we can talk about Delta kernel without actually mentioning much of what Delta is or what Delta does internally, which to an extent kind of showed us that this is this is an excess in and of itself that you can describe a technology. We we we aim to hide the details, right?
So, and if we don't even need to talk about them much, that was um that was something we realized uh along the way. But, basically, kernel aims to teach engines how to read and write Delta tables without them actually needing to understand any or much of this. So, we'll look into how this fits into the open lakehouse and how uh uh Delta kernel is a composable uh system. And when we talk about composable systems, the the question is So, here, I don't know how many of you're familiar with these two bigger, let's say, movements within the the uh data world, but these are two movements I'm personally a big fan of that capture a lot of the directions, architectures, engines, data systems have been going.
So, the open lakehouse, I think, is a great success story in the sense of that I think all the major cloud providers actually refer to their architectures as lakehouse architectures by now. And composable system is something that came a little bit later, but essentially trying to dissect or um deconstruct, decompose what a data engine is or a a query engine is, right? They're trying to modularize the query engine in the sense that a a change within one single component of such an engine doesn't propagate into the rest of the system.
And if you want to look at this, so Voltron Data actually has great little little animations of all of this, but the basic idea is you have sort of layers, you have an an execution layer, you have an input layer. I don't know, it could be SQL, could be a data frame API, an execution layer, you have representations for your arrays, all of this kind of And we'll explore a little bit how these come together. So, the the question we're trying to answer in this in this talk is um open table formats uh give you these asset transactions and a lot of these properties you want composable systems um want to make it possible to just yeah, kind of like with Legos, build your own data system from individual components, but open table formats by nature have an IO component where you need to read from disk, but also concern themselves with some of the internals of the execution of a query, which sits inside one of those composable layers, right?
So, how can we make open table format into something composable that we can plug in uh shove out kind of and evolve independently without permeating into the rest of the system? And um now is going to talk a little bit about what this architecture looks like and uh yeah. Thanks. Um so, we're going to dive into the architecture and I've briefly listed kind of the major sections that we'll cover. Um hopefully a couple of these examples sprinkled throughout will keep things fairly pragmatic and understandable.
Um but yeah, I'll try and uh not bore everyone to death with super deep dive and uh keep stuff actionable. Um so, the kernel's overall architecture could hopefully be simplified to something like this, but um alas, it's never this easy. Uh you can imagine a user issuing a query um that goes to whatever engine you're running, which ultimately contacts kernel and says, "Hey, I have to go read this um Delta table. Please go to cloud storage and read it back for me."
Um, but this doesn't work because that would require us to take an opinion on IO and the in-memory format and perform a bunch of work that is effectively the engines within the engines purview. It's stuff that they're already good at. It's stuff that they know how to do and it's stuff that um may be difficult to interoperate with. Like if we were to pick a singular format for us to um to leverage. So, the solution to this is to embed the kernel.
Um we the kind of like subtitle or tagline of the kernel is a is a deeply embeddable query engine agnostic um Delta implementation. And so, the deeply embeddable part is really the solution to this this problem. It It lets the kernel exist within a query engine and um facilitate or rather leverage the things that the engine is good at such as IO and having its own in in-memory format um to go ultimately read from cloud storage or do the computation that we need to carry out our um various activities.
So, we'll zoom in on this uh this diagram to get a bit more context on what the kernel looks like and how we are somewhat unique in the space. Um, we have these two API layers. So, on the top we have table APIs and then on the on-quote bottom, we have engine APIs. So, it shouldn't be surprising that table APIs are like creating a table or a snapshot or starting a scan, beginning a transaction against my table. So, these are these should be unsurprising for any like storage library, right?
Like you we want to interact with Delta tables. So, these are the unsurprising APIs. Perhaps the um more unique ones are the engine APIs, which communicate not intent but rather capabilities. So, um the engine trait or like interface effectively communicates that an engine is capable of fulfilling the things that the kernel needs to go do meaningful work. So, what I mean by that is whenever the kernel needs to go create a Delta table object or begin a scan, it will ask the engine to go do the some of the meaningful pieces for it.
So, please go read JSON, please read parquet, or evaluate this expression. Um if we come back to the to the original diagram, so the table APIs are unsurprising, but the engine trait is the thing that we're going to talk briefly about now. Um like I mentioned, it'll have these capabilities that the engine can communicate to the kernel. And so, we're saying like everything in blue here is the engine's code, and so it can plug in its JSON reader, plug in its parquet reader, plug in expression evaluation.
Um and then after that point, you get a usable kernel, right? Like then all of those table APIs actually leverage the engine's JSON reader, parquet reader, etc. Um it's worth noting that there are a number of clients uh or like users that um we have integrated with that are effectively like, "Hey, we we don't want to displace the engine trait. We don't want to run our own custom code to do any of these things." Um so, we actually ship with our own default engine.
So, all the yellow boxes are Delta kernel code, and so we ship a default engine that exists as a sane default. People you know, very frequently use this on the metadata side uh and then perform their own data reads. You can obviously use this to do your data reads as well, but um will talk a little bit about some of those patterns we have observed with existing integrations at the end of the talk. So, my first example uh hopefully this is mostly legible.
My first example, again to keep things relatively pragmatic is is you're just scanning a table and um I've created just some chunks of code with comments that are effectively highlighting the overall flow. So, everything is predicated on creating an engine. It's the it's the thing that facilitates kernel doing work more or less. So, we create an engine and then we can pass that engine into our table based our table APIs that say like, "Hey, go create this new table at my S3 URL."
Um and then we can start a scan, we can get back scan files. We go tell our parquet reader, "Hey, please go read these these scan files that are ultimately like the data that comprises the Delta table. Um so, perhaps on this last slide you would you'd notice like, "Well, a lot of these APIs maybe are our table is a table type or scan is a scan type." But, an interesting worth noting is that scan files um is an in it's actually an engine data type.
So, it is a uh we effectively need to communicate large amounts of data back and forth between the engine and the kernel. So, like for the scan files, this would be hey, telling your parquet reader, "Please go read all of these parquet files that comprise the current scan of the table." And obviously this is like, you know, maybe approximately table sized is is is like a large comparison, but it's it's effectively large enough data that this we need to think deeply about how we're passing this back and forth.
So, we notice that um obviously engines are already good at processing large amounts of data and we again allow engines to displace the in-memory format directly via this format agnostic engine data trait. So, again by example, the read JSON files is one of the one of the required methods within the engine trait, and I kind of just plucked that out as an example of what this looks like. So, the return type of read JSON files is an iterator of again the most like important piece is the highlighted one.
It's an iterator of engine data, where engine data is something that implements the engine data trait. Um the main like how we define this format agnostic engine data is effectively it is whatever you want it to be. So, for some engines this is arrow, for other engines this is a you know bespoke like DuckDB specific very optimized thing. You could be a time series only database that has an engine data that's like ultra good at time series and terrible at everything else.
Um but we aim for keeping this API simple. So, you can effectively just visit the rows and know that it has a length and that's about it. So, everything else is entirely up to you. This means it's an easy API to implement and ideally generalizable to basically every format that's at least the hope. Um so I'm kind of trying to tie everything back together here to the original diagram that we had in which you have the scan metadata like table level API that effectively boils down into like oh maybe you need to go do some JSON read, some parquet reads, etc.
And you ultimately hand back some engine data to the user or rather to the engine that then goes and perhaps like reads the files embedded within that engine data to via its parquet reader to go return data to its user. Um so the second example that I have is for is talking about query plans. So, kernel obviously aims to work in the, you know, maybe rather linear pattern that we looked at in the last example in which it was just like staring at a at a ABCD kind of style of code.
But, if you imagine that you're an engine that has um logical plans and physical plans, which are fairly prominent today, um kernel exists in in this architecture as well. So, you can imagine you have some logical plan that says we're talking about this example like select star or like select A, B from some table. And your logical plan would boil down to a project and then ultimately like some sort of data source node.
Um, the kernel can then transform that into like a uh Parquet scan. So, in in this relatively naive view, it's it's kernel being invoked in order to um remove the Delta specific things that says like, "Hey, go scan my Delta table." Um, and then translate that into uh into APIs that the engine has and understands such as, "Please go read Parquet files." Uh, we'll layer on a little bit more complexity because um I want to talk a bit about this sort of shared language that we both have to agree on.
Um, it's a little bit of a lie to say like, "Oh, your Delta table always just boils down to go read a handful of Parquet files." Um, because Delta includes um some relatively advanced features that require you to like um fix up data in a sense, like transform the data that you're reading from the Parquet files, or to inject things into your schema for like generated columns, et cetera. Um, we actually communicate an expression as well as a schema to in this example, this would be like a project exact node.
Um, so it would like ordinarily select columns. It would be able to embed your the expression that we are asking the engine to evaluate. And this all still fits very nicely into the existing pattern of query plans. The last thing I want to point out on this example is just that the um we can work with, you know, you can pick an arbitrarily advanced engine. Like let's say that you have this engine in which they actually have a super cool multi-file parquet reader that distributes or parallelizes stuff.
Right? The we take absolutely no opinion on the execution semantics of the engine. So, as long as we expose the right APIs, which for example these files to scan API is is iterator based, it's lazy, and it lets engines consume it as they see fit, then the engines are the ones that get to make decisions about how to execute this, how to distribute this across workers, etc. And so the thing that I touched on earlier about this shared language, um I'll try to explain it a little bit more detail on this slide.
So, on the left-hand side we have kernel native items, which are effectively things that we take the most strict opinion of and say like this is a kernel native data type or or kind of subject. And on the right-hand side in the blue we have the this gradient, it's stuff that the engine is entirely in charge of. So, on the left we have things like schemas, right? We open table formats, whether that's Delta or Iceberg, they specify their own data types and schemas.
And so, we obviously have to take an opinion there and then it's up to the engine to translate back and forth. And a lot of times this is relatively simple code, right? If we say it's a, you know, int column or a long column, that becomes like a U64 or I64 or what what have you. Um expressions and predicates fall into an interesting middle ground. We obviously need to leverage predicates during file skipping and data skipping.
And then we need to produce expressions, uh, for those transforms that I mentioned in which you can, imagine that you effectively are telling your parquet reader, "Hey, please go read these files for me, but perform this trans, uh, transformation to allow me to like read the correct data based on my table features." Um, but all this being said, the actual expressions and predicates that we need to support are relatively small set, um, and there are a lot more that the engine would ostensibly support that we we just don't care about, and that's totally fine.
Um, we allow the engine to be good at all the fancy expressions it's good at, and we just ask for the minimal subset that we need to go carry out the delta operations that we have. And then I I won't spend too much time on it, but obviously on the far right-hand side we have engine data, the trait that we mentioned, um, before, which is the engine's in-memory format, which we take effectively no opinion on other than we need to be able to visit the data, um, and, uh, and ask it for its length.
So, this was really motivated, um, by these some of these guiding principles, right? We want to provide the best performance for each engine, not prescribe any, uh, design decisions, um, not force anyone into a data format, and be able to leverage the things that the engine is good at already. So, for the first point, um, we implement this relatively flexible, somewhat low-level API. The engine data abstraction, uh, broadly addresses the second and lastly, um, the engine interface overall is is, uh, addressing letting the engine be good at what it's good at.
And to bring everything back to the what I I I don't know, I'm calling our subtitle, um, Delta Kernel is a deeply embeddable query engine agnostic Delta library. And so, the deeply embeddable part is what we've been talking about, the fact that you can use this relatively low-level API to, um, interact directly within your query engine as well as query engine agnostic meaning, you know, we have these engine data trait engine and engine data traits to effectively displace any engine um and allow any engine to implement those.
So, thank you for sticking with me. I'm going to hand it back to or to talk about uh integrations. Yes. Um So, talking a little bit about integrations, we have three examples. Delta RS, uh a project I personally worked a lot on. I think DuckDB also needs no introduction. Um and I would say anybody working with data at least in Rust has in some way, shape, or form uh interacted with DataFusion, seen DataFusion, heard about DataFusion.
So, let's look a bit a a little bit about those integrations and we'll highlight specific aspects of how kernel integrates with each of these integrations. So, first, Delta RS. Delta RS is the foundation for the Delta Lake library um which is a Python library that allows you to interact with Delta tables. And the usage pattern is a little bit different. Large query engines like Spark don't really have sort of this interactive, I don't know, data science workflows, right?
They just fire off a query, do a scan. Um obviously, they do fancy caching and stuff like this in the background. But Delta Delta RS and Delta Lake, they they keep in memory a lot of the log in order to not redo that work, right? But whenever you perform an an an operation on a Delta table, you need to update that state. And I don't know, we've seen checkpoints that are, I don't know, 3 GB large. So, you don't really want to go for every update, read 3 GB again from cloud storage, pay all of that cost um via latency or just sort of pure egress costs of shoving all of those bytes around.
So, we need to supply APIs that allow you to incrementally update that state. Luckily though, since mentioned mostly what we do is we just operate on these iterators of engine data. And this is your data. Kernel doesn't hold on to any of this. So, what you can do is in many of those APIs that interact with the log you hold on to your data. And then there are these incremental APIs where you just kind of shove in your current state.
You say, "Okay, I don't know. This is the state from version five. Please give me the state from the latest version back." And you'd run it through kernel again. It updates, mingles, mangles again using your own expressions, your I don't know if it needs JSON, parquet, whatever, reads it, leverages that. And on top of this what Delta RS also does is some let's say delta aware caching within again the engine implementation trades, right?
So, we know for instance that the JSON reader is used to read JSON files from the log. So, we can kind of apply some smart caching based on top of this that is very domain aligned because we know what it's used for and we know what it does. But this massively speeds up obviously updates because you don't need to replay all the log. And that's something that allowed us to really streamline the implementation of Delta RS.
And our users on one hand they they want all the log. On the other hand, they want a minimal memory footprint. And the architecture that kernel came up with kind of allowed us to fulfill a a of those needs. Obviously, it's a journey, and uh more is coming. Um but yeah, this is Delta RS. So, also Delta RS, beside of Delta Kernel RS, always welcomes contributors. So, if you're happy, uh go by the repository, have a look at it.
Another one is DuckDB. The kernel team has been working closely with the DuckDB folks, and when we claim interoperability between query engines, I mean, there are people out there that maybe have the opinion that all the query engines should be written in Rust, but they aren't. There's other query engines out there, uh DuckDB being one very, very popular written in CC++. And the work with the DuckDB team was around, okay, can we validate that this actually works?
That we have come up with a with an architecture that allows to interoperate across language barriers. The way to do this is FFI, foreign function interface. So, and here, yeah, some some very smart engineers on the team came up with ways how to bring some of the safety of Rust into the the FFI APIs. I'm not saying they're safe, right? There's still a lot of responsibility on the on the side of the the the query engine, in this case, DuckDB, but it worked really well to clearly communicate what can be transported across this boundary and how this works.
DuckDB on the also is a good example of what mentioned is they don't actually um implement all the traits themselves. They use the default engine for much of this, and it can still be kind of the raw DuckDB performance you're getting, even though you're using these traits based on the approach that showed for her before, that you have sort of this metadata phase where you do the logical planning, but after that, we just hand everything through the engine and DuckDB, for instance, has an amazing parquet reader, right?
So, um replacing the parquet reader in DuckDB with something custom would be, I don't know, taking some of the core strengths away from DuckDB. But, DuckDB is 100% in control in pushing all the predicates into the read, I don't know, doing all the optimizations they want to do, reading the actual data from the files. They just leverage the default engine to do the metadata scanning um and essentially get this logical plan that um mentioned back.
So, if you want to look at it or contribute to it, there's the repository, obviously, for that as well. And last but not least, let's look into DataFusion. DataFusion, interestingly enough, implementing a trait isn't all that hard if you're already working in your engine. Why is that? Um because the implementation doesn't require you to learn any new concepts, really. You're still within your own language. You're still DataFusion already has expression handling and you just need to wire it up.
DataFusion already does parquet reading. You just need to wire it up and pass through the parameters, right? So, the implementation of the engine itself was not so difficult, but one thing we want to highlight is how easy it is today to use uh the kernel kind of kernel-enabled engine with DataFusion. And if you look at this, this is a functioning program um that allows you to query a Delta table using DataFusion. You see, there is this extension trait that you can import.
And then, the first line where we create the session context you you call this enable Delta function and this wires up thing in the background. You still need to register, but this is by design all the object stores, caches, whatever you want on your session. But this is what the engine should control, right? Delta does or Delta kernel doesn't take any opinion on how you should do IO. So you still do the work you usually do to integrate with your A3 buckets, with your I don't know Azure object stores and it fairly transparently just gets used in the background.
So that work really really well. One thing we want to showcase here now is uh you can use this integration also and one mantra, I say, is that a word? Mantra um that comes up in open table format as metadata is data. And I think kernel really embraces this by not, I don't know, making stuff explicit structs, but just saying we process data. So let's try if we can create a Delta sharing server on this slide. It's ambitious, but but let's try.
Um we we we limit ourselves to let's say the most important endpoint in Delta sharing, which is where you actually read the table. Um Yeah, so let's see if we can make that work. So the first thing we do is and this is something that the the engine also provides is a table provider that allows you to do a log replay that gives you kind of the well, the files that you require from um well, they they they're part of your scan essentially.
You then define an expression in terms of the expression language within data fusion that transforms a little bit and I cheated because there is this sign URL function that is a custom defined function but it's a function that's already more or less there. So, the object stores the abstraction for accessing storage and DataFusion already knows how to sign URLs which is what you need to do and then you reshape it you serialize it into uh new line delimited JSON and you send it back.
And we actually have an implementation of uh an experimental let me highlight that, very experimental implementation but this technically is a working implementation of a Delta Sharing server using um Kernel uh and the DataFusion engine for Kernel. So, I thought that was pretty neat that this uh that we could fit this on a on a single slide. Yeah. So, thank you so much. Some exciting work that has been done uh write support checkpointing and there's more exciting work coming up.
I think a lot of people enjoy variant type or excited for variant type. Um actually I don't know exactly, you want to say a couple of words about catalogs because that's just something where Yeah, certainly. There's a lot of uh ongoing work right now for a new table feature, um catalog managed tables. So, Kernel is obviously a large part of that and we're discussing how to um reorganize some pieces of Kernel to be amenable to those new tables.
And uh I'll just keep going on the last couple bullet points. We have uh we are going to index much more heavily on better documentation, um making sure that this is an approachable project um in terms of engine developers as well as contributors to the Kernel directly. Um and we're looking forward to even more integrations from all sorts of different engines. Uh we're on GitHub and yeah, thank you all for coming.

Learn more about the Databricks Data and AI platform.