Fast applications need the right database. But do they?
It is very unlikely that your application does not store data in some form or shape. Whether it is a user profile, shopping cart, customer data or inventory details. Every application needs data. But every application requires something different. A social network needs to quickly identify similar interests and a financial application needs aggregated data and maybe trend analysis. And an online retailer is much more interested in targeting individual customers with recommendations.
For all these type of applications there is almost an unlimited number of options. Traditional relational databases like Oracle, SQL Server or Postgres build upon 50 year old principles. And no-sql options like Mongo looks much more developer friendly with schema on write principles. And today it looks like more purpose built database are finding their way to developers.
Yet, a disk is a disk and memory is memory. Storing data on disk is a trivial task for every database system. Understanding how this works and what you can control will help you better understand the performance of your application. Because, believe it or not, the performance of your application is based on how you model your data. Not which database system you use.
In this session I will show different applications with their own specific database requirements. I will show how to model this in a traditional relational database system. In my case, Microsoft SQL Server. But I believe the same principles apply to other traditional relational databases as well.
So if you want to learn how to model your data to maximize application performance, come to this session.
Next-Gen Meta data driven pipelines 2.0
Most data engineering projects are larger then a single fact table and one or two dimensions. Probably more then a handful sources. While most samples out there are built around how to get a source file into a table the reality is that, in real life data engineering is much more then that.
But having tens or hundreds of sources that all must be copied into a staging table often means repetition. So it will not be long before most people resort to a meta data driven framework or just roll their own. And it is not new, I saw projects build this way 20 years ago. Simply because it gets the job done.
This session will show what the downside might be when using meta data driven pipelines and what possible solutions you have to work around these. Hopefully you will walk away with some new insight you can apply to your data pipelines right away.
My database will be hacked. But I don't care.
My database will be hacked. But I don't care. It is a bold statement. But reality is that there is a good chance your database or application will be hacked at some point. Data will be stolen, or held hostage. But by far the biggest problem is the impact it will have on the people that trust that their data is safe in your hands.
Still a lot of people seem to be not aware of this risk. Or think that it doesn't apply to them because they are a special kind of company that will never be exposed. Truth is that every company can be a target at any moment. So, with that in consideration what are the risks you see?
This purpose of this session is to get a discussion going at you company by identifying the current risks and if you can mitigate them. The ultimate goal would be that your company gets hacked, someone gets access to the database but no usable data was stolen.
DevConf 2026 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top