# Real-time energy trading and analytics on Databricks > Source: > Published: 2026-10-23 19:00:00+00:00 See how Databricks combines real-time energy trading, risk monitoring, machine learning, and historical analytics with one platform and one governance model. by [Victoria Sicking](https://www.databricks.com/blog/author/victoria-sicking) and [Jack Yallop](https://www.databricks.com/blog/author/jack-yallop) Energy trading desks work in markets where conditions change quickly and decisions are measured in milliseconds. Two changes make this harder: higher price volatility, and the move [EU’s day-ahead electricity market move from hourly to 15-minute trading intervals](https://energy.ec.europa.eu/news/eu-electricity-trading-day-ahead-markets-becomes-more-dynamic-2025-10-01_en). The 15-minute market time unit is part of the Single-Day Ahead Coupling (SDAC), the system that connects day-ahead electricity markets across EU countries. This creates four times as many market periods per hour and increasing the volume of records, orders, and risk recalculations. Keeping those calculations accurate requires data that is current – which points directly to how data is stored and governed, not only how fast it arrives. Stale data is more than an inconvenience for a trading desk. It can make risk controls reflect an earlier state of the market, contribute to missed intraday moves, and put desk limits out of sync with current positions. Many organizations respond with two stacks. An operational system supports the live desk and millisecond transactions. A separate analytical system supports strategy backtesting, machine learning and regulatory reporting. The split matches two different workloads, but it creates four recurring problems: Machine learning adds another dependency. Models need historical data for training, but their outputs must be available in the live trading workflow. Moving models and data between separate systems adds complexity to an already time-sensitive process. The alternative is a unified platform for data, analytics and AI – one that [Real-Time Mode streams](https://www.databricks.com/resources/demos/videos/apache-spark-rtm) in with millisecond latency and Lakebase Postgres holds ready – so both the live desk and the model pipeline draw from the same source without an extra transfer step. Operational and analytical workloads run together by sharing one data foundation. The solution presented below by Victoria Sicking, Solutions Architect at Databricks, described in **'**[Run Live Energy Trading, Risk, and Analytics in Databricks](https://www.databricks.com/resources/demos/videos/run-live-energy-trading-risk-and-analytics-databricks)**'** below combines six components on the Databricks Data + AI Platform, and the key design choice is that no component maintains its own separate copy of the data. All of them work from what Spark Structured Streaming Real-Time Mode has written into Lakebase and the lakehouse. Spark Structured Streaming Real-Time Mode receives market data and streams it into [Lakebase](https://www.databricks.com/product/lakebase), used here as the operational (OLTP) database for millisecond reads, transactions, and upserts. The same data can then support the analytical workloads built on the [lakehouse](https://www.databricks.com/product/data-lakehouse). Teams no longer need to coordinate parallel pipelines, one for the live desk and another for backtesting and reporting. Time previously burned on reconciliation and coordination is released by creating a single ingestion pathway into your data estate for market and position data. [Unity Catalog](https://www.databricks.com/product/unity-catalog) – the Databricks governance layer for permissions, lineage and audit – applies that governance across the app, business intelligence and machine learning workloads, so they are not configured independently in multiple systems. It looks like a single application showing prices, positions, profit and loss (P&L) and risk, all updating as the market moves. The live experience is built on [Databricks Apps](https://www.databricks.com/product/databricks-apps) – the way to build and host data applications, such as a live trading interface, on the platform – bringing together what a desk needs to monitor the market and act on changing conditions, served directly from Lakebase so the desk is always reading from the same governed data that feeds the analytical workloads, with no separate operational copy required. The demo displays instrument prices for Brent crude, German and French power spots, EUR-to-USD conversion, EU carbon allowances (EUAs) and TTF gas. Risk is monitored against the desk's limits in the same workflow. When a measure approaches a limit, the app raises a risk alert so the desk can see the change and respond immediately. This replaces a nightly batch process that calculates risk from an earlier snapshot of the data. The application is not a reporting surface disconnected from the data platform. Lakebase provides the operational layer behind the app, and the streaming pipeline keeps the information current. Train machine learning models on the same governed data that supports the live desk, track their development and lineage with [MLflow](https://www.databricks.com/product/managed-mlflow), and deploy approved versions through Databricks [Model Serving](https://www.databricks.com/product/model-serving). Their outputs can then surface directly in the app. Energy trading teams need models that can anticipate risk and identify potential trade signals, and running everything on one governed, unified copy of the data removes the handoff between a training system and a live system – the model sees exactly what the desk sees. The demo shows a real-time price forecast that can contribute to a trade signal. The path between the data used to train a model and the workflow that consumes its output gets shorter. Machine learning becomes part of the end-to-end trading workflow rather than a separate system sitting between the live and analytical stacks. The same governed data can also support risk analysis and model development. Operational and analytical workloads stay connected, and teams do not need to reconcile separate versions of the data after the fact. Analysts use an embedded dashboard and Genie One, both built on the same data foundation as the live app. The embedded dashboard presents historical trading data, including total trades, traded volume and comparisons between traders. For deeper analysis, analysts can use SQL, Python or Spark. They can also use [Genie One](https://www.databricks.com/product/genie/one) – the Databricks natural-language interface for asking questions of governed data – without writing the query themselves. In the demo, the analyst asks Genie One to identify the top five counterparties by number of trades and compare total buy volume with sell volume for each. Genie One works within the Databricks workspace and uses the available data context and defined semantics to answer. Analysts can move from a dashboard view yielding fixed insights to a bespoke analysis of the data while staying in the same governed environment. A unified copy of the data means results agree between the live desk and the analytics back-office. Data flows from a market feed, through streaming and Lakebase, to the app, analytics and machine learning, all under Unity Catalog governance. Because Unity Catalog spans every component, the permissions, lineage and audit that apply to the live desk also apply to dashboards, Genie One and machine learning – configured once, not reproduced in each system. The steps are: The live desk, analytics and machine learning workloads are not separate destinations that need repeated data movement. They are different ways of working with the same governed data. The question is whether operational and analytical requirements must be served by disconnected systems with separate copies, governance models and synchronization logic. They do have different requirements, but one platform can serve both and consolidating on one governed copy of data means the desk, the risk models and the reporting layer are never out of sync with each other. When these workloads run on separate systems, risk controls can depend on batch data, models can be trained on information that does not match the live system, and governance, lineage and synchronization pipelines must be maintained more than once. The Databricks Energy Trading solution brings these capabilities together on one governed data foundation. With this setup, teams can evaluate risk as the market moves while using the same governed data for P&L, exposure, backtesting, machine learning, dashboards and natural-language analysis. To learn more about how you can get started, visit: Separate systems can create two versions of the truth, a freshness gap in risk controls, duplicated governance and lineage, extra maintenance work, and additional synchronization pipelines between systems. Machine learning also becomes harder to manage when models are trained on one system but must run on another. Maintaining one governed and unified copy of the data, with a single set of controls, removes most of these costs. Energy trading teams can run the live desk, risk, machine learning and historical analytics on one governed copy of data in Databricks. Spark Structured Streaming Real-Time Mode, Lakebase, Databricks Apps and Unity Catalog replace the second system and the duplicate controls. Lakebase is a fully managed Postgres database native to the Databricks Data + AI Platform, used here as the operational (OLTP) database for millisecond reads, transactions and upserts. Because it sits within the same platform as the lakehouse, it connects operational data with analytical workloads on one governed and unified copy of the data rather than requiring a separate database outside the platform. A live trading application built on Databricks Apps, the way to build and host data applications, such as a live trading interface, on the platform, can display prices, positions, P&L and risk as they update. Risk alerts trigger as measures approach desk limits, so traders respond to current conditions instead of relying only on batch calculations. Unity Catalog is the Databricks governance layer for permissions, lineage and audit, providing one governance layer across the operational application, analytics and machine learning workflows. It maintains centralized permissions, lineage and audit end to end, so teams configure controls once for the single copy of data rather than reproducing separate governance for each system. Subscribe to our blog and get the latest posts delivered to your inbox.