DATAPLEXER FOR SHEETS™

Your Redshift tables.
Live in Google Sheets™.

A Google Sheets™ add-on that queries Amazon Redshift directly — point and click, or the SQL you already have. Results are written into the tab, and a scheduled refresh re-runs the query and writes the new rows at the hour you choose, while nobody has the spreadsheet open. You choose how it connects and who holds the credential; whichever you pick, it never reaches a browser.

Request accessSee how it works
  • No database password to share
  • Read-only queries
  • Serverless and provisioned clusters

Answers, not tickets

The people who need the number can get it themselves. The warehouse stays the one place the number comes from.

Connects your way

Route every query through one admin-held credential, or let each team own its own connection. Either way the credential lives in your Google Workspace™ and never reaches a browser.

Illustration: a spreadsheet showing quarterly revenue by region, populated from a Redshift query and refreshed on a schedule.

THE SPREADSHEET TAX

Every number in that sheet is a copy of the truth.

Warehouse data reaches spreadsheets in three ways, and all three have the same ending.

Export, paste, repeat

Someone runs the query, downloads a CSV and pastes it in. It is correct for about a day.

By Thursday the sheet and the warehouse disagree, and nobody can tell which one is wrong.

Hand out the credentials

The alternative is giving people warehouse access so they can connect their own tools.

Now the credential is in a laptop, a config file, a shared drive, and someone's old keychain.

Wait for the data team

So everything routes through the two people who are allowed to query production.

A two-minute question sits three days behind a roadmap, and the roadmap slips.

THERE IS A FOURTH WAY

Let the spreadsheet ask the warehouse itself.

One connection, pointed at your cluster or workgroup, owned by whoever should own it. The sheet fills itself and the credential is never copied, pasted, or mailed to anyone.

HOW IT WORKS

Three moving parts. None of them is a password.

Everything runs in two places you already own: your Google Workspace and your AWS account. There is no third party in the path.

01

Install the add-on

One install per person, arranged with your administrator once your access is approved. After that it is there in every spreadsheet they open, not just the one they installed it from.

02

Point it at your warehouse

A connection names a cluster or a Serverless workgroup and how to authenticate to it. Your administrator can hold one for the whole company, or each team can own its own — the next section is the whole menu.

03

Keep the sheet current

Build the query by clicking or paste your own SQL, write the results into the tab, then set it to run daily or on a chosen weekday at a chosen hour. From then on it re-runs and rewrites the tab on its own, with nobody in the spreadsheet.

CONNECTION MODELS

Your security posture is not a feature request.

Some companies want one credential, held centrally, that no end user ever sees. Others want each analyst federating their own Google identity into a scoped AWS role. Both are supported, side by side, in the same install — and so is everything in between.

Centralised, through a proxy

Your administrator deploys a small Apps Script web app in your Workspace and puts one AWS credential in it. Every query in the company goes through it. End users hold no AWS key of their own, cannot choose which cluster they hit, and the proxy audit-logs every query it runs.

Best when one team owns warehouse access for everyone.

Self-serve, per team

No proxy at all. A team defines its own connection in the add-on and the add-on signs its own requests. The credential lives in that user's Apps Script property store — server-side, scoped to them, available in every spreadsheet they open and in none of anyone else's.

Best when teams own their own data and their own AWS roles.

How it authenticates to AWS

  • IAM access keys

    A long-lived key pair, held server-side in your Workspace.

  • Google federated identity

    No stored AWS key at all. The user's own Google identity is exchanged for temporary AWS credentials through STS. Available in the add-on only — it cannot run through the proxy.

  • IAM Identity Center

    For organisations that mandate IDC as the only front door to AWS. The user approves a sign-in once and queries for the life of that session. Available in the add-on only, and it cannot be scheduled — the device grant needs a person at a browser.

Which database identity the query runs as

  • Temporary DB credentials

    AWS mints short-lived credentials for a named database user. Provisioned clusters only — there is no Serverless equivalent.

  • AWS Secrets Manager

    AWS resolves the secret server-side. The password is never seen by the add-on or the proxy.

  • IAM-mapped user, provisioned

    The caller's IAM identity maps to a database user on a cluster.

  • IAM-mapped user, Serverless

    The same, on a Serverless workgroup.

Pick a pair. The two axes are independent, so the way you reach AWS and the identity your query runs as are separate decisions — which is the point.

WHAT YOU GET

Everything a spreadsheet person needs, and nothing they don't.

Built for the analyst who knows the question and should not have to file a ticket to ask it.

Build the query by clicking

Pick columns, filters and sorts for raw rows. Or switch to Aggregate: drop fields into dimensions and measures and get SUM, AVG, MIN, MAX, COUNT and COUNT DISTINCT, with HAVING for filtering on the totals.

Refresh on a schedule, with the file closed

Daily, or a chosen weekday, at an hour you pick. The run is unattended — it opens the spreadsheet on its own and writes the new rows into the tabs while nobody has it open, so the numbers are already current when someone does. Every run is recorded, and a run that fails says so — instead of leaving a stale sheet looking fresh.

Credentials never reach a browser

Whether a credential is held centrally by an administrator or by the team that owns the data, it lives in a server-side Apps Script store inside your Workspace. With federated identity there is no stored AWS key at all.

Access, connection by connection

Each connection carries its own list of who may use it. Finance reaches the finance workgroup. Nobody reaches one they were not given.

Reads, not writes

The builder emits SELECT and nothing else, and statements are checked before they leave the sheet. The enforcement that matters is still where it belongs: your IAM policy and your database grants.

Serverless or provisioned

Point a connection at a Serverless workgroup or a cluster. Same builder, same schedule, same sheet.

THE BUILDER

Click the question. Read the SQL.

Nothing is hidden. Every query the builder writes is visible, copyable SQL — so the analyst who asked for the number and the engineer who reviews it are reading the same thing.

The builder panel, in Aggregate mode: dimensions created_at by month and region, measures SUM(mrr) and record count, rows filtered to status not equal to cancelled, and groups kept where SUM(mrr) is over 1000. The statement it generates is beside it.
Generated SQL
SELECT DATE_TRUNC('month', "created_at") AS "month_created_at",       "region"                          AS "region",       SUM("mrr")                        AS "sum_mrr",       COUNT(*)                          AS "record_count"FROM "public"."subscriptions"WHERE "status" != 'cancelled'GROUP BY 1, 2HAVING SUM("mrr") > 1000ORDER BY 3 DESC, 1LIMIT 100;

Or paste your own SQL and skip the builder entirely.

NO MIDDLEMAN

There is no third party in the path.

Most ways of getting warehouse data into a spreadsheet put a hosted service in the middle. You create an account with a vendor, give their cloud a credential for your warehouse, and their add-on talks to their servers, which talk to your database. Every query and every row makes a round trip through a company that is not yours.

The usual shape

Your credentials live with the vendor. Your rows pass through them.

This add-on

Nothing in between.

Your data never leaves your accounts

Rows travel from your Redshift cluster to your spreadsheet. Both are yours. Nothing in between stores them, caches them, or forwards them anywhere.

Your credentials never leave either

They sit in an Apps Script store inside your Google Workspace, or are minted as temporary AWS credentials against your own identity. No vendor holds a copy, because no vendor is given one.

A vendor breach is not your breach

When a hosted connector is compromised, every customer's warehouse credentials are in one place — that is what makes it worth attacking. There is no such place here.

One thing does leave your Workspace, and it is not your data: a licence check. The add-on asks our control plane whether your organisation is entitled to use it, sending a Google identity token so we can match it against our allowlist. No warehouse credential, no query, no row — and what we keep is operational — a timestamp, a decision code, a latency measure, cache state, and a one-way salted digest of the user id. Never the raw token, never the email, never the domain.

SECURITY

Built for the person who has to sign off on it.

There is no vendor in the middle. Every part of this runs inside accounts you already own and already audit.

Everything runs in accounts you own

The add-on and the optional proxy run in your Google Workspace. The warehouse runs in your AWS account. Credentials sit in server-side Apps Script property stores, and there is no service of ours in the query path.

Every request is SigV4-signed, wherever it is signed

Through the proxy, your administrator's credential signs for everyone. Direct from the add-on, the connection's own credential signs — or, with federated identity, temporary credentials AWS issues against the user's Google identity.

Every query is logged, with who ran it

The proxy audit-logs each query it runs. Runs from a schedule are recorded too, so a refresh that stopped working is visible rather than silent.

Access is enforced where it counts

Authorisation is your IAM policy and your database grants, plus a per-connection allowlist when you run the proxy. The add-on also checks that a statement is read-only before sending it — a guard on top of those, not a replacement for them.

There is no shared database password, because there is nowhere to put one: Amazon's Redshift Data API takes no password at all. Authentication is IAM, temporary credentials, or Secrets Manager.

WHO IT'S FOR

Three people have the same problem from three directions.

Data & analytics leads

You own the warehouse and the definitions in it.

Today You are a CSV vending machine, and half the numbers in circulation are forks of yours.

With this The questions that do not need you stop reaching you, and every answer still comes from your tables.

Finance, ops & revenue analysts

You live in the model, not in the warehouse.

Today The model is good. The numbers in it are four days old.

With this The model reads live warehouse tables and refreshes itself before you open it.

Platform & security owners

You are the one who signs off on access.

Today You do not know how many copies of that credential exist, or where.

With this One credential, in one place you control, with a log of every query it ran.

LIMITS AND SUPPORT

The numbers, before you ask.

The first five are Amazon's published limits on the Redshift Data API, which this add-on uses. They are not our benchmarks — they are the ceiling AWS sets on any client of that API, including this one.

Warehouses
Redshift Serverless workgroups and provisioned clusters
Maximum query duration
24 hours
Maximum result size
500 MB, after gzip compression
Maximum statement size
200 KB
Concurrent queries per cluster
500 active
Database authentication
IAM temporary credentials, Secrets Manager, or Google-federated identity
Refresh schedule
Daily, or a chosen weekday, at a chosen hour
Distribution
Private, scoped to your Google Workspace domain

PRICING

One price. One plan. Everything included.

Ten dollars per user, per month — however many people you are, and whatever you do with it.

$10

per user, per month

Every feature, every connection model, every spreadsheet. The only thing that scales is how many people you add.

Request access

One plan, and it includes everything below. We do not meter your queries, your rows, or your spreadsheets. The only ceilings are the ones your own AWS account and Google Workspace already set.

  • Unmetered. We do not count your queries, your rows, or your spreadsheets.

  • No vendor in the data path. Your credentials and your rows never touch anyone else's cloud.

  • Every connection model. Centralised through a proxy, or owned per team — with IAM keys, a federated Google identity, or IAM Identity Center.

  • The visual builder, and the SQL it writes. Point and click for raw rows or aggregates; the generated SQL is always visible and copyable.

  • Refresh on a schedule. Daily, or a chosen weekday, at an hour you pick.

  • Serverless and provisioned. Same builder, same schedule, either target.

  • Read-only by construction. The builder emits SELECT; enforcement stays in your IAM policy and your database grants.

  • Access control per connection. Run the proxy and each connection carries its own allowlist.

QUESTIONS

The eight things everyone asks.

Do I have to share my database password?

No — and there is nowhere to put one. Amazon's Redshift Data API takes no password parameter at all. A connection authenticates with temporary database credentials, an AWS Secrets Manager secret that AWS resolves server-side, or an IAM identity mapped to a database user. The connection models above are the full menu.

Where do the AWS credentials actually live?

Wherever you decide. Run the proxy and one credential sits in it, held by your administrator, invisible to end users. Skip the proxy and each connection's credential sits in that user's own Apps Script property store. Both are server-side stores inside your Workspace — neither is in a browser — and with federated identity nothing long-lived is stored at all.

Can someone use this to change data?

The builder emits SELECT and nothing else, and statements are checked before they leave the sheet. But the enforcement you should rely on is the one you already run: the IAM policy on whichever credential the connection uses, and the grants on the database user it connects as. Give it read-only rights and it has read-only rights.

Does it work with Redshift Serverless?

Yes. A connection points at either a Serverless workgroup or a provisioned cluster, and everything downstream is identical.

How often can a sheet refresh?

Daily, or on a specific weekday, at an hour you choose. Each tab keeps its own query, so one spreadsheet can hold several that refresh together.

How much data can one query return?

Amazon caps a Redshift Data API result at 500 MB after gzip compression, and a query at 24 hours. In practice a spreadsheet is the tighter constraint — this is for the answer, not for the export.

What does my administrator have to do?

Less than you would expect, and it depends which topology you pick. In both, some credential needs three Redshift Data API permissions — ExecuteStatement, DescribeStatement, GetStatementResult — plus access to the target cluster. If you want the centralised model, they also deploy the proxy web app once and hand out its URL. If teams own their own connections, they do not.

What can you see?

None of your data, and none of your credentials. Queries and rows travel from your Workspace to your AWS account and back — the add-on runs in your Workspace, the proxy, if you run one, runs in your Workspace, and the warehouse is yours. One thing does leave: a licence check. The add-on asks our control plane whether your organisation is entitled to use it, sending a Google identity token so we can match it against our allowlist. That call carries no warehouse credential, no query and no row, and what we keep is operational — a timestamp, a decision code, a latency measure, cache state, and a one-way salted digest of the user id. Never the raw token, never the email, never the domain.

Put your warehouse in the sheet.

Tell us about your setup and we will get your team access.

Request access

Protegido por reCAPTCHA — aplican la Privacidad y los Términos de Google.

Dataplexer for Sheets™ privacy policy Dataplexer for Sheets™ terms of service