BigQuery Iceberg flexible column names and Gemini SQL editor

On 8 October 2026 Google Cloud announced two generally available changes to BigQuery. Iceberg external tables, Iceberg managed tables in BigQuery and Apache Iceberg tables managed by the Lakehouse runtime catalog now support flexible column names by default. And the BigQuery Studio SQL editor has a Gemini inline action button that appears when you select text.

The first change is about data modelling and interoperability. The second is about how people write SQL day to day. Neither needs a migration project, but both reward a short, deliberate review.

Key takeaways

• Flexible column names are now the default for three kinds of Iceberg table in BigQuery, and the feature is generally available as of 8 October 2026.
• The change matters most where Iceberg data comes from other engines or source systems whose field names don't fit tidy identifier rules.
• Audit anything downstream that parses, quotes or generates column names before you start landing new styles of name.
• The Gemini inline action in the BigQuery Studio SQL editor is also generally available. Review what it produces before running it.
• Both changes are small enough for an in-house team to handle. Bring in a partner for naming standards across many sources or for governance of AI-assisted SQL.

What did BigQuery change for Iceberg tables on 8 October 2026?

The release notes for 8 October 2026 say that flexible column names are now supported by default for the following table types:

• Iceberg external tables
• Iceberg managed tables in BigQuery
• Apache Iceberg tables managed by the Lakehouse runtime catalog

The notes label this a feature and mark it generally available. That means it's a production-supported capability, not a preview or an allowlisted trial.

Flexible column names are a BigQuery capability that lets column names use a wider range of characters than the older, stricter naming rules allowed. The practical point is that BigQuery can now sit closer to how data is actually named upstream, rather than forcing a rename at the door. For the exact list of permitted characters and any remaining restrictions, read the BigQuery documentation on column naming. Don't rely on a blog post for that, this one included.

The word to notice in the announcement is 'default'. The release note doesn't describe a switch you flip or a table option you set. It describes these three table types as supporting flexible column names out of the box. If you want to know how that interacts with tables you created before this date, the documentation for each table type is the place to confirm it.

Why do column names matter for Iceberg in particular?

Iceberg is an open table format, which means the same table is often touched by more than one engine. A Spark job writes it, a streaming pipeline appends to it, and BigQuery reads it. Each of those engines has its own opinion about what a legal column name looks like.

That's where friction used to come from. Imagine an operations team ingesting records from a marketing platform export. Fields arrive named 'Campaign Name' or 'Revenue (USD)' or something with accented characters from a regional system. The upstream engine is happy to store those. If the warehouse side had stricter rules, someone wrote a rename layer, and that rename layer became a thing to maintain, document and debug.

Support for flexible names by default on Iceberg tables in BigQuery lowers the pressure for that rename layer. It doesn't make naming policy irrelevant. It moves the decision. Before, the platform made it for you by rejecting names. Now your team has to decide, on purpose, which names are worth keeping.

That is a good trade for most teams, but only if somebody owns the decision.

Who needs to act, and who can ignore this?

Not every BigQuery team needs to do anything. A quick way to sort yourself:

Situation	Affected?	Suggested action
You run native BigQuery tables only and don't use Iceberg	No	Read the change, move on
You query Iceberg external tables written by another engine	Yes	Review which upstream names you've been renaming and whether you still need to
You use Iceberg managed tables in BigQuery	Yes	Decide on a naming convention for new tables before the flexibility gets used ad hoc
You use Apache Iceberg tables managed by the Lakehouse runtime catalog	Yes	Same review, plus check what other engines reading the catalog expect
You own dashboards or reverse-ETL jobs fed from Iceberg tables	Yes, indirectly	Test them against any new style of column name before it reaches production

The people who should read this properly are data engineers who own ingestion, and analytics engineers who own the models on top. Marketing analysts who only consume a curated reporting layer can skim it.

If your Iceberg usage is a single table that has worked fine for a year, the sensible response is to note the change and leave it alone.

What should you check before using unusual column names?

The risk with a more permissive naming rule is not in BigQuery. It's in everything that touches the name afterwards. A column called something with spaces or punctuation in it will need quoting in SQL. Any tool that builds SQL by string concatenation may or may not quote correctly.

Work through this list before you let new-style names into a shared table:

1. List your consumers. Scheduled queries, views, BI tools, notebooks, reverse-ETL jobs, anything exporting to a downstream system.
2. Test quoting. Pick one table with a deliberately awkward column name in a non-production dataset and query it from each consumer. Note which ones fail.
3. Check other engines. If the same Iceberg table is read by Spark, Trino or another engine, confirm they read the names you intend to write. That's a question for their documentation.
4. Check exports and extracts. CSV headers, JSON keys and API payloads built from column names will carry whatever you choose into systems you don't control.
5. Write the convention down. Even a half-page note saying 'we keep source names for raw tables and use clean names in the modelled layer' saves arguments later.

A worked example helps. Say a retailer's analytics team receives a daily Iceberg table from a loyalty platform. Today a view renames fourteen columns into snake case so Looker, a Python notebook and a reverse-ETL job all work. After this change they could point straight at the raw names. They shouldn't. The better move is to keep the rename view for the consumer-facing layer and use flexible names to make the raw landing table a faithful copy of the source. The raw layer gets fidelity; the modelled layer gets stability.

What is the Gemini inline action in the SQL editor?

The second item on 8 October 2026 says you can use Gemini assistance in the BigQuery Studio SQL editor through an inline action button when you select text. The notes mark it generally available and point to Google's page on writing SQL with Gemini assistance.

That is all the notes say about it. In practice, it means that when you highlight part of your query in the editor, a button appears next to the selection that lets you ask Gemini to help with that piece. The point is to keep you in the editor and working on the specific lines you care about, rather than copying text out to a separate chat window.

The release note doesn't spell out which actions the button offers, what the setup or permission requirements are, or how it's priced or licensed. Read Google's documentation page on writing SQL with Gemini assistance for those details before you roll it out to a team, particularly if your organisation has rules about which AI features are enabled in which projects.

Here is a position worth taking. This is a productivity feature for people who already read SQL well. It's most useful to an analyst who knows what they want and wants a faster first draft of a window function or a tedious join. It's riskiest for someone who can't tell whether the result is right.

How should you roll out both changes?

Treat them as two separate small projects with different owners. They don't depend on each other, though they meet in one place: an assistant asked to write SQL against a table with awkward column names will need those names quoted correctly, so you'll want to read what it produces.

Step	Owner	What to do	Done when
Inventory Iceberg tables by type	Data platform lead	List external, managed and Lakehouse runtime catalog tables	You know which tables the change applies to
Review current rename layers	Analytics engineering	Mark which renames exist only because of old naming limits	Each rename has a keep or retire decision
Pilot an awkward name in a sandbox	Data engineer	Query it from every consumer	A pass/fail list per consumer
Agree a naming convention	Data platform lead with analytics	Write it down, short	Published where engineers will find it
Review Gemini documentation	Data platform lead	Confirm setup, access and any organisation policy implications	A decision on who gets access
Short Gemini trial	Two or three analysts	Use it on real but non-sensitive queries and report back	A written verdict, good or bad

Keep the pilots small. A week of real use from three people tells you more than a month of planning.

How do you measure whether either change helped?

Pick measures that match the actual problem, not the feature.

For flexible column names, the useful signals are about effort and breakage:

• How many rename views or mapping scripts did you retire, and how many hours a month did they cost to maintain?
• How many ingestion failures in the last quarter were caused by a column name that couldn't be handled?
• How many downstream jobs broke after a naming change in the first month?

If the first number goes down and the third stays at zero, you've got a clean win. If the third number climbs, you moved too fast.

For the Gemini inline action, measure with colleagues rather than counters. Ask the pilot group how often they accepted the suggestion unchanged, how often they edited it, and how often they threw it away. A rough tally over a couple of weeks is enough. Also ask a reviewer to read a sample of queries that used the feature. Wrong answers that look right are the cost you care about, and no usage dashboard will show them to you.

Don't invent a productivity percentage and report it upward. Direction and examples are more honest and more persuasive.

What shouldn't you do?

A few things are tempting and wrong:

• Don't mass-rename existing columns because you can. Renames break references. Only change names that are causing you real pain.
• Don't let every pipeline pick its own style. Permissive rules without a convention produce a table where the same concept has three spellings.
• Don't assume every tool downstream handles unusual names. Test them; the platform accepting a name is not the same as your dashboard tool accepting it.
• Don't paste Gemini output into a scheduled production query unread. Review it, run it on a small slice first, and check the results against something you trust.
• Don't switch the Gemini feature on for everyone and call it governance. Decide who gets it, for what kind of work, and who reviews.
• Don't treat the release notes as the full specification. They're a summary. The product documentation holds the limits and conditions.

Where does an implementation partner help, and where can you do it yourself?

Most of this you can do yourself. An in-house team with someone who knows Iceberg and BigQuery can run the inventory, the sandbox test and the convention document in a couple of weeks of part-time effort. The Gemini trial needs no outside help at all.

A partner becomes worth paying when the problem is bigger than one table or one team. Three situations stand out:

1. Many sources, one standard. If you're pulling Iceberg data from a dozen systems owned by different teams, agreeing a naming and layering standard is mostly a people problem, and an outsider with a template and no stake in the outcome can move it along.
2. Multi-engine estates. When the same Iceberg tables are read by BigQuery and other engines, someone has to test the whole chain. That's tedious, cross-tool work.
3. Governance of AI-assisted SQL. If you're in a regulated sector, deciding who may use assistive features, on which data, with what review, benefits from experience of how other organisations have set it up.

If you do want help, start by looking at BigQuery implementation partners and the broader Google data and analytics partner list. Write the brief before you call anyone: which tables, which engines, which consumers, what you want finished. The RFP template is a reasonable starting point for that. A vague brief gets a vague quote.

For a wider view of BigQuery changes as they land, the MarTech Partners blog tracks them.

What is the practical bottom line?

Flexible column names by default on Iceberg tables is the more consequential of the two changes for platform teams, because it alters a rule other systems may have been quietly relying on. Do the consumer audit, write the convention, and change nothing that isn't hurting.

The Gemini inline action is the easier win and the easier mistake. Try it, read what it writes, and keep a person responsible for every query that reaches production.

Both are generally available as of 8 October 2026. Neither is urgent. Both are worth an afternoon this month.

Sources

• Google Cloud: BigQuery release notes, 8 October 2026 — Flexible column names by default for Iceberg tables, and Gemini inline action in the BigQuery Studio SQL editor, both GA.