Skip to main content

Lakebase 101: core workflows and the Lakebase experience

Summary

  • This video introduces Lakebase as a serverless PostgreSQL database with decoupled compute and storage that autoscales in under 500 milliseconds, scales to zero when idle, and supports read replicas through a shared storage layer without physically duplicating data.
  • Core workflows demonstrated include provisioning a database, creating instant development branches using copy-on-write semantics, performing point-in-time recovery in under one second, and controlling costs through autoscaling and scale-to-zero pricing.
  • Lakebase integrates natively with the Databricks Data and AI platform through Unity Catalog federated tables, bidirectional Lakehouse Sync for analytics, and Genie Code for natural-language querying, with a benchmark showing 4ms Lakebase response versus 7 seconds for the same point-lookup against a SQL Warehouse.

Lakebase 101: core workflows and the Lakebase experience

Watch: Lakebase 101: core workflows and the Lakebase experience
New to Lakebase? this video walks you through the core workflows that define the Lakebase experience: provisioning a database, connecting your first application, using branching for safe development, applying point-in-time recovery, and controlling costs with autoscaling. Through live demos, you'll see how each feature maps to real-world scenarios and why running your operational database directly on the lakehouse changes what's possible for applications, analytics, and AI. No prior Lakebase experience required.
Talk By: Hatim Binani, Solutions Engineer, Databricks ; Youssef Mrini, Sr DevRel, Databricks ;

Chapters

FAQs

What makes Lakebase different from traditional managed PostgreSQL databases?

Lakebase decouples compute from storage, meaning resources can scale independently and scale to zero when not in use—eliminating the need to provision for peak load at all times. Traditional managed PostgreSQL databases tightly couple compute and storage, making it expensive and slow to adjust capacity. This video demonstrates that Lakebase autoscales in under 500 milliseconds and creates database branches instantly using copy-on-write semantics, capabilities not available in legacy managed Postgres offerings.

How does database branching work in Lakebase?

Lakebase branches use copy-on-write semantics similar to Git branches, creating an instant logical copy of the database without physically duplicating all the underlying data. Developers can use branches to create isolated staging or development environments without the time or cost of copying an entire production database. This video includes a live demo showing a development branch created and used instantly, with changes isolated from the main database until merged.

What is Lakehouse Sync and how does it enable bidirectional data movement?

Lakehouse Sync enables bidirectional data movement between Lakebase and the Databricks lakehouse, allowing operational data in Lakebase to be analyzed at scale with Spark or SQL while analytics results can be written back to Lakebase for application use. Unity Catalog federated tables also allow querying Lakebase data directly from the lakehouse without physically copying it. This integration makes Lakebase a natural fit for applications that need both low-latency operational access and analytical scale on the same platform.

What latency advantage does Lakebase provide over SQL Warehouse for point-lookup queries?

This video demonstrates a benchmark showing Lakebase delivering approximately 4ms response times for individual record lookups compared to approximately 7 seconds for the same query against a SQL Warehouse. This difference reflects the architectural distinction between an OLTP database optimized for row-level access and an analytical warehouse optimized for large scan queries. Lakebase is designed for the point-lookup and low-latency transaction patterns required by applications, while the SQL Warehouse remains the right tool for analytics and reporting.

Full transcript

[00:08] Big thanks to Alison for overselling us. Please make sure to ask only easy questions. So today we're going to be talking about of course Lake Base 101. And before we start, just want to make sure like how many people uh have already used or
[00:22] heard about Lake Base. Oh, so thank you so much. So for today's agenda, so we're going to start by talking about the product and
[00:34] then Hatim will take the lead on the integration and where it fits and we're going to end this presentation with two talk with two talks with two uh two demos. One about how it fits with the
[00:46] data bricks apps and the second present second demo we're going to deep dive a little bit on the lakebase interface. So let's try to answer those three
[00:58] questions. What's lake base? How it works? And what it what makes it different from the other databases? I'm pretty sure all of you or at least
[01:10] some of you have already vibecoded apps. Like I'm pretty sure we have more apps than people on the planet. And every single company are building those apps. make sure that they they display the results to their end user and make sure
[01:23] that they increase their AOE and the apps are getting better and better. We have now like stateless serverless they are more intelligent then the offering is getting like wider but the problem is that those those apps are intelligent
[01:37] but they still use monolithic databases architecture that has been developed on the 90s and they are not designed for those genai era and that's not the only
[01:49] problem like most of the most of databases are rigid why because the compute and the the storage are coupled or tightly coupled which means if I want to increase a little bit of memory of
[02:02] RAM well I'm obliged to increase the storage which means I need to increase the entire workloads for just some like more memory and of course I need to make sure if I'm for example I'm sales company I need to make sure that I
[02:14] provision the right infrastructure for my for my peaks for example I don't know it's black Friday which means I I will pay for the like highest peak like 24
[02:26] hours per day and seven days a week which can represent huge amounts of money and of course it's going to also slow developers. Let's suppose you have a team you want to create your like two new branches for uh staging and dev you
[02:41] need to like copy the entire database or just a subset of it. It's going to take time and of course also money and we need to make sure in this era that we are agile because this is the only way to survive. In addition, you have also
[02:54] weak lineage because you have a very limited history retention and very very slow point in time recovery. And of course, you need to make sure that your database can be audit audited and meets
[03:06] the auditory requirement. And of course, because those databases have been architected in the '9s, they are not designed for this GI era. And I'm not on um and also we need to talk about the
[03:19] tax integration because I'm pretty sure you have an NOLAP database and to make sure that you switch the transactional database we need to to copy the data and to do so we need to create a custom ETL
[03:33] duplicate the data duplicate the governance well it's a lot lot of a lot of cumbersome and to answer the first question I asked lakebases posgress and here I'm not saying that Lake B postgrad is not good.
[03:47] That's totally the opposite. Postgra is like one of the fastest growing database on the market for the during this last decade. The performance are just amazing and of course it's fully asset. You have indices you have join CTS triggers
[04:02] triggers procedures and of course it benefits from a wider uh number of extensions such as PG vector PG crypto. And the goal here is that we're like literally inventing
[04:14] a new architecture. So to summarize lakebase is a fully managed serverized posgress and as I mentioned we are taking the best of posgress and as usual data bricks is embracing open source. Postgress is one
[04:26] of the best database on the market and we're creating a new architecture by decoupling the compute and the storage and this is very very important and of course with few twists and I will deep
[04:39] dive on every single uh every single twist. So this imagine if you have a database that can autoscale in less than 100 500 milliseconds. You could scale to zero things that you don't can't have
[04:51] right now. You can have branches. Imagine having a git on the top of your database, which means you no longer need to copy your data. You can have instantaneous snapshots and point of time recovery rather than having to
[05:03] schedule them each time and run them, which can take more time. You can have history retention up to 30 to 30 days. And of course, you can have more like read replicas easily instantiated.
[05:15] Subsequent provisioning and the most important one is you pay for only what you use. This database is not a myth, it's a reality and we're going to show you how it works. It's not a road map. It does really exist. So let's start
[05:28] with this serverless architecture. So as I mentioned, we are decoupling the compute from the storage. So and since and and and because of this, we were running this compute on
[05:40] managed Kubernetes and that's what help us start the computes in less than 500 milliseconds. And on the other side we have the we have what we call the safekeepers. So basically safekeepers are ingesting all the operations you are
[05:53] running on your database and which means ingesting the stream the stream stream wall and then the page server is indexing everything you're doing and putting them on pages and of course all
[06:05] the old operations are pushed to the object storage which can which are durable and multi availability multi availability zone and this is what help us uh let's say keep uh keep like scale quickly because we can add more more
[06:19] more compute, more C more memory, more CPUs without any downtime because the compute and the storage are totally decoupled. And of course, we have the autoscaling because you have the opportunity to
[06:31] define the mean, the the minimum and the maximum for every uh instance you will have. And of course, imagine you have a database where you can scale like the compute of the database can scale up and
[06:44] scale down in less than less less than one second. It's just insane. which means you no longer need to think about provisioning the the peak of compute like having your instance handling the peak. It can go down for it can go up to
[06:56] I don't know 20 GB and then going down to 5 GB immediately. And this is this is amazing. That's why I mentioned that's driven by CPU. And of course you have to scale to zero. So basically when you're creating your compute you can define it
[07:10] from 60 seconds up to seven days but we tend to recommend at least five minutes. And this avoid like let's say this having this cold start. And as I mentioned, you always pay only when the compute was active. So no longer need to
[07:24] pay for the idle time which means you're going to reduce your reduce your uh your cost and make sure that your application is always performing and we also have red replicas. So
[07:36] remember I told and I will keep repeating myself many times. So my apologies. We're decoupling the compute from the storage. So as you can see over here we have the uh we have the first instance which has like uh which is a
[07:48] primary can read and right and if I want to add more let's say read replicas since the comput is decoupled for the stories and they are sharing the same lakebased stories I no longer need to duplicate the data to make sure that my
[08:01] my my read replicas are accessible. So I can scale them as much as I can. I can define their own their own size and they can also autoscale which means you have autoscale that can start the read
[08:14] replicas that can start immediately without duplicating the data and of course we have on the top a load uh a load balancer to make sure that it's not let's say searchcharge and this is this
[08:26] is very very important and each replicas as I mentioned can scale can scale to zero independently from uh from the others when when idle And I did mention previously the
[08:38] branches. So imagine you are you're a developer. You have access to the production database. What if you want to clone it? So basically you can just create a new branch. In the past you would have copied the entire database which means create another instance pay
[08:51] for uh pay for like the storage and which can be a little bit uh it's expensive. So over here we have slight uh copy on right which means you won't be paying the storage wise. to only be
[09:04] paying for example if on my my the second branch that I did that I did create I modified for example a new I added a new row then I'll be paying for just the different or the delta of the storage that's it and it's literally
[09:18] instant in instantaneous and it's fast to create will show you how to do this a little bit later and same thing for the for the snapshot basically it can capture branch at any time at any time
[09:31] you can either schedule it or and by default I mean it's it's automated and you can restore it in less than one second. So as you can see it's super super fast and you can also go back to any to any uh let's say point in time um
[09:46] within of course a 30 days history uh retention that that would have uh set up at the beginning and of course it's built for the high availability remember at the beginning I
[09:59] mentioned that we are decoupling the compute from the storage and you can count how many time I will repeat myself
[10:11] safekeepers are available in the three availability zones and how it works. So we're going to have a quorum if two out of three are saying yes then this transaction is uh is validated and that's why we have this active uh
[10:23] standby pace servery in evaluate user and every and we have redundancy and this is and something you need to be something very important to keep in mind compared to the monolytic database where and they need to make sure that they
[10:35] need to catch up everything before let's say serving the traffic in lake base things happen like instantly so we no longer need to wait everything is served in Everything is served immediately which means it's very fast and quick
[10:50] and of course you you deserve the best security and that's why on the top we have of course identity access so basically you have the o via via via data bricks and you can also have the native posgress uh password o
[11:03] permissions everything is encrypted on transit with TLS and at rest and you can also bring your own CMK customer uh manage key you have also a network isolation so for Those who are familiar
[11:15] with security, you can bring your your private link and and IP alles to filter the IPs who can access the database and of course put all like um all the permissions you can have on the uh on
[11:27] postgress and you have tenant isolation. This is very important. You benefit from the audit and lineage. So basically everything happens are logged in system tables. Uh which means you can you cannot wipe anything. So,
[11:40] oops, just imagine slides are here.
[11:53] have to fix this issue.
[12:05] I'll keep going until I fix. And so, so just keep just just bear with me. And we're going to now talk be talking about actually the pricing. So basically when we're talking about the compute we have what we call the the the compute units CU. So basically every one CU is equal
[12:19] to giga two 2 GB of RAM. And for example when you going to be and that's what Hatim is going to show you when you're the when you're choosing your instance you're going to choose what's the minimum C capacity unit and what's the
[12:31] maximum that's going to be the range to scale up and scale down. Of course you will be able to define which means how long will be how big your instance is it between 10 GB to I don't know 128 gigabytes with of course the to the
[12:44] scale to zero and of course when it comes to uh Postgress we have also in addition the storage of the uh the storage of the data you will have because it moved to to uh to row storage
[12:56] with key value pairs and yeah you have it here. So basically the data stored you will be paying for the data stored but the branches as I mentioned only the delta and it's configurable between two
[13:08] to 30 days and of course you won't be paying for the reader the the the comput the storage of the read replicas because they are sharing the same lakebased storage layer which means no longer need to duplicate the data
[13:22] and with this team can will take the lead. Thanks Yousef. Uh all right let's talk about how lakebase is actually integrated in the datab bricks ecosystem.
[13:34] So uh as you may already know uh unity catalog is one of the main components of the datab bricks platform. It's the governance layer that comes on top of uh everything in the platform and lakebase
[13:47] is natively integrated with unity catalog. So uh you can actually register your lakebased tables or lakebased databases in a unity catalog as readonly cataloges. Um and so this way you will
[14:01] have in the same place your lakebased data sets and your lakehouse data sets. Um and what this does is that you will have this unified governance. So you're now able to manage your permissions,
[14:13] your lineage, uh, audit logs and all the governance um, aspects at the same place. So no need to wrangle between different systems. Um, you're going to also be able to do uh, some unique
[14:27] capabilities like cross queries. So you can mix and match between u data coming from an OOLTP and an OLAP in a single SQL statement.
[14:39] um you will have a centralized discovery uh since everything sits uh in the same place uh through the catalog explorer. You can see in the same times the lakebase object but also your lakehouse
[14:52] already existing uh data sets and finally lake bay is actually integrated also with all the rest of the platform. So uh you can use lakebase uh directly in your dashboards in your notebooks uh
[15:05] in apps or even in your genie spaces. So um you can boot up a genie have a bunch of tables from lake base some tables from lake house and start interacting in natural language uh with your whole
[15:19] data. So what I showed earlier was called unity catalog federation. But what if you want to go a bit further and actually synchronize physically the data between uh your OLTP and your OLAP
[15:34] system. So between the lake bays and the lakehouse. Well, for this uh if we go from lakehouse to lake bays, we have what we call sync tables. Um and this is what makes it possible to do reverse
[15:46] ETL. So to take data from UC tables from lake lake house and synchronize it either on a on like a one-time copy snapshot or through triggered schedules
[15:58] um into the lake base. Um but what most interesting or the most interesting aspects about lake bay is actually the other way around. To take data from lake bay into the lakehouse uh we can go
[16:11] through what we call lakehouse sync. And what does this what this does is that it continuously and in a low latency manner replicates the data from uh your Postgress tables into Unity catalog
[16:24] manage tables. And here the this is a copy of the data to the lakehouse. Uh but what's particular is that you actually don't need any external compute or pipelines or jobs uh in order to do
[16:37] this copy since uh well due to the architecture of lakebased data already sits in object storage. So it's already um ready to be uh copied directly to lakehouse.
[16:53] Um another interesting integration is um is that lakebase and genie code are can work together. So basically you can leverage Genie code to generate and execute uh code against against lakebased table ask it to synchronize
[17:06] for you from lakehouse to lakebase or even connect databicks apps directly to to lakebase. So now you don't even have to um know SQL in order to interact with
[17:20] your uh transactional database and uh soon there will be actually a new uh a new tab on your lakebased UI. So Genie is going to be a first party um
[17:34] feature inside the the lakebased UI. So this is coming soon. All right. Um now let let's talk about uh where lakebase fits in the competition landscape and first I want
[17:47] to do a quick comparison with traditional managed uh postgress since lake base is already postgress so um what's the twist um well as you may see lake bay has all the features of a
[18:01] traditional managed uh posgress with some perks u well lake bases is is actually faster so when we take capabilities basic capabilities This is like provisioning, scaling or recovery
[18:13] point in time recovery. Things that takes seconds to uh minute sorry minutes to even hours in traditional managed posgress take less than a second in in lakebase. So the promise is pretty much
[18:27] anything you do in lakebase is instantaneous. In terms of costs, lakebase is cheaper. Um since we have capabilities in lakebased like uh scale to zero where
[18:40] you don't need to pay for idle uh compute compute turn are turned down when they're not used whereas in traditional managed posgress you're kind of obliged to to pay for a provisioned
[18:53] capacity either use it or not and finally like bases is very well integrated in the lakehouse uh in the with the data bricks uh platform and you
[19:05] don't need to write any custom ETL as as you would have um been doing with the with manage postgress in order to go from one to the other. Uh what about other vendors? Well, other
[19:18] vendors actually have nailed uh one or two of these features very well. Uh but none of them actually delivers the whole combination of of of these features. And Lake Base has some very unique uh
[19:31] features uh that aren't u out there. Uh I'm thinking things like copy or write branches um and even the the the performance of subsecond provisioning
[19:43] and this is really due to the architecture behind Lakebase and the fact that computer and storage are separate. I think I'm going to
[19:56] lakebase is very well positioned uh against other renders. All right let's talk about some use cases where we should be thinking lakebase. So the first one is if you
[20:09] want to serve your um analytical data so your lakehouse data but at low latency at application speed. So things like customerf facing dashboards with live
[20:21] KPIs or uh even for example if you have uh some machine learning learning models and you want to serve real time features uh for for these machine learning models well lakebase is is is your way to go.
[20:35] Um another maybe more traditional uh usage of lakebase is if you want to power a transactional app or even AI agents. So uh and you can choose lakebase as your backend database for
[20:49] for these applications and AI agents. And finally um well if you want to analyze operational data uh in the lakehouse so um do things like um like
[21:02] analysis on five years of data from your operational systems but you want this you want to do this in your OLAP system. So with things like lakehouse sync lakebas is is is the way to go also for
[21:15] for these use cases. Okay. So to sum it up um in three points lakebases postgress you already know it's not a fork of posgress. It's not a
[21:28] kind of version of posgress. It is posgress. So all what you've been doing with postgress can be done with lakebase. So you can either use your your favorite IDE let's say to to um to
[21:41] interact with with lakebased like debaver or or PG admin and your team uh is productive on day one. So they already know the language. Uh second it's built for the AI era. So uh with
[21:54] features like branches, snapshots, subsecond autoscaling. Um it's very well uh it's it's the the database that your agents actually need.
[22:07] And finally there are no silos to be maintained. It's only one platform. No glue to be done between different systems. U natively connected to Unity
[22:19] catalog. So the governance is there and no custom pipelines or second governance plane to to maintain. No integration tax.
[22:34] All right. And enough talking. Now demo time. I'll give it back to you. Thank you. This is a live demo. So this is a data bricks apps and I do
[22:47] recommend you to give it a try for those who haven't maybe create your account on data bricks free edition and no credit card required. Give it a try. lake base or lakebase is also available there. So
[22:59] in my app over here I have uh a bunch of customers 50,000 customers that I have that are sitting on my data lake and that I did sync with uh lake of course lake basease sync to to push to push the
[23:12] data to lakebase and that's what I have here. So as you can see I have 15,000 customers I have 13 orders the revenue products and uh when was the last sync. So I have over here I'm just going to
[23:24] compare uh two uh two uh engines lake base and SQL warehouse. Over here I'm going to run a lookup on for example let's say customer number 14.
[23:36] Of course this is let's say cold start for DBSQL takes time to start but okay so you can see over here and let's you can see over here. So lake base I was able to do lookup in 4 milliseconds
[23:48] and in DBSQL takes 7 seconds. We can run it again. and it will be on the cache it will be less than 1 second but still what you have to keep in mind that you need to make sure to choose the right engine for the right use case so for for
[24:02] for our example we are we are we are a sales company then we need to require a no no LTP uh engine which is lakebased for my case while for the OLAP and here I'm talking about DBC core lakehouse
[24:15] this is mainly designed for let's say to run complex aggregation on the entire on the entire historic history of the uh for example the company. So this is very important. You need to make sure to choose the right technology for the
[24:28] right use case. And over here let's suppose I have my app and this is the app that customers are using for example or sales people are using to see for example the profile or the user or when it's when I load I can see for example
[24:42] my lifetime value number of orders. So oops sorry. So I did load it. So we see it's 18 as you can see 18 milliseconds. So the lifetime value is 1,917 orders 25 and the return risk is very
[24:55] low. So if I select the same customer ID and here let's go for I don't know hollow ergonomic h mouse 6 bucks. So once I I I add it. So as you can see over here I have my my hello ergonomic
[25:09] mouse and you can see if I run it again the the the revenue is like instantly being instantly being updated as well as the number of or as well as number of orders. So as you can see both uh like
[25:23] everything of course this is not a print on the on the app. It's actually powered by Lakebay. So you can see how fast it did the the lookup and how fast it did the right. And this is really the apps
[25:35] that you the database that your apps deserve. And just to show you actually in the uh uh in the uh in the platform if you go to the dice demo. So over here
[25:47] I have the uh I have the I have the products and this is the uh customer gold. And if you want to create a sync you just need to come here and create a sync uh a sync table and then a pipeline
[25:59] will automatically be created for you. It's called pipeline database table sync. So you no longer need to do custom ETL. The platform design it. It's very easy to use and it's it's completely
[26:11] straightforward and Hatim will will keep going with to show you how you can create your first database and create your branches. Thank you. Okay. So let's try to create a lake base.
[26:25] So first lake base sits alongside the other features we have here. uh lakehouse datab bricks apps and genie one. So we can switch to the lakebase UI
[26:38] and when you want to create a lakebased project first uh lakebased instance first you need to create a project. So let's give it a name dice demo 101
[26:51] and I hit create and be uh give some attention here because in a matter of one two three four five six 7 8 9 and 10
[27:04] our lake base is up and ready and we can already uh connect to it. Um so as you can see here uh it gives you a connection string. It just as any uh
[27:16] Postgress any other Postgress database we can connect it through uh the IDE or any any um other tool out there. Okay let's see what we can do uh else
[27:29] with this uh database. So we can edit the primary compute configuration and in here we can for example set up the autoscaling parameters, set up a minimum and the
[27:42] maximum. Maybe also activate the scale to zero. And as you can see here the compute activation takes only a few hundred milliseconds. So if my compute was to go idle um and uh I use it again,
[27:58] it will only take less than a second in order to to to boot up. So this feature is a a nice a nice feature to be enabled. Okay. Um what can we do through the UI?
[28:12] So we can either for example write some SQL um lakebased some Postgress SQL as you as you may already know create some table insert in it and and select data.
[28:25] Um so we can see here that I've created this table here. Um, I can check also I have um a UI to check what's I do have in my database
[28:37] and what's the the data in it and even maybe add a record or add a a column in here. And here you're going to need to be very imaginative.
[28:57] let's try to fix this before going on. This is the perks of having live demo effect
[29:13] and the most exciting part isn't I haven't shown the most exciting part which is about branches. So uh let's see what can we do as an advanced advanced um features in in in lake base. So in lakebase we can create
[29:25] what we call branches and really a branch uh is um just a new database that you're going to be creating on on top of of of an already existing one but it's
[29:37] not going to duplicate the data behind the scenes. So I'm going to give it let's say the name of dev. Let's say this branch will become my development branch. I can choose to to never uh delete actually this branch. go from the
[29:50] production uh choose the the branch I want to go from and I when I hit create again instant in in an instantaneous a hard word to say uh manner I have a
[30:02] new database a brand new connection string that I can use uh as a really completely different database but the data behind the scene is the same.
[30:14] Okay, I can go on and maybe do some changes with this new branch. So maybe I'll add a new column here. I'll keep it as as is and review and comments.
[30:27] Let's go back to the data view just to see that my column has been added here. And now if I go back to the overview, I'm able to actually say see the difference between the old branch and
[30:41] the new branch. same as you would do with a a git um diff uh in in in GitHub for example and yeah go from there do some changes in uh in your g branches as
[30:55] well or align the branches in lakebase with the branches in in in your git repository. So this is um this is uh all about branching and of course I can um if I
[31:08] have let's say finished my development in this branch I don't need it anymore I can reset it from the parents and just drop the changes or I can even uh delete it.
[31:20] So this is a way to use the branches uh from the UI. But of course you can connect these branches to an agent for example that could boot up a bunch of branches and do some tests and then kill
[31:33] those branches without any duplication of data behind the scene. And this is the power of branches. Um now if you want to go a bit deeper uh into lakebase we can check how a backup and restore
[31:47] works in lakebase. A snapshot in Lake Base is also instantaneous. So once I click create, I have this snapshot that got got created and it's actually just a matter of tracking which uh delta
[32:02] version or iceberg version I'm in. This is a snapshot. So there is no um copy of data done behind the scenes. Restoring is exactly the same. So when I
[32:14] click restart um here I will be um I will be prompted to a new branch that got created from this uh snapshot and I can go from there. So it's it's tied to
[32:27] a new compute and I can connect to it and start using it. Okay, that's it for my demo. Uh this is Lakebase is it's GA already um available in either the free
[32:39] edition or your workspaces. So please give it a try. And by the way, one more thing, it's the database that your apps deserve.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.