BigQuery Security center and OBJ.LIST are now generally available

The 30 September 2026 BigQuery release notes carry four changes. The BigQuery Security center is generally available in the Google Cloud console, the jobs explorer's layout and filtering improvements are generally available, the OBJ.LIST function is generally available, and query plans now show UPDATE, DELETE, MERGE and EXPORT execution steps. They touch governance, day-to-day operations, unstructured data and DML tuning, and all four are additions to the console and SQL surface, so the work is adopting them rather than migrating anything.

Key takeaways

• The BigQuery Security center is GA in the Google Cloud console. It brings your data security profile, row- and column-level security policies, and policy tags into one place.
• The jobs explorer's layout and filtering improvements are GA: status counts in the filter bar, resource grouping, and timeline metric charts.
• OBJ.LIST is GA. It returns metadata and ObjectRef values for Cloud Storage files without a persistent object table.
• Query plans now show the UPDATE, DELETE, MERGE and EXPORT execution steps.
• Do a read-only security review and a small OBJ.LIST trial first. Bring in a partner for governance redesign or unstructured data pipelines, not for console tours.

What did Google release on 30 September 2026?

Four items, listed in the notes as features. Three of them are explicitly marked generally available: the Security center, the jobs explorer improvements and OBJ.LIST. The fourth, execution steps for UPDATE, DELETE, MERGE and EXPORT in query plans, is described as something you can now view, and the notes don't attach a maturity label to it. Treat it as available and check the documentation for any limits.

The pieces don't depend on each other, and you don't have to adopt them together. A governance lead cares about the first. A platform or FinOps owner cares about the second and fourth. A data engineer working with documents, images or other files in Cloud Storage cares about the third.

The table below gives the short version, then the sections that follow go through each change in turn.

Change	Status in the notes	Who it mostly affects	First action
BigQuery Security center	GA	Data governance, security and compliance owners	Open it and review your data security profile
Jobs explorer layout and filtering	GA	Platform admins, analytics engineers, on-call	Use status counts and resource grouping on a real incident
OBJ.LIST function	GA	Data engineers working with files in Cloud Storage	Run it on one bucket prefix
UPDATE, DELETE, MERGE, EXPORT steps in query plans	Available now	Anyone tuning DML or export jobs	Inspect the plan of your slowest DML job

What is the BigQuery Security center and who should open it first?

The Security center is a console area where you can analyze your data security profile, create and manage row- and column-level security policies, and configure and manage data governance and policy tags. Google lists it as generally available.

That covers three separate jobs, and it helps to keep them apart. Row-level security decides which rows a given user or group can see in a table. Column-level security, typically driven by policy tags, decides who can read sensitive columns such as an email address or a national ID. Governance and policy tags are the classification layer: the labels that say which columns are sensitive in the first place.

The people who should look first are the ones who answer questions about who can see what. If your marketing analytics warehouse holds customer identifiers alongside campaign data, that is probably you. A CRM export landing in BigQuery with hashed emails, phone numbers and consent flags is exactly the kind of table where column-level controls matter, and the Security center is now a supported place to review and manage them.

A sensible first pass looks like this:

1. Open the Security center in a project that holds customer data and read what it says about your data security profile.
2. List the tables you already know contain personal or commercial-sensitive columns.
3. Check whether each of those columns carries a policy tag, and whether the tag's access list matches who actually needs the data.
4. Check whether any table shared across business units needs row-level policies, for example regional teams that should only see their own markets.
5. Write down the gaps. Don't fix them in the same sitting.

That last step matters. A read-only review costs you an hour. Changing policies on live tables can break dashboards and scheduled queries that run under service accounts nobody remembers creating. Review first, then change in a controlled window.

The notes don't say anything about pricing, required roles or supported regions for the Security center, so don't assume. Look at the product documentation for the permissions needed before you ask a colleague to log in and discover they can't see anything.

What changed in the BigQuery jobs explorer?

The notes name three improvements: status counts in the filter bar, resource grouping, and timeline metric charts. Alongside them is a general layout improvement and better filtering. All of it is GA.

The jobs explorer is where you go when someone says the nightly load was slow or a dashboard query failed. Status counts in the filter bar let you see, at a glance, how many jobs sit in each state for the filters you've applied. Resource grouping lets you organise jobs by the resource they ran against. Timeline metric charts put job metrics against time so you can see when something shifted.

Here's a worked example. A reporting team notices that the morning refresh finished late three days running. Instead of opening jobs one by one, an admin filters to the relevant window, reads the status counts to see whether failures or long-running jobs dominate, groups by resource to see whether the trouble concentrates on one reservation or one project, and then looks at the timeline charts to find when the load changed. Whether each of those views answers the question depends on your setup, but the route from symptom to suspect is shorter than clicking through a list.

You don't need a project to adopt this. The test is simple: the next time something goes wrong with scheduled queries, use the new filters and grouping first, and note what you couldn't answer. Those gaps tell you whether you still need INFORMATION_SCHEMA queries or monitoring dashboards alongside it. Probably you do for alerting, because a console page is something you look at, not something that wakes you up.

How does OBJ.LIST change working with unstructured data?

OBJ.LIST returns a table of metadata and ObjectRef values for files stored in Cloud Storage, and it doesn't require you to create a persistent object table. The notes describe it as a way to discover and analyse unstructured data spontaneously, and it is GA.

The practical point is the word persistent. If you want to see what's in a bucket prefix, you can run the function and get rows back, one per file, with metadata and an ObjectRef you can carry forward. For exploratory work that matters: an analyst who wants to know how many PDFs, images or call recordings sit under a prefix, and how old they are, can ask the question directly.

Picture a team that stores campaign creative, scanned contracts or support call audio in Cloud Storage. They want to know what's there before deciding whether any of it is worth structuring. OBJ.LIST gives them a queryable listing for that first look. If the answer is that the files are worth processing regularly, that's a separate design decision about pipelines, access and cost, and the notes don't settle it for you.

A few cautions, none of which are in the notes and all of which you should confirm in Google's documentation:

• Check what access the function needs on the bucket. Listing files is still reading information about them, so treat the permissions as a governance question, not a convenience.
• Start with a narrow prefix, not a whole bucket holding millions of files.
• Don't build a production job on an ad hoc listing without deciding who owns it.

If your use case is occasional discovery, OBJ.LIST may be all you need. If you need a stable, governed, repeatedly queried view of files, the choice between ad hoc listing and a persistent structure is worth a short design conversation.

What do the new UPDATE, DELETE, MERGE and EXPORT plan steps give you?

You can now view the UPDATE, DELETE, MERGE and EXPORT execution steps in your query plans. A query plan is the breakdown of how BigQuery ran a job, stage by stage, and it's the first thing to read when a job is slower or costlier than you expected.

Who does this help? Teams that run DML as part of their pipelines. A MERGE that upserts yesterday's events into a customer table, a DELETE that honours erasure requests, an UPDATE that backfills a column, an EXPORT that ships results out to storage: each is a job whose plan you can now read with its own step visible. The notes don't describe what each step shows or how it's labelled, so open a recent job's execution details and see what appears.

A reasonable way to use it:

1. Pick the three slowest or most expensive DML or EXPORT jobs from the past month.
2. Open their execution details and find the new steps.
3. Compare where the time sits across stages. If the heavy stage is upstream of the write, the query feeding the statement is the problem. If it's the write itself, look at the statement's shape and the table it touches.
4. Record what you saw before changing anything, so you can tell later whether a change helped.

Don't expect the plan to hand you a fix. It's a diagnostic. It tells you where to look, and the remedy still comes from understanding your data and your table design.

How should you roll this out, and who owns each step?

None of these changes warrants a project plan. They do warrant an owner each, so that adoption doesn't turn into everybody's job and nobody's task. The table is a checklist you can paste into a ticket.

Step	Owner	Effort	Done when
Read-only review in the Security center	Governance or security lead	Hours	Gaps listed, no policy changed yet
Confirm required roles for Security center and OBJ.LIST in the documentation	Platform admin	An hour	Roles written into your access runbook
Use the jobs explorer filters and grouping on the next incident	On-call analytics engineer	During normal work	Notes on what the explorer answered and what it didn't
Trial OBJ.LIST on one narrow bucket prefix	Data engineer	A day at most	Output reviewed, decision made on ad hoc versus persistent
Inspect plans of the slowest DML and EXPORT jobs	Pipeline owner	A few hours	Baseline recorded for each job
Apply any policy changes found in the review	Governance lead with platform admin	Scheduled window	Dependent dashboards and service accounts tested

Test in a non-production project where you can. For policy changes especially, the safest order is to try on a copy of the table, run the queries and scheduled jobs that depend on it, and only then change the live one. A policy that hides a column from a service account will fail that account's queries, and nobody will tell you until the report is blank.

How do you know whether any of this paid off?

Pick one measure per change, and take the baseline now.

For the Security center, count sensitive columns without a policy tag and tables that need row-level controls but lack them. You're looking for that list to shrink. Don't measure it by how many policies you create, because more policies aren't better; correct ones are.

For the jobs explorer, track how long it takes to get from a reported symptom to a named cause. You don't need precision. Two or three incidents timed informally will show whether the new views are helping.

For OBJ.LIST, measure whether the exploratory question gets answered without building anything persistent. If every trial ends with a request for a permanent table, that's useful information about your actual requirement.

For query plans, record the stage-level time of your chosen DML jobs before any tuning, and compare afterwards. Direction matters more than a precise figure here, and I'd rather you didn't promise yourself a specific saving before you've looked at the plans.

What should you ignore, and where does a partner genuinely help?

Ignore the urge to reorganise your governance model because a new page exists. The Security center is a place to review and manage controls. It doesn't decide what your classification scheme should be or who should hold access. If your policy tags are a mess, a new console page won't fix that, though it may make the mess easier to see.

Ignore, too, any plan to turn OBJ.LIST into a production pipeline on the strength of this release. The notes say what the function returns. They don't say how it behaves at your scale, so test it on your own data.

A team can do most of this itself. Opening the Security center, using the jobs explorer, running OBJ.LIST on a prefix and reading a query plan are all within reach of a competent analytics engineer.

Where an implementation partner earns their fee is narrower. It's useful when you need to design a policy-tag taxonomy across several business units and migrate existing tables to it without breaking consumers. It's useful when unstructured data is becoming a real workload and you need decisions on access, structure and ownership. And it's useful when a handful of DML pipelines are costing more than they should and nobody in-house has time to untangle them. If that sounds like your situation, look at BigQuery implementation partners and compare shortlisted firms against what you actually need.

When you do brief someone, write down the outcome you want, not the features you've read about. A short RFP template helps: current state, the tables and buckets in scope, the access model you want, and how you'll judge success. A partner can't do much with a request to look into the new BigQuery release, but a clear question like which of our customer tables lack column-level controls gets a useful answer fast.

Finally, keep Google's documentation open while you work. The release notes are terse by nature, and details such as required roles, supported locations and limits belong to the vendor's own pages. For more on where BigQuery fits your stack, the rest of the MarTech Partners blog covers related changes as they land.

Sources

• Google Cloud: BigQuery release notes, 30 September 2026 — Security center GA, jobs explorer GA, OBJ.LIST GA, and DML and EXPORT execution steps in query plans.