Databricks Apps

Question regarding Databricks Apps deployment

Anyone playing around with Databricks Apps yet? Thoughts & initial impressions

Hey everyone, I’ve been testing out the new Databricks Apps feature recently, and I wanted to see how others in the community are using it. Historically, if we wanted to spin up a Streamlit app or a custom dashboard connected to Databricks, we had to deal with separate hosting (App Service, EC2, etc.), network security groups, and handling OAuth tokens separately. With Databricks Apps, running a Streamlit/Dash app directly inside the workspace using Unity Catalog for permissions has been a game-changer for internal tooling. That said, I'm curious: Are you using it for production workloads or just quick internal prototypes? How are you handling CI/CD deployments for these apps? Have you run into any limitations with serverless compute or scaling yet? submitted by /u/SalamanderOpen859 [link] [comments]

Query on Databricks apps idle time out

A full month-end finance app built on Databricks Apps

Below are the things covered in the video: 1. Overview: drag the month slider and every figure on the page moves with it, including a cash flow diagram from sales through to profit 2. P&L: the statement drawn as a ladder from revenue down to profit, plus a bridge showing why we beat or missed budget 3. Cafes: ranking, a map of the Front Range, a margin heatmap by month, and how fast each new cafe paid back its fit-out 4. Menu: which items earn their place and which are just popular 5. Cash: a 13-week forecast, overdue invoices by age, and the supplier payment calendar 6. Close: the month-end checklist as a board, with how long each close took historically 7. What-if: move price, volume, wage and ingredient levers and watch profit change 8. A one-page monthly report that prints to A4 Under the hood: seven Delta tables in Unity Catalog, read through a SQL warehouse, with the app running as a Databricks App in Python. All the finance logic (consolidation, budget variances, the close tracker, the cash forecast) sits in one file that a finance analyst could read. submitted by /u/oneaffidavit1 [link] [comments]

Quest 5 Complete - Engineering handbook knowledge base with RAG, deployed on Databricks Apps.

Databricks Apps/Jobs Deployment Issue on New Workspace: Due to Quota?

My company sells a data analytics application to professional sports teams. The application is built as a Databricks App, deployed into a customer's workspace. The underlying data model is seeded by ETL that lives in my own company's workspace, with the gold tables shared as pinned version views into the customer's workspace, where a daily job syncs the views into Lakebase on the customer side. I built this on Databricks partially because the customers typically don't have robust IT teams in-house. Rather than requiring them to self-manage a bunch of infrastructure or host my own costly SaaS backend, I figured I could save a lot of complexity by setting up a Databricks workspace for them and deploying the application code into it via DAB from a central repo. I'm having an issue with a new customer that I onboarded yesterday. They created a new Azure subscription for the purpose of deploying the Databricks workspace + our application. Everything deployed successfully, but the Databricks App stops itself after approximately two hours. At first I thought it was a transient issue and restarted the app, but it keeps recurring. Troubleshooting has been challenging, because App logs are not visible when an App is stopped. I was able to get the following from the CLI ( databricks apps get -o json ): "app_status": { "message": "App status is unavailable.", "state": "UNAVAILABLE" }, "compute_size": "MEDIUM", "compute_status": { "message": "App compute was stopped due to workspace or account status.", "state": "STOPPED" }, Both the Azure subscription (Azure Plan) and the Databricks workspace (Premium + RBAC) do not appear to be in a trial state. Both were set up in the past 48 hours. I suspect this is some kind of new workspace restriction on the Databricks side, but I'm not sure what can be done about it. The App is deployed into a few different workspaces and runs without issue, but all of the workspaces have existed for a while. This is the first Workspace that was deployed specifically for the App. I found this thread on Databricks Community that describes a similar issue, but it appears to have died without a resolution. Has anyone run into a similar issue, and is there anything that can be done about this? It's likely that many of our customers will need a new Databricks workspace to deploy our application, so if this is a recurring issue, we may need to rethink our entire architecture. submitted by /u/Minute_Visual_3423 [link] [comments]

Databricks Apps vs Model Serving: Authentication, Cost, and Performance Compared

Databricks Apps gives you the app you wanted, without the React plumbing or the Power Apps limits

Are PATs (user or service principal) accepted by Databricks Apps?

Auto stop option on databricks apps

Want to request a feature for databricks app, it should have an auto stop option. I know Databricks markets it as a web app that should be readily available, but I think customers deserve the option to turn auto-stop on or off, like we do for, say, SQL Warehouses. This has been a major blocker for us suggesting apps to leadership, the engineering team has build some really useful apps for usecases like Data modelling and stuff which is used when needed but they running 24*7 all time is wasting compute and getting flagged in finops P.S i know we can have a databricks job which can shut down and start the app during working hours but we have a global team working round the clock so it's not feasible for us. If we have someone from databricks apps team this is a highly requested thing from alot of people around the community. submitted by /u/sumit671 [link] [comments]

Azure Databricks, two-week-old account: partner pay-per-token endpoints (Claude, Grok) have never once succeeded — "Databricks-set rate limit of 0" — and the Assistant has "no daily token allowance". Open models work. What gates this?

Azure Databricks, Premium, one account with three workspaces, Unity Catalog, Azure Marketplace billing (no card, no trial credits left). The account was bootstrapped on a trial workspace about two weeks ago and moved to Premium six days later. I've spent two days on this and want a sanity check from anyone who has seen it. The facts, from system.serving.endpoint_usage: • Every open-weight pay-per-token endpoint has worked since the trial: gpt-oss-120b has ~50 successful calls going back to the trial period, Llama 3.3 70B likewise, zero refusals. • No partner pay-per-token endpoint has ever returned a success on this account. The very first call anyone made to databricks-claude-sonnet-5 was refused, and every call since, on every Claude endpoint and on Grok, in all three workspaces, for users and service principals alike: 403 PERMISSION_DENIED: The endpoint is temporarily disabled due to a Databricks-set rate limit of 0. • It is not our AI Gateway config: I removed every rate limit from one Claude endpoint and invoked it — same 403. The endpoints' config shows nothing else. • The notebook Assistant worked during the trial. On the paid account it refuses everyone, admins included: *"This workspace has no daily token allowance for the assistant."* Underneath, /ajax-api/2.0/conversation/llmproxy/ returns 429 {"type":"daily_token_limit_reached","daily_limit_tokens":0,"message":"…Daily token limit of 0 reached. Resets at midnight UTC. (DTB)"} and it recomputes to 0 every midnight. • Once, the Databricks Apps in the workspace were stopped by the platform with *"App compute was stopped due to workspace or account status"* while every workspace showed RUNNING. apps start brought them back. Red herring, for completeness: we also created a Unity AI Gateway per-user budget whose first version had a $0 threshold with BLOCK_USAGE. That blocked Genie for a day, exactly as documented, and was fixed. It was created a day *after* the first Claude refusal, so it isn't the cause of any of the above. What I've found: two Community threads describe "Databricks-set rate limit of 0" as a workspace trust-tier gate — trial-born accounts sit in TRIAL_VERIFIED, pay-per-token partner models are gated to PAYABLE_VERIFIED, a card alone doesn't flip it, only Databricks Sales/Support moves the tier. Both were AWS/personal accounts, neither resolved on-page. The account console's own API reports our account's feature_tier as STANDARD_W_SEC_TIER although the workspaces are Premium; I can't find what that field means. Questions • Does Azure Databricks with Marketplace billing go through the same PAYABLE_VERIFIED gate? Does it clear on its own after the first settled invoice, or does someone have to move it? • If you were moved: who did you contact (account team, or "Contact us" in the console) and how long did it take? • Is the Assistant's "daily token allowance" the same gate, or a trial allowance that simply goes to 0 when the trial ends on an unverified account? • Does feature_tier: STANDARD_W_SEC_TIER on the account object mean anything to anyone? submitted by /u/sumit671 [link] [comments]

Time to Swap the Cookies for Jetfuel - New Dataset & New Databricks Genie Tutorial

Most of you know samples.bakehouse . Great for a first query. Perfect for a quick demo. But after years of cookie sales, it's a little overbaked. Time to swap the cookies for jet fuel. ✈️ Together with the OpenSky Network , I brought a full day of global air traffic to Databricks Marketplace: 696 million real ADS-B position reports, messy just like real life. Myself, I used Genie for the whole journey: EDA, data exploration, a Apache Spark Declarative Pipeline, and a Lakeflow Job. Then I went a step further and read the same Marketplace data with open-source tools only, using OpenSharing and pandas. The result is this hands-on tutorial: Marketplace + Unity Catalog: get the data as a governed table Genie Agents: find anomalies in plain English Genie Agents: explore and visualize with maps and charts Genie Code: a Spark Declarative Pipeline, bronze to gold, with data quality rules Genie Code: a Lakeflow Job with schedule, retries, and email alerts Databricks Apps: your coding agent, governed by Unity Catalog OpenSharing: the open-source client in VS Code with pandas Everything runs on Databricks Free Edition (free, no credit card). 📖 Tutorial: Databricks Genie for Data Engineers and Data Scientists 💻 GitHub: databricks/tmm/DSDE-Genie-Tutorial 🛫 Dataset: OpenSky Network full-day dataset on Marketplace What's the first thing you'd query in a day of global air traffic? P.S. For the record, we still love bakehouse! 🍪❤️ [Disclaimer: I'm one of the two people who baked it.] submitted by /u/CompetitiveBet8978 [link] [comments]

Databricks Micro Apps, App Spaces and Genie App Generator

Databricks launched App Spaces and Serverless Micro Apps at the end of last week (in Beta). Over the weekend, I tested migrating two of my production Databricks Apps to App Spaces. App Migration 1: Blocked by Zero Egress My Data Portfolio Project Creator required internet access to pull data stacks from live job postings. Then, the LLM needs internet access to research for open data sources to use. In standard Databricks Apps, this runs cleanly. In App Spaces, there is zero external internet egress including for LLMs. The app can reach internal workspace resources, but it cannot touch the outside web. If your app relies on third-party APIs, external databases, or web scraping, App Spaces is a non-starter until Databricks opens network egress. Workload 2: Success on Internal FinOps My client-facing DBU cost observability app reads workspace usage data and writes directly to Lakebase. Because it requires zero external network calls, the migration worked. Both the micro app compute and Lakebase scale to zero when idle. Cold starts take roughly 30 seconds (though in beta, you occasionally need a quick browser refresh once it spins up). For internal, low-frequency administrative tools, this turns a continuous monthly compute bill into pennies. (+ App Spaces, Genie App Generator, and Micro Apps are free while in beta) The next part is less about App Spaces and more just general best practice for Databricks Apps that I see people miss. Stop Using Delta Lake as an OLTP Database Databricks Apps are software applications, not batch analytics notebooks. If your app writes application state, session data, or row-level CRUD directly into analytical Delta tables, you need to rethink that design. For app transactions, use Lakebase (serverless Postgres which also scales to 0). Both are governed under UC, but Lakebase gives your app the low-latency transactional engine that application engineering actually requires. My Verdict on the Beta App Spaces solves the idle compute problem that has plagued Databricks Apps since launch. But until Databricks allows us to deploy directly from existing Git repos and opens external network egress, it remains limited to internal-only use cases. Curious on other peoples experience... How has it been for others? submitted by /u/OkImprovement7010 [link] [comments]

Lakebase handles failover within a region, but cross-region disaster recovery is still in Private Preview. How are people covering that?

I was reading through Databricks' breakdown of what Lakebase takes over on the ops side. Patching, scaling, in-region failover, and point-in-time restore with 2 to 30 days of history all run automatically, while cross-region disaster recovery is Private Preview on AWS only, with manual failover and recovery procedures the customer owns. For anyone running Lakebase behind an app or for agent state, how are you handling a region outage today? I can see people copying scheduled snapshots elsewhere, replicating out to a Postgres instance outside Databricks, or accepting the risk until DR goes GA, and I'm curious which one teams have landed on. I'd also like to hear whether the built-in PgBouncer has held up under spikes in connections from Databricks Apps, since that's the other thing I'd want to test before putting a production workload on it. submitted by /u/InsideDebt6345 [link] [comments]

Reliable approach for scaling Databricks Apps down and starting them on demand

Both Databricks Apps Returning 502 Bad Gateway

Build with Replit Against Managed Postgres in Databricks Apps

Dark mode setting ignored when embedding BI dashboard inside Databricks App

Databricks Apps - Deployment process - Need help !!

Did anyone get an hands on Databricks apps

Hoping a discussion and insights from an individual who had an hands on databricks apps submitted by /u/BugSquare4344 [link] [comments]

Databricks Apps / AppKit

Hi, what do u use for creating user facing apps, we are primary using Python, i see that Databricks recommends AppKit for such use cases which is written in TS. For teams which deploys apps that are customer facing, what is your stack? submitted by /u/ptab0211 [link] [comments]

Open Sharing protocol of Databricks Apps and SaaS sharing

I want to understand the open sharing protocol, how it is sharing the apps, what artefact is shared when app is shared, is it sharing the app files from Workspace path directly? Secondly, how the SaaS is shared and what artefact is shared and how? Could not find documentation. Thanks

Databricks Apps - "App Not Available" error with locationId parameter missing

Databricks Apps (Streamlit) - How to Implement Proper Logout Functionality?

Databricks Marketplace: IP Protection, Job Compute, and Secret Management

I am planning to publish an application through Databricks Marketplace. The application contains proprietary business logic and processing algorithms that must not be accessible to customers after installation. Customers should be able to use the application to process data in their own Databricks environment, but they should not be able to inspect, copy, or reuse the underlying implementation. Approaches I Have Tried I have considered the following approaches: Packaging the implementation as Python wheels or other artifacts. Hosting the implementation as private Python packages. Deploying the application source from a private Git repository. With the packaging approach, the underlying Python implementation may still be accessible or inspectable from notebooks, workspace files, cluster environments, package caches, or other customer-accessible locations. This does not meet my IP-protection requirements. With private package hosting, the package installation requires an access token or API key. Providing a reusable package-registry credential to an application running in the customer's workspace creates a risk that the credential could be extracted or reused to download the private package outside the intended application flow. I also understand that Databricks Marketplace reviewers may require the submitted application code to be human-readable during the review process. Therefore, I am looking for an architecture that protects the production implementation without relying only on code obfuscation. Current Understanding My understanding is that a Databricks App runs in an isolated, containerized runtime. This provides separation between the application runtime and normal customer workspace resources. However, my workload includes processing large datasets. I understand that Databricks App compute is primarily intended to run the application, API, or user interface, rather than perform large-scale Spark processing. Because of this, I am unsure whether Databricks App […truncated]