Everyone starts somewhere. Whether you’re writing your very first line of code or you’ve been building for years and never fully learned the tools underneath, this guide is your on-ramp.

This is the entire GitHub for Beginners series distilled into one holistic story—a detailed path that takes you from “what even is a repository?” all the way to collaborating on real projects and contributing to open source.

Read it top to bottom, and you’ll have a complete model of how modern software gets built on GitHub. Jump to any section, and you’ll find a self-contained answer. Let’s dive in.

Part 1: Get your bearings

1. What is version control (and why does it matter)?

Version control is a system that tracks changes to your files over time, and Git is the most widely used version control system in the world.

If you’ve ever saved brand_guide_v2, brand_guide_final, and brand_guide_FINAL_actually, you’ve already felt the problem that version control solves. Git records every change you make, so you can see what changed, when, and why. If you need to go back to an earlier version, it can handle that, too. You never need a folder full of “final” files again.

Git works through three zones: your working directory (where you edit), the staging area (where you review what’s ready), and the local repository (where your saved history lives). Three commands move work between them (i.e., git status, git add, and git commit) and you’ll use them so often they become muscle memory.

Read more: What is Git? Our beginner’s guide to version control

💡 Tip: When someone says “push your code,” they mean you should use Git to upload your local commits to GitHub.

2. How do I set up and secure my GitHub account?

Your GitHub account is your developer identity. You should make sure it’s well protected.

Turning on two-factor authentication (2FA) adds a second layer of protection that keeps your account safe even if your password is stolen. Passwords alone are vulnerable to phishing and reuse, so enable 2FA from Settings → Password and authentication.

While you’re here, give yourself a profile README. This is a living portfolio of your skills, projects, and interests. Create a public repository with the same name as your username, add a README, and whatever you write shows up on your profile page.

Read more: Beginner’s guide to GitHub: Setting up and securing your profile

💡 Tip: Download your recovery codes and store them in a password manager. They’re your only way back in if you lose your device.

3. Which Git commands do I actually need?

A small set of Git commands covers the daily workflow of nearly every developer.

The commands you want to become familiar with are .config, init, clone, add, commit, push, pull, branch, and switch.

You don’t need to memorize all of Git. Here are the ones you can use to get started:

Command	What it does
git config –global user.name “…”	Set the name attached to your commits
git init	Turn the current folder into a Git repository
git clone <url>	Make a local copy of a remote repository
git status	See what’s changed in your local environment and what’s staged
git add .	Stage all your changes for the next commit
git commit -m “message”	Save a snapshot of your staged changes
git switch -c <branch>	Create a new branch and switch to it
git push	Upload your local commits to GitHub
git pull	Download and merge the latest changes from GitHub
git merge <branch>	Integrate another branch into your current one

Read more: Top 12 Git commands every developer must know

Part 2: Build your first project

4. How do I create my first repository?

A repository (or “repo”) is a project folder that tracks changes, stores history, and lets multiple people seamlessly work together.

This is your project’s home base. Start from your dashboard, the page you land on when you sign in to github.com, which shows your repositories and activity feed.

• Click the green New button
• Give your repo a name
• Choose public or private
• Check the box to add a README. This is the first thing visitors see and should act as the front door to your project.

That’s it! You have a repository. You can optionally add a .gitignore to keep junk files out of version control and a license to tell others what they’re allowed to do with your code.

What’s a .gitignore for? As you work, your project folder fills up with files you never actually wrote. These are things your computer or tools automatically create (e.g. system files, folders of downloaded dependencies, temporary build output). You don’t want to track or share those, so a .gitignore file lists them and tells Git to leave them alone. It keeps your repository clean and focused on the code that actually matters.

Read more: Beginner’s guide to GitHub repositories: How to create your first repo

5. What is Markdown and how do I use it?

Markdown is a lightweight language for formatting plain text. It’s how you write READMEs, issues, pull requests, and comments across GitHub.

Markdown turns simple symbols into clean formatting. A few keystrokes give you documentation that’s a pleasure to read, which can make all the difference. You can use Markdown syntax, along with some HTML tags, to format your writing on GitHub.

Read more: GitHub for Beginners: Getting started with Markdown

6. What is the GitHub flow?

The GitHub flow is the repeatable loop for safely adding work to a shared progress: branch, commit, push, open a pull request, merge.

Here’s the rhythm you’ll keep on repeating:

1. Clone the repo to your machine
2. Create a branch for your work
3. Make changes
4. Commit them
5. Push them to GitHub
6. Open a pull request.

You can collaborate on anything you store in a repository. For example, imagine your team keeps its reusable AI prompts in a shared repo. You rework the prompt to improve the output. You make that change on a branch, open a pull request, and a colleague checks the new output before it’s approved. Once it’s merged, the next teammate who refreshes the repo is automatically writing from the improved prompt. There’s no need to send out an announcement to use the new prompt and no attachment drifting around inboxes. It’s the same branch-review-merge loop developers use, applied to words instead of code.

Read more: Beginner’s guide to GitHub: Adding code to your repository

💡 Tip: Give branches descriptive names like fix-login-bug or add-dark-mode so everyone knows what they’re for at a glance.

Part 3: Collaborate with other people

7. What is a pull request?

A pull request is a proposal to merge a set of changes from one branch into another, with a built-in space for teammates to review and discuss.

A pull request is where collaboration happens. It shows a visual diff of exactly what you changed and gives reviewers a place to comment . Write a clear title and description, link any related issues, and review your own pull request first to catch obvious mistakes.

💡 Tip: Smaller pull requests are easier and faster to review and merge, provide less room to introduce bugs, and provide a clearer history of changes.

Read more: Beginner’s guide to GitHub: Creating a pull request

8. How do I merge a pull request and fix a merge conflict?

Merging integrates reviewed changes into your target branch. A merge conflict is simply Git asking for your help when two changes touch the same lines of code and it doesn’t know how to integrate both changes at the same time.

Most merges are one green button: click Merge pull request, confirm, done. 🎉 Sometimes two branches edit the same lines of a file and Git can’t decide which version wins. In this case, GitHub marks the conflicting sections. You use the browser editor or VS Code to choose what to keep, mark it resolved, and merge. With a little practice, it feels as natural as any other push.

Read more: Beginner’s guide to GitHub: Merging a pull request

9. What are GitHub Issues and Projects?

Issues track individual tasks, bugs, and ideas, while projects organize those issues into a visual board so nothing slips through the cracks.

Issues are shared, trackable notes. Each one is a task, bug, or idea you can assign, label, and discuss. Projects pull those issues onto a Kanban-style board so you can see the status of all the issues at a glance. Here’s a small piece of magic that ties it all together. Every issue gets its own number. You’ll see it after the title as a hashtag and then a number (e.g., Let’s call a sample issue The answer to everything #42). When you open a pull request to fix that issue, you can type a closing keyword into the pull request description (e.g., Closes #42, Fixes #42, or Resolves #42).

GitHub recognizes that phrase as a link between the two: the pull request and the issue now reference each other. Then, the moment that pull request is merged, GitHub automatically marks issue #42 as closed for you. If the issue is on a project board, it slides over to the “Done” column on its own. It’s a simple habit that keeps your code changes and your task tracking in sync without any extra effort.

Read more: GitHub for Beginners: Getting started with GitHub Issues and Projects

Part 4: Level up your projects

10. What is GitHub Actions?

GitHub Actions is a CI/CD and automation platform built into GitHub that automatically runs tasks (e.g., tests, deployments, labeling) when events happen in your repo.

Once your project is moving, use GitHub Actions to let GitHub do the repetitive work. Write a workflow as a YAML file in .github/workflows/, tell it what event should trigger it, and define the steps to run. From then on, GitHub follows those steps on its own.

Read more: GitHub for Beginners: Getting started with GitHub Actions

11. How do I publish a website for free?

Got a portfolio, a project page, or documentation? GitHub Pages can host it for free at username.github.io/repo-name with no servers to manage. Enable it from Settings → Pages, choose to deploy from a branch, and you’re live in minutes. Even private repositories can publish a public site. This is great for showcasing work with code you’d rather keep to yourself.

Read more: GitHub for Beginners: Getting started with GitHub Pages

💡 Tip: Use Pages to promote your projects, share what you’re building, and grow your portfolio.

12. How do I secure my code on GitHub?

Security isn’t a final step; it’s a habit. GitHub Advanced Security is a built-in suite that automatically finds and helps you fix vulnerabilities. It includes secret scanning, Dependabot, and CodeQL code scanning, and it’s free for public repositories.

Secret scanning catches API keys you accidentally commit. Dependabot watches your dependencies for known vulnerabilities and opens pull requests to update them. CodeQL analyzes how data flows through your code to spot risky patterns and explains how to fix what it finds. Turn it all on from your repository settings.

Read more: GitHub for Beginners: Getting started with GitHub security

💡 Tip: You inherit any risk from a library the moment you import it into your project, even though you didn’t write the vulnerable code yourself.

13. How do I contribute to open source?

Open source software has freely available code that anyone can study and improve, and GitHub is its home.

How do you find the perfect project to contribute to? First, look for projects with a clear README, a CONTRIBUTING.md, an open source license, and issues tagged good first issue. That label is maintainers’ way of waving beginners in.

Contributing to real projects is one of the fastest ways to grow, and a fork makes it safe to do so. A fork is your own personal copy of someone else’s repository where you can experiment freely, then propose your changes back with a pull request.

So how is a fork different from a branch? A branch is a parallel workspace inside a repository you already have permission to change. A fork copies an entire repository into your account, which is what you need when you don’t have permission to edit the original (like most open source projects). A common workflow combines both: you fork the project, create a branch in your fork for your changes, and then open a pull request back to the original.

Read more: GitHub for Beginners: Getting started with open source contributions

The post GitHub for Beginners: Your roadmap to mastering the GitHub essentials appeared first on The GitHub Blog.

Autonomous agents are moving faster than the field’s ability to govern them, and catching up requires more than better prompts or bigger sandboxes. At O’Reilly’s recent AI Superstream focused on OpenClaw and the broader ecosystem of locally run and self-hosted AI agents, five speakers, each working at a different layer of the stack, explored patterns for addressing many of the challenges developers will face implementing an agentic system, from risky third-party extensions, hallucinated compliance, and spaghetti codebases only an AI can read to cost overruns from misconfigured models, supply chain attacks, and worse.

As host Alistair Croll noted during the event, we can get better and better with nondeterministic technology, but we’ll never be 100% certain it’s working. The harder it gets to inspect what’s running, the more the governance layer matters. That work is unglamorous, mostly invisible to end users, and probably more important than any model capability improvement shipping this quarter.

Secure the action your agent takes at the execution layer

Eran Sandler, founder of Canyon Road and the team behind AgentSH, opened his talk by running through a list of common ways agents can be compromised, including prompt injection, malicious files, unsafe tools, compromised packages, installed skills, and model mistakes. Most AI security thinking focuses on the first one and ignores the other five, but “guarding the input box does not guard the action,” Eran explained.

His advice is enforcement at the execution layer, the boundary between the agent’s intent and the operating system that carries it out. Container isolation limits blast radius, Eran acknowledged, but it doesn’t make decisions. “Walls keep things in. They don’t make judgment calls.”

To illustrate the point, he installed a simulated malicious package, the kind that could arrive bundled with a routine task like “build me a sales prediction model.” Then he queried AgentSH’s deny log and pulled up a list of what actually happened while the agent was busy congratulating itself, including an attempted skill mutation, a blocked call to an external domain, and reads of .env secrets and SSH keys. “Transcripts might lie,” he says. “Models hallucinate compliance all the time. You can tell them in your rules files, please don’t touch this file, and they’ll still do it.” Without execution-layer controls, Eran said, “you’re hoping the model behaves. With it, you can prove what happened.”

Skills are a supply chain risk, and most people aren’t reading them

A recent audit of ClawHub found over 900 malicious skills, which at the time meant nearly 20% of total packages were risky. Most of these skills look professional, with documentation, high download counts, and user ratings. Kesha Williams, Keysoft founder and head of AI, audited one live—a typosquat of the real ClawHub CLI tool. (It used all lowercase where the legitimate package uses camel case.) The skill had more than 8,000 downloads before it was removed.

Here’s how it worked. The prerequisites section asked users to install a fake dependency called open-claw-core and then referenced a password-protected zip file from GitHub (the password was “openclaw”) specifically to bypass automated scanning. For macOS, it echoed a legitimate-looking install command that actually decoded a base64 string and piped it to bash.

“It looks like a skill you could actually need and use,” Kesha pointed out. “But once you really dig in and read what it’s actually doing, that is not a skill you want to install on your system.”

A good defense starts with two things most users skip: reading the skill Markdown file before installing it and configuring the toolsDeny section of the OpenClaw config to limit a skill’s access. If a summarizer skill needs exec, that’s suspicious, Kesha said. Block it. She also showed how to restrict the 50-plus bundled skills that ship with OpenClaw, most of which users haven’t reviewed. The skillsAllowed configuration lets you determine exactly which bundled skills stay active.

The open source software supply chain has always had trust problems, but the friction of traditional package management meant you at least needed technical knowledge to participate. Skills written in Markdown and installed with a single command lower that bar significantly. “Right now,” Kesha explained, the best policy for anyone extending their agent with third-party tools is to “keep a human in the loop and do your own due diligence.”

Operational hygiene failures are more common than adversarial attacks

Most OpenClaw risk is the result of operational hygiene failures that happen in the first hour after installation, argues Erik Hanchett, a developer advocate at AWS and the creator of the Program with Erik channel. There are thousands of OpenClaw instances currently exposed on the public internet because users didn’t check the gateway bind mode after setup. As Erik demonstrated, the default should be loopback (localhost), but a user who deploys on a VPS and sets the gateway to LAN may inadvertently expose their instance. The fix takes two minutes, but most people never do it.

That’s recommendation one on Erik’s five-point checklist. The others include pinning to a stable version rather than always updating to the latest (a crowdsourced stability tracker at Is It Stable? can help), configuring fallback models to avoid burning through expensive frontier tokens on routine tasks, writing a real SOUL.md rather than rushing through the onboarding prompts, and setting up backup of workspace files to a private GitHub repo before anything breaks. He also shared tips on context management, such as using /new to start fresh sessions rather than accumulating one long conversation, and using /compact when sessions grow large enough to affect performance, are the kind of operational detail that doesn’t appear in documentation but matters in daily use.

The Docker and Kubernetes eras produced the same pattern: powerful infrastructure technology deployed by enthusiastic early adopters who hadn’t always thought through the operational defaults. The problems Erik described—exposed dashboards, runaway token costs, and memory that resets unexpectedly—are the most common reasons people abandon agentic tools after a few weeks. The good news is they’re eminently fixable with the right guidance.

In regulated environments, plausibility isn’t accuracy

Ari Joury, CEO of Wangari Global, is working to solve the question that most enterprises experimenting with agents are probably asking themselves: How should we handle autonomous agents that operate in environments where being wrong has legal consequences?

Wangari Global builds financial reporting automation for institutional clients. However, LLMs are optimized for plausibility, not accuracy. In financial services, that gap is a compliance risk. Ari gave an example of AI output that sounded correct. . .until a client read it and “told [the company] it was complete nonsense.”

In response, Ari and his team stopped treating the AI as a magic box and engineered a framework to ensure veracity. Numbers are now calculated with hard-coded deterministic code, then agents verify the math for plausibility. A separate agentic layer generates commentary, and another critiques it. Humans approve or reject the output, and every rejection becomes a training signal for future iterations.

Human input is the only thing that prevents AI slop at scale

Kyle Balmer closed things out with a demonstration of his agent-assisted process for content production for his AI with Kyle channel, addressing the economic incentive structure driving agent adoption outside software development. While he’s found autonomous agents to be economically transformative, the system only works if you design human input and review into it deliberately, which Kyle illustrated in a workflow that distinguished between automated and human processes.

His daily workflow converts a one-hour livestream into 20 to 30 derivative assets, including a newsletter, five to eight short-form videos, carousels, and a long-form YouTube video. The whole system runs on roughly $200 a month, and Kyle estimates that translates to roughly $1,000–$2,000 worth of potential customers entering his funnel daily.

The process is not fully automated: Kyle injects himself into the process at various steps throughout. He chooses the topic. He records voice notes with his actual opinions. He delivers the livestream pulling those thoughts together into clear arguments. He rewrites the AI-generated newsletter draft using his own voice. He records the short-form video scripts himself rather than using an AI avatar. The AI handles research, briefing, slide generation, script drafting, and the feedback loop that improves output over time, but the human provides the signal.

“I have tested with fully automated AI content,” he says. “It does not work. It is slop. And people know it’s slop.”

We’re updating TypeScript version support in the AWS SDK for JavaScript v3. Starting January 4, 2027, the SDK will require TypeScript versions published within the last 2.5 years. Read on to learn what’s changing, why this change is necessary, and what actions you may need to take.

We built the AWS SDK for JavaScript with TypeScript-first development in mind, designed to deliver smaller artifacts while taking advantage of modern TypeScript features. This support policy update also aligns the SDK with the broader TypeScript ecosystem.

What’s changing and why

This change applies only if you use TypeScript with the AWS SDK for JavaScript v3.

The TypeScript ecosystem has broadly converged on supporting only recent compiler versions:

• DefinitelyTyped, the central repository for community-maintained TypeScript type definitions (hosting types for 8,000+ npm packages including @types/node and @types/react), only tests packages against TypeScript versions less than 2 years old. For more information, see Support Window on GitHub.
• typescript-eslint, the most widely used TypeScript linting framework, mirrors the DefinitelyTyped support window and only supports TypeScript versions less than 2 years old.

Real-world applications depend on many packages beyond the SDK. Once the broader ecosystem drops an older version, you’re likely to encounter incompatible typings regardless.

We are aligning with this ecosystem norm. The SDK will follow the DefinitelyTyped support window plus a 6-month grace period, giving you up to a 2.5-year window to upgrade your TypeScript version. For more information, see AWS SDKs and Tools maintenance policy.

The following table shows the end-of-support timeline for each TypeScript version:

TypeScript version	Release Date	DefinitelyTyped end-of-support	JS SDK end-of-support
<=5.5	June 20, 2024	June 20, 2026*	January 4, 2027
5.6	September 24, 2024	September 24, 2026*	March 31, 2027
5.7	November 22, 2024	November 22, 2026*	May 31, 2027
5.8	March 5, 2025	March 5, 2027*	September 30, 2027
5.9	August 1, 2025	August 1, 2027	February 29, 2028

* Speculative, based on the DefinitelyTyped support window. 

What you can expect

A clear minimum supported TypeScript version

We will document a minimum TypeScript version in the GitHub repository’s README and will keep it updated as part of the normal maintenance process. We define “supported” as:

• We build and test the SDK against TypeScript versions within the support window.
• We may not address issues specific to out-of-window TypeScript versions.

Smaller package artifacts and simpler publishing

This change reduces build and release complexity, published package size, and AWS Lambda artifact size.

What you need to do

You don’t need to take immediate action. If your project uses a TypeScript version within the support window, no changes are needed. For projects on an older TypeScript version, your existing setup will continue to work as long as you don’t update the SDK version. However, we recommend that you upgrade your TypeScript version to continue receiving the latest SDK updates.

You have two options for staying compatible with the SDK:

Option 1: Upgrade TypeScript to a supported version (recommended)

• Upgrade TypeScript in your dev dependencies.
• Run your project’s type check to validate your code against the new TypeScript version.
• Address any new diagnostics.

Tip: Newer compilers often catch issues that older versions missed, so new diagnostics might reveal real bugs in your code.

Option 2: Pin the AWS SDK for JavaScript v3 packages

Pin @aws-sdk/* dependencies to the last version that supported your TypeScript version. This prevents short-term disruption, but you won’t receive newer SDK updates, security patches, or new features.

FAQ

Is this a runtime breaking change?

No. This change affects type-level compatibility (your build) and the SDK’s ability to ship types efficiently. This can cause build failures with older (unsupported) TypeScript compilers.

Why not keep downleveling indefinitely?

Downleveling hasn’t been required since TypeScript 4.7, which was published in May 2022. Down-leveling makes every release heavier:

• Downlevel types account for 18% of the published package size in the SDK.
• Downleveling is an additional step in the SDK’s release process.

Conclusion

We recommend upgrading to a supported TypeScript version ahead of this change to keep receiving updates, security patches, and new features. For the current minimum supported version, see AWS SDK for JavaScript v3 README on GitHub.

We’d love to hear from you. Open a discussion or issue on our GitHub.

Microsoft Azure Databricks delivers the first-party advantage of Databricks on Microsoft—and for customers, that advantage shows up as real, measurable value. It is the same Databricks platform your teams already know, co-engineered with Microsoft and delivered as a native Azure service, so it fits naturally into the Microsoft tools, identity, and governance your organization already runs.

The advantage is built-in, not bolted on. Microsoft and Databricks co-engineer the service, share one integration roadmap across the Microsoft data and AI stack, and align go-to-market so you get one motion, one bill, and one support path. For technical teams, that means deeper native integration and stronger performance. For the business, it means lower cost, less risk, and faster time to value.

The strategic partnership drives an accelerated integration roadmap and continuous optimization for improved performance; however, decision-makers constantly ask about what business value all of this translates to. To address this key question, Microsoft commissioned a Forrester Total Economic Impact™ study of Azure Databricks. It found that a composite organization based on interviewed customers realized a three-year 331% return on investment, $58.1 million in net present value, and recovered its investment in less than six months.

Commissioned study conducted by Forrester Consulting on behalf of Microsoft, June 2026. Results are over three years and represent a composite organization based on interviewed customers and may not be typical; actual results will vary.

What the study found

Forrester interviewed Azure Databricks customers and built a composite organization to model the impact: a $6 billion company in a regulated industry, running about 10 petabytes of data.

Before Azure Databricks, its data estate was fragmented and expensive. It was unreliable at scale and hard to govern. Afterward, the results were clear: $75.6 million in benefits against $17.5 million in cost over three years translating to $58.1 million in net present value.

The value came from four places:

• $39.0 million—data and analytics teams’ productivity. Teams handled more work without adding people, with measured gains of 15% to 25%. As a Vice President of data services at a healthcare organization put it: “…we’re doing more work with the same size of the team.”
• $19.9 million—lower infrastructure costs. Elastic, pay-as-you-go compute replaced overprovisioned hardware.
• $11.4 million—better data platform resiliency. Managed operations meant fewer outages and no custom disaster recovery to build.
• $5.4 million—retired legacy software and redeployed DBAs. Consolidating databases and Extract, Load, Transform (ETL) tools eliminated third-party licenses, and managed operations freed database administrators for higher-value work.

Forrester listed more benefits it didn’t put a price on: native Azure services integration, faster insights, wider access to data, and governance through Unity Catalog. That’s where the return starts.

Where the value comes from

Those returns come down to one thing. Azure Databricks is a true first-party Azure service, co-engineered by Microsoft and Databricks, it plugs into the tools your teams already use. That removes the extra data copies, tooling, and integration work that raise costs elsewhere.

A great example is the Azure Databricks Genie integration with Microsoft Copilot Cowork. You can add context of your business and build on that intelligence into the tools your teams already use with this integration. Genie lets anyone question the lakehouse in plain language—now inside Microsoft Teams, Microsoft 365 Copilot, and more recently in Copilot Cowork, where it grounds tasks in trusted data through Genie Ontology. Every answer is scoped by Unity Catalog to exactly what each user is permitted to see, so intelligence reaches the flow of work without loosening governance.

The same depth runs across the rest of the platform:

• Identity and governance: Automatic Identity Management for Entra ID syncs users into Azure Databricks. Unity Catalog and Microsoft Purview govern the rest. 
• Microsoft Power BI and Microsoft 365: Power BI reads your data directly and now writes back to it. A new Excel add-in brings governed data into spreadsheets; a SharePoint connector streams files into Delta tables, and Teams notifications deliver alerts where teams work. Metric views keep business logic consistent across all of them. 
• AI and agents: Beyond chatting with your data, Genie connects to Copilot Studio and Microsoft Foundry, and a single Model Context Protocol (MCP) connection lets Copilot Studio and GitHub Copilot agents reason over an entire Azure Databricks workspace. Azure Database Lakebase gives agents a serverless Postgres engine, and serverless workspaces get them started fast. 
• Microsoft OneLake: OneLake catalog federation lets Azure Databricks query OneLake data directly, with no pipelines or copies. You can also store Unity Catalog tables in OneLake, alongside Azure Data Lake Storage.
• Customer data: CustomerLake, a new Agentic Customer Data platform, builds Customer 360 profiles and runs campaigns inside the lakehouse where the data and governance already live. 
• Enterprise systems: SAP Business Data Cloud Connect brings SAP data into the lakehouse. It’s the same model helping industries like industries like telecom turn AI into returns. 

These are the integrations that Forrester valued but didn’t price separately however, they are critical factors driving productivity and cost benefits that were quantified.

Backed by independent benchmarks

Value also depends on speed, and that’s been tested. Principled Technologies, an independent firm, ran an industry-standard, TPC-DS-like decision-support benchmark on a 10-terabyte dataset. Azure Databricks completed a single query stream in up to 21.1% less time than Databricks on AWS (with autoscale disabled) and ran four concurrent query streams more than nine minutes faster.

What it means for you

Choosing a data and AI platform is a long-term decision, and with Azure Databricks the pieces reinforce each other. The integration drives the savings Forrester measured. The performance keeps those gains steady as usage grows. And it all rests on one foundation: a first-party partnership that puts Microsoft and Databricks engineering, roadmap, and support behind your data estate. The value isn’t a claim, it’s been measured: a three-year 331% return, with payback in under six months. It’s why so many teams choose to run their lakehouse on Azure Databricks.

Explore further

• The full Forrester TEI study, plus the ROI calculator to model your own numbers.
• The Principled Technologies benchmark.
• Azure Databricks at Data + AI Summit 2026, and how it uses OneLake as a shared data foundation.
• Build AI apps and agents with Azure Databricks, Copilot Studio, and GitHub Copilot.
• Stay current on the Azure Databricks Tech Community blog and the official release notes.
• Related blog posts: Differentiated synergy and Databricks runs best on Azure.
• For the full set of Databricks Data + AI Summit 2026 announcements, see Azure Databricks at Data + AI Summit 2026.
• Learn more about Azure Databricks

The post Azure Databricks delivers proven business value appeared first on Microsoft Azure Blog.