A lot of New Zealand organisations already have Databricks. Fewer are getting full value from it. Not because the platform falls short, but because implementation is where that value actually gets built, and that work is often incomplete.
The case for a unified lakehouse is a good one. One platform for data engineering, analytics, and AI, instead of three systems patched together with brittle integration work. That’s why so many New Zealand organisations have already bought into Databricks.
The platform delivers on that promise. What tends to lag behind is the build itself, and that’s not a knock on anyone. Getting the governance model right, designing pipelines properly, having a team who actually knows the platform inside out. All of that takes work, and in New Zealand right now, Databricks expertise is genuinely hard to find, and most organisations are trying to figure it out on their own.
The lakehouse isn’t the hard part
Under the hood, Unity Catalog managed tables give an organisation reliable, governed storage for structured and unstructured data, built on either Delta Lake or Apache Iceberg. That choice of open formats matters more than it sounds. It means data isn’t locked into one vendor’s proprietary format, and it means analytics, reporting, and AI can all draw from the same trustworthy source instead of three different, half-matching copies.
That foundation is solid from day one. The part that determines whether it’s actually paying off is what gets built on top of it. Lakeflow handles the whole journey from source system to something usable: managed connectors so engineers aren’t hand-coding extracts, pipelines that check data quality automatically, and job scheduling that actually tells you what’s happening rather than leaving you guessing. There’s even a version, Lakeflow Designer, that lets analysts build their own pipelines without waiting on an engineering queue. Whether an organisation is genuinely using all this, or still routing data through the same clunky, multi-step process it had before Databricks arrived, comes down to how well it was set up in the first place.
Governance is where the platform either scales or stalls
Unity Catalog is Databricks’ governance layer, and it’s worth understanding why it matters so much. It handles who can access what, where data actually came from, and keeps a single catalogue of everything across the platform. For an organisation with more than one team touching the data, this is the difference between a setup that scales cleanly as it grows and one that slowly turns into a mess of who-has-access-to-what nobody wants to untangle.
Get this right early, and access is controlled by design rather than by a policy document everyone forgets to check. It also means everyone’s working from the same truth. A number on a dashboard, an answer from Genie, and a response from an AI agent all trace back to the same governed definition, rather than three tools quietly disagreeing with each other.
Genie is where this starts to feel less like infrastructure and more like something people actually use
This is the part of Databricks that tends to land best with the people who aren’t in the data team. Genie lets anyone ask a question about the business in plain English, “which region grew fastest last quarter,” “why did signups drop in August,” and get a real answer, built from an actual query against the organisation’s own data, not a guess.
It’s not an open-ended chatbot loosely connected to a spreadsheet. Genie works from Genie Spaces, which are set up with verified metric definitions and proper guardrails for a specific part of the business, so the answer someone gets is trustworthy rather than plausible-sounding. Uptake has been fast. Over 1.5 million Genie Spaces were created across Databricks customers in 2026 alone. For a business user, that’s the difference between waiting on a report and just asking.
AI adoption depends on the same foundation
Agent Bricks is the practical starting point for most organisations building on Databricks. It builds agents grounded in an organisation’s own governed data, with evaluation built in, so quality gets measured rather than assumed. Underneath, Model Serving handles deployment for agents, generative AI, and traditional machine learning from the same workspace, and MLflow keeps track of everything, experiments, model versions, monitoring, so a promising pilot doesn’t fall apart in production.
Where AI needs to power something a customer actually uses, not just a dashboard, Lakebase gives agents fast, reliable access to governed data, and Databricks Apps turns that into something a user can genuinely click on. None of this steps around governance either. The Unity AI Gateway applies the same access controls to AI itself, spend limits, model routing, full tracing, which is usually the question that comes up about six weeks after the first AI pilot works, when someone asks who’s actually allowed to use it, and what it’s costing.
The question isn’t whether Databricks can do this
It’s whether the implementation behind it is built to get everything the platform is actually capable of.
Mero is a Databricks partner with delivery experience across Google Cloud, AWS and Azure. That matters because Databricks runs on all three, and how well it performs depends as much on the cloud environment underneath as the platform itself. We work with organisations to close the distance between what Databricks can do and what it’s currently doing, and rather than waiting on a hiring market that isn’t making it easy, we bring in a team that’s ready to start.
If you have Databricks and would like to see what’s possible for your environment, get in touch.