DEV Community: Abd Alrhman Alloush

How GCP Service Accounts Work for Database Access Tools

Abd Alrhman Alloush — Mon, 26 Oct 2026 05:09:13 +0000

If you've ever connected a third-party tool to a GCP project, you've run into the same ritual: create a service account, attach some roles, download a JSON key, paste it somewhere. Most DBAs do this on autopilot without stopping to think about what a service account actually is, which roles it really needs, and what happens if that JSON key leaks.

That's worth slowing down for. Service account permissions are one of the most common places database security goes quietly wrong — not through a sophisticated attack, but through a service account granted far more than it needed, because "Editor" was faster to click than figuring out the right role.

TL;DR

A GCP service account's permissions come entirely from the IAM roles you attach — there's no implicit access beyond that. For a tool that only needs to discover Cloud SQL and Cloud Spanner instances, roles/cloudsql.viewer and roles/spanner.viewer are the only roles needed. 1DataCloud connects to GCP using exactly those two roles. Try it free →

What a GCP Service Account Actually Is

A service account is an identity — not a human one. It's what applications, scripts, and third-party tools use to authenticate to Google Cloud APIs, the way your own Google account authenticates you in the GCP Console.

The part that matters: a service account's permissions come entirely from the IAM roles you attach to it. There's no default level of access. A brand-new service account with no roles can do nothing.

Download its JSON key, and you're holding long-lived credentials for that identity. Anyone with that file can authenticate as the service account and do whatever its roles allow — which is exactly why the roles attached matter so much.

The Roles That Actually Matter for Database Discovery

For a tool that only needs to discover and inspect database instances — not modify them — two predefined roles cover it:

roles/cloudsql.viewer — read-only visibility into Cloud SQL: instance names, regions, tiers, versions, status, configuration. No create, modify, delete, or data access.

roles/spanner.viewer — the equivalent for Cloud Spanner: instance and database metadata, no schema or data modification.

Both are scoped specifically to metadata visibility for their service. Neither touches Compute Engine, billing, IAM, or anything else in the project.

What not to grant

The common shortcut is attaching Editor or Owner because it "definitely includes" whatever narrower permission is needed. It does — along with the ability to modify or delete nearly everything else in the project. A leaked key tied to a viewer role exposes metadata. A leaked key tied to Editor exposes your entire GCP project.

How 1DataCloud Uses This

1DataCloud's GCP connection runs on exactly roles/cloudsql.viewer and roles/spanner.viewer — nothing broader. With just those two roles, it uses the GCP API to discover every Cloud SQL and Cloud Spanner instance across every project the service account can see, automatically. No project-by-project browsing, no permissions beyond what's needed to build that inventory.

Once an instance is connected for querying, its schema is read and mapped so Query1AI can turn plain-English questions into read-only SQL — but the discovery step itself never required write access to anything.

If that JSON key were ever exposed, the worst case is someone viewing your database inventory metadata — not modifying a database, not touching unrelated GCP services, not reaching billing. That's a very different incident than a leaked key with Editor attached.

Mistakes Worth Avoiding

One service account for everything. A single, broadly-scoped account shared across five tools means a compromise of any one is a compromise of all five.
Keys that never rotate. A JSON key doesn't expire on its own.
Using the default Compute Engine service account, which often carries broad project-level permissions by default, for a narrow task like discovery.
Project-level roles when a resource-level one exists — even when the project-wide version is more convenient to click through.

Summary

A GCP service account is only as risky as the roles attached to it. For database discovery, roles/cloudsql.viewer and roles/spanner.viewer grant exactly enough visibility to build an inventory — nothing more. 1DataCloud's own GCP connection runs on exactly those two roles.

👉 See how 1DataCloud connects to GCP
👉 Try it free

What's your team's policy on service account scoping — one per integration, or shared accounts with broader roles? Curious how others handle this in practice.

Why Every Query Your Team Runs Should Leave a Paper Trail

Abd Alrhman Alloush — Thu, 22 Oct 2026 07:51:54 +0000

Here's a question worth asking before you roll out self-service database access to anyone outside engineering: three weeks from now, when a number in a report looks wrong, can you tell who asked for it and what query actually ran?

If the answer is "we'd have to ask around," you don't have self-service access yet. You have an open door.

TL;DR

Natural-language database access removes the bottleneck of needing an engineer to write every query — but it only holds up if every question asked, and the exact SQL it generated, gets logged. Query1AI does both: schema-aware natural language to read-only SQL, with every question and every generated query kept in a trail you can go back and check. No writes, no black box.

The Part of Self-Service Access Nobody Markets

Most pitches for "ask your database a question in plain English" stop at the demo: type a question, get an answer, everyone's impressed.

What they skip is the part that actually determines whether a team is comfortable turning this on for non-engineers: what happens after the answer comes back.

A number shows up in a board deck. Where did it come from?
A number looks wrong a month later. Who generated it, and what did they actually ask?
A new hire types something ambiguous. What query did the system decide to run on their behalf?

None of those are hypothetical. They're the exact questions a security or compliance review asks the first time someone proposes giving non-engineers direct database access — and "we trust the AI" is not an answer that survives that conversation.

What a Query Needs to Leave Behind

For natural-language database access to be something you can actually stand behind, three things have to be true of every question asked:

It's logged. Who asked, when, and what they typed — not just the final number they saw.
The generated query is visible. Not just "it ran a query" — the actual SQL, so anyone reviewing it later can see exactly what was executed.
It can't have been a write. If the worst-case outcome of a wrong guess is a wrong answer instead of a changed row, the whole audit conversation gets a lot shorter.

Miss any one of these and "self-service" quietly becomes "we gave people a button we can't explain."

How This Works in Query1AI

This isn't a separate feature bolted on top — it falls out of how Query1AI is built:

Schema-aware, not schema-blind. When you connect a database, 1DataCloud reads the table names, column names, types, and relationships. That map is what Query1AI works from — it's why a question like "which customers haven't logged in for 30 days" turns into a real query against your real tables, not a generic guess.

Read-only, enforced at the system level. Query1AI only ever generates and runs SELECT statements. INSERT, UPDATE, DELETE, and DDL aren't filtered out after the fact — they're not a path the system can take. Worst case is a wrong answer, never a wrong write.

Every question and query kept in a trail. Each question asked through Query1AI, the SQL it generated, and who asked it are kept, so you can go back and check — not a live feed watching for anomalies, just a record you can pull up when you need it.

Put together, that's the actual answer to "what happens after someone asks a question": you can reconstruct it.

This Is a Trail, Not a Watchtower

Worth being precise about what this is not: it's not a monitoring system scanning queries in real time for anything suspicious, and it doesn't flag or alert on unusual activity on its own. It's a record that exists because every question already has to go somewhere — so instead of disappearing after the answer is shown, it's kept.

If you need active alerting on query patterns, that's a different system, and an honest answer today is that it isn't this one. What you do get is the ability to answer "who asked for this, and what actually ran" without reconstructing it from memory.

Why This Is the Part That Lets You Say Yes

Engineering teams already trust themselves with database access because they can be held accountable for what they run — it's logged somewhere, even if informally, in query history or shell history.

Non-technical self-service access doesn't get that trust for free. It has to be built in. The moment a product manager or sales lead can type a question and get a number back, someone on your security or compliance team is going to ask what happens if that number is wrong, or if that access gets misused.

"Every question and the exact SQL it ran is logged, and nothing but SELECT ever executes" is a real answer to that question. "Trust the AI" isn't.

That's the difference between a feature you can demo and a feature you can actually turn on for your whole company.

👉 See how Query1AI works
👉 Try it free

If your team has rolled out any kind of self-service data access — AI-driven or a plain BI tool — how did you handle the "who ran what" question? Curious what's actually worked.

On-Premise Database Inventory: Bringing MySQL and PostgreSQL Into One Multi-Cloud View

Abd Alrhman Alloush — Mon, 19 Oct 2026 07:05:48 +0000

Most multi-cloud database discussions start and end with AWS, GCP, and maybe MongoDB Atlas. On-premise databases rarely come up — not because teams don't have them, but because almost no tooling treats them as a first-class citizen.

That's a problem, because on-premise MySQL and PostgreSQL instances are still extremely common. Legacy applications that were never migrated. Databases that have to stay on-prem for data residency or latency reasons. Infrastructure acquired along with a company that hasn't been touched since. These instances don't disappear just because the rest of the stack moved to the cloud — they just become harder to see.

TL;DR

On-premise MySQL and PostgreSQL databases don't show up in any cloud API, so most "unified" multi-cloud tools quietly skip them. 1DataCloud connects to them directly via a read-only database connection and lists them in the same inventory as your AWS, GCP, and MongoDB Atlas instances — schema mapped, queryable in plain English. Try it free →

Why On-Premise Databases Become the Blind Spot

There's no cloud API to ask. AWS, GCP, and MongoDB Atlas all expose management APIs a tool can query to discover what exists. On-premise infrastructure has no equivalent — if a tool wants to know an on-prem database exists, someone has to tell it directly.

Discovery depends on tribal knowledge. On-prem inventory tends to live in people's heads, a wiki page, or a spreadsheet that was accurate as of some point last year. When the person who set up an instance leaves, the knowledge usually leaves with them.

It gets left out of "unified" views. Plenty of tools genuinely unify AWS and GCP, then stop there, because cloud APIs are the easy part. On-prem requires a direct connection to the database itself, so it's often skipped or bolted on as an afterthought.

Compliance treats it as a separate exercise. If cloud databases are inventoried automatically but on-prem ones are tracked manually, every audit ends up doing two different things — pull a report for the cloud side, then manually reconstruct the on-prem side.

A Better Workflow

Step 1 — Connect with a database connection string. Add the host, port, and a read-only database user for your on-prem MySQL or PostgreSQL instance. Since there's no cloud API, this is a direct database connection rather than an auto-discovery scan.

Step 2 — It shows up next to AWS, GCP, and Atlas. The on-prem instance appears in the same inventory list as your RDS, Cloud SQL, and Atlas clusters — engine, version, and status, side by side. One list, filterable by provider.

Step 3 — Schema loads automatically. The platform reads the database's tables, columns, data types, and relationships the same way it would for a cloud-hosted instance. No manual schema docs to maintain.

Step 4 — Query in plain English. With the schema mapped, Query1AI turns a plain-English question into read-only SQL for that on-prem instance, the same mechanism used for any connected database.

What's Actually Supported

On-premise MySQL, PostgreSQL, and MariaDB, via a direct read-only database connection — alongside the existing cloud coverage for AWS, GCP, and MongoDB Atlas, all in the same inventory. (Azure is still in active development and isn't part of this today.)

Where This Helps

One inventory instead of "cloud databases, plus that spreadsheet." Before: a dashboard for cloud databases and a separate, frequently stale document for whatever's still on-prem. After: everything's in the same list, filterable by provider.

Letting a non-technical teammate query a legacy on-prem database. Before: only the few engineers who remember the schema can get an answer out of it. After: anyone with dashboard access can ask a plain-English question through Query1AI once it's connected.

Onboarding an engineer to infrastructure that predates them. Before: they learn what's running on-prem by asking around. After: they see it in the inventory from day one, schema already mapped.

Security Model

The database user should be read-only; queries Query1AI generates and executes are strictly read-only regardless — no INSERT, UPDATE, DELETE, or DDL
The instance has to be network-reachable (firewall rule, VPN, or bastion) — nothing is installed on the database host itself
Connection details are encrypted at rest, never shown in the UI after entry, never logged
1DataCloud stores schema metadata, not your data — query results return to your browser session and aren't retained server-side

1DataCloud for On-Premise Databases

On-prem MySQL, PostgreSQL, and MariaDB listed alongside AWS, GCP, and MongoDB Atlas in one inventory
Filter by provider to isolate what's running outside the cloud
Schema metadata loaded automatically once connected
Natural language querying via Query1AI, read-only
One place to look, whether the answer lives on-prem or in the cloud

Free to try, setup in a few minutes.

👉 Connect your databases at 1datacloud.ai

Full write-up with FAQ and more detail on the security model: 1datacloud.ai/blog/on-premise-database-inventory-multi-cloud-view

Why Your Team Needs a Multi-Cloud Database Inventory

Abd Alrhman Alloush — Thu, 15 Oct 2026 11:49:35 +0000

Quick question: how many database instances is your team running right now?

Not an estimate. The exact number, across all your cloud providers, all your accounts, all your regions.

If you can answer that in under 10 seconds without opening a console, you have a database inventory. Most teams don't.

TL;DR

A multi-cloud database inventory is a single, always-current list of every database instance your organization runs — across AWS, GCP, MongoDB Atlas, and on-prem. Without one, you're flying blind. 1DataCloud automates this without agents or manual tracking. Try it free →

The Hidden Complexity Problem

Ten years ago, most companies had a simple database setup: a few MySQL or PostgreSQL instances, maybe a replica or two, running in a single data center or a single AWS account. One person knew where everything was.

Today, the landscape looks completely different:

Multiple cloud providers. AWS for most workloads, GCP for analytics (BigQuery is hard to replace), maybe Azure for a legacy integration, MongoDB Atlas for flexibility.
Multiple accounts per provider. Separate AWS accounts for prod, staging, dev, each product team, each regulated workload.
Multiple regions. Latency requirements, data residency laws, disaster recovery — all push toward multi-region deployments.
Multiple engine types. Relational, document, key-value, column-family, graph. Often in the same organization, sometimes for the same product.

The result is that "where are our databases?" is no longer a question with an obvious answer. And the consequences of not knowing are real.

What Happens Without a Database Inventory

You forget what you have

Databases created for a project that ended. Test instances that were supposed to be temporary. Replicas that were promoted and then the original was never cleaned up. Without an inventory, these accumulate silently — incurring cost, creating attack surface, and holding data that shouldn't be held.

Security gaps appear

A database that isn't in your inventory isn't in your patching cycle. It isn't reviewed during access audits. It might be publicly accessible. It might have a root password that was never rotated. You don't know, because you don't know it exists.

Onboarding is painful

Every new engineer needs to learn "the landscape" from whoever holds the tribal knowledge. This takes weeks, it's always incomplete, and it walks out the door when that person leaves.

Incident response slows down

When something breaks at 2 AM, you don't want to be asking "which database is connected to which service?" That mapping should already exist. Without an inventory, you're reconstructing it under pressure.

Compliance becomes a project

GDPR, SOC 2, HIPAA — all of them require knowing where data is stored. If you don't have a database inventory, every compliance audit becomes a weeks-long archaeology project.

What a Database Inventory Actually Contains

At minimum, a useful database inventory answers these questions for every instance:

Field	Why it matters
Cloud provider	Determines which tools and APIs apply
Account / project	Determines ownership and billing
Region	Affects latency, data residency, DR planning
Engine and version	Drives patching and end-of-life planning
Instance size	Capacity planning and cost optimization
Status	Running? Stopped? Rebooting?
Multi-AZ / HA	Risk assessment
Publicly accessible	Security posture
Connected services	Impact radius for incidents
Schema metadata	What data is actually stored there

The last two are the hardest — and the most valuable.

Why Multi-Cloud Makes This Harder

If you were on a single cloud provider with a single account, an inventory is manageable. You can use native tools (AWS Resource Explorer, GCP Asset Inventory) to get a reasonable view.

The moment you span providers, those native tools stop helping. AWS doesn't show your GCP instances. GCP doesn't know about your MongoDB Atlas clusters. Neither knows about your on-prem PostgreSQL.

This forces teams into one of three bad options:

Manual spreadsheets. Updated when someone remembers. Always out of date. Doesn't scale.
Home-built tooling. Scraping APIs from each provider, aggregating results, building a UI. This is weeks of engineering time that solves a problem that isn't your core product.
Ignoring it. Accepting the risk and operational friction as a cost of doing business.

None of these are good options when you're trying to move fast.

What an Automated Inventory Looks Like

The right solution connects directly to each cloud provider's API, discovers instances automatically, and presents them in a unified view that stays current without manual updates.

This is what 1DataCloud does.

Connect once, discover continuously:
Add your AWS IAM credentials, GCP service account, MongoDB Atlas API key, or on-prem connection strings. 1DataCloud queries each provider's management APIs and builds a unified inventory automatically.

What it discovers today:

AWS: RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server), Aurora, Redshift, DynamoDB, ElastiCache, DocumentDB, Neptune
GCP: Cloud SQL, Spanner, BigQuery, Firestore, Bigtable
MongoDB Atlas: clusters across all projects
On-prem: MySQL, PostgreSQL, MariaDB

Coming soon: Microsoft Azure (SQL Database, Cosmos DB, Azure PostgreSQL)

No agents required:
Everything is read-only and API-based. Nothing is installed on your database nodes. Existing cloud security primitives (IAM roles, service accounts) are used directly.

Schema metadata included:
Click any instance and browse its tables, columns, data types, and indexes. This is the layer that turns an inventory from a list of instances into a map of where your data lives.

The Organizational Benefits

Beyond the operational improvements, a database inventory changes how the organization relates to its data infrastructure:

Engineering teams stop wasting time on "what's running where?" and start spending it on things that matter.

Security teams get a complete surface area to audit — without a months-long discovery exercise before every review.

Data teams know where the data they need actually lives, without filing tickets to find out.

Leadership can make capacity, cost, and risk decisions based on a complete picture, not a best guess.

Getting Started

If you don't have a database inventory today, the fastest path to one is to stop trying to build it manually and connect to a tool that maintains it automatically.

1DataCloud is free to start — connect up to 3 database instances across any provider, no credit card required.

If your team is managing more than that, Pro and Enterprise tiers support unlimited instances across all providers with shared organizational access and RBAC.

👉 1datacloud.ai

👉 Start free

One More Thing

Once you have an inventory with schema metadata, natural language querying becomes possible. Instead of "I know the data exists somewhere in our infrastructure" being the beginning of a long search, it becomes the beginning of a question: "How many active users do we have across all our regional databases?"

That's what Query1AI is for — but you need the inventory first.

Does your team have a database inventory today? How do you maintain it? Genuinely curious what approaches people are using at different scales.

MongoDB Atlas Database Management Without the Atlas UI

Abd Alrhman Alloush — Mon, 12 Oct 2026 06:22:28 +0000

MongoDB Atlas does a genuinely good job of managing MongoDB. Cluster provisioning, scaling, backups, and monitoring are all handled through a single, well-built console.

The catch is in that sentence: it's a console for MongoDB. The moment your org also runs AWS RDS, GCP Cloud SQL, or an on-prem database alongside Atlas — which is the normal state past a certain team size — you're back to the same problem every cloud-specific console creates. Atlas tells you everything about your MongoDB clusters and nothing about anything else.

TL;DR

Atlas organizes MongoDB clusters by Project and gives you a capable console for managing them — but it has no idea your team also runs RDS or Cloud SQL, and querying anything beyond basic filters means writing an aggregation pipeline. We built 1DataCloud to put Atlas clusters in the same inventory as your other databases, and let anyone ask a question in plain English instead of hand-writing MongoDB query syntax. Try it free →

Where the Atlas UI Falls Short Once You're Multi-Database

It only knows about MongoDB. If your app's primary store is Atlas and your reporting or billing database is RDS or Cloud SQL, there's no single screen — in Atlas or anywhere else — that shows both. You check one console for half your infrastructure and a different one for the rest.

Querying is a separate skill from managing. Atlas gives you a solid UI for cluster config, and a separate interface (Data Explorer, or mongosh) for actually looking at data. Aggregation pipelines have a real learning curve, and it's a different syntax from the SQL your team already knows for its relational databases.

Projects add a navigation layer. Sensible for access control, less sensible when you just want to answer "what clusters do we actually have running" — multiple projects means multiple places to check.

Non-technical teammates are locked out by default. Getting a PM an answer from MongoDB means teaching them aggregation syntax or routing it through an engineer. Same bottleneck relational databases create, just with a different query language.

A Better Workflow

Step 1 — Connect your Atlas account once. Provide an Atlas API key pair scoped to read-only Project Data Access. The platform uses the Atlas Administration API to discover every cluster across every project tied to that key — automatically.

Step 2 — See Atlas clusters next to everything else. Every discovered cluster — project, region, provider, status — appears in the same unified inventory as your AWS RDS and GCP Cloud SQL instances. Filter by provider, region, or status.

Step 3 — Connect directly. Select a cluster and connect from the dashboard. The platform reads the collection and field structure automatically on connect.

Step 4 — Ask in plain English. Query1AI reads that schema metadata and turns a plain-English question into a query for the connected database — no hand-written aggregation pipeline required for a straightforward answer.

Where This Actually Helps

One inventory across MongoDB and your relational databases. Before: check Atlas, check AWS or GCP separately, keep the combined picture in a spreadsheet. After: one dashboard, filterable by provider.

Getting an answer without writing an aggregation pipeline. Before: open Data Explorer or mongosh, recall collection/field names, write the query. After: connect the cluster, ask in plain English, get the result.

Letting a non-technical teammate check something directly. Before: the question goes to whoever on the team is comfortable with MongoDB's query language. After: anyone with dashboard access can ask it themselves.

Security Model

Atlas API key scoped to Project Data Access Read Only — no cluster config, user management, or billing access requested
Queries executed through Query1AI are read-only, full stop
The API key is encrypted at rest and never shown again after entry
1DataCloud stores collection/field metadata, not your documents — query results return to your browser session and aren't retained server-side

1DataCloud for MongoDB Atlas

Atlas clusters listed alongside your AWS RDS and GCP Cloud SQL instances in one inventory
Filter by provider, region, or status
Direct connectivity to any cluster from the dashboard
Collection/field metadata loaded automatically on connect
Natural language querying via Query1AI, read-only
One place to look, regardless of which cloud or engine the answer lives in

Free to try, setup in under five minutes.

👉 Connect your MongoDB Atlas account at 1datacloud.ai

Full write-up with FAQ and more detail on the security model: 1datacloud.ai/blog/mongodb-atlas-database-management-without-atlas-ui

Nobody on Your Team Should Need Your AWS Keys Just to See a Database

Abd Alrhman Alloush — Thu, 08 Oct 2026 05:34:09 +0000

Here's a pattern that shows up on almost every multi-cloud team eventually.

An engineer sets up read-only access to the company's databases — an IAM role in AWS, a service account JSON key in GCP, an API key for MongoDB Atlas. It takes some care to get right: scoped permissions, no write access, nothing that touches other cloud services. That part is usually fine, because one person did it once.

The problem starts right after. A new engineer joins and needs to see what's running in staging. A product manager wants to check a table without filing a ticket. A teammate on a different project needs the connection string for a database they don't normally touch.

Now someone has to decide: do we hand out a copy of the credentials, or does everything keep routing through the one person who has them?

Neither answer is good.

The Credential-Sharing Trap

Copying IAM keys or service account files around a team is a well-known anti-pattern, and most engineers already know why:

There's no way to revoke access for one person. If a teammate leaves or changes teams, you either rotate the credential for everyone or you leave it live.
There's no record of who actually used it. A shared key doesn't tell you who ran what — it's one identity for however many people have the file.
It spreads. Once a credential lives in a Slack DM or a shared .env file, you've already lost track of every place it exists.

So teams default to the other option: route everything through whoever originally set up the connection. That person becomes a bottleneck for anything database-related, which defeats the entire point of giving the team visibility in the first place.

Neither of these is a credentials problem, really. It's an access-model problem — cloud IAM was built to control who can touch AWS or GCP resources, not to control who on your team can look at a schema or run a read-only query.

What Actually Fixes This

The fix isn't a better way to share secrets. It's not needing to share them at all.

When we built 1DataCloud, this is why the credential and the team access are two completely separate layers:

One person connects the account. An engineer adds the AWS IAM role, the GCP service account, or the Atlas API key exactly once, directly to 1DataCloud. The credential lives in one place.

The organization controls who sees what's connected. Access from there is managed at the team level — only people who've been added to your 1DataCloud organization can see or query the databases that organization has connected. Adding a new teammate means adding them to the org, not minting or copying a cloud credential.

Nobody downstream ever touches the credential. A teammate who's been added to the org opens the dashboard, sees the databases already connected, and works with them directly — they never see the IAM role, the service account file, the connection string, or the AWS or GCP console itself.

That's the whole shift: the cloud credential answers "can this platform read this database," once. The organization membership answers "can this person use it," separately, and that's the part that actually changes as your team changes.

What This Looks Like Day to Day

Onboarding a new engineer stops being "here's a shared key, don't lose it" and becomes "you're added to the organization" — they get the same view everyone else has, with nothing to configure and no secret to hand over.

Offboarding is the same operation in reverse: remove them from the organization and their access to every connected database goes with it, without touching the underlying AWS or GCP credential at all.

A non-technical teammate — a PM, an analyst, a support lead — can be added to the organization and use Query1AI to ask questions in plain English against a database's already-mapped schema. They get answers. They never see a connection string, a table name, or a console, because none of that was ever something they needed in the first place.

The engineer who set up the connection stops being the only path to the data. They did the IAM work once; everyone else works through the organization, not through them.

Why This Matters More as You Add Clouds

This gets more important, not less, the more providers you're running. An AWS IAM role, a GCP service account, and an Atlas API key are three different credential formats with three different rotation and permission models. Asking every teammate who needs visibility to understand and safely hold copies of all three doesn't scale past a couple of people.

Separating "who holds the cloud credential" from "who can use the data" means that distinction only has to be solved once, by the person connecting the account — not re-solved for every engineer, PM, or analyst who needs to look at something afterward.

The Short Version

If your current process for giving a teammate database visibility involves sending them a key, a .env file, or a console login, that's the part worth fixing — not by finding a better way to send secrets, but by not needing to send them at all.

Connect the account once. Add people to the organization, not to the credential.

👉 1datacloud.ai

How does your team currently handle this — shared credentials, a secrets manager, something else? Curious how much of this is already solved vs. still painful.

What I Got Wrong Building a Multi-Cloud Database Tool

Abd Alrhman Alloush — Thu, 01 Oct 2026 06:07:52 +0000

A while back I introduced myself here with the standard founder-story framing: decades running databases, saw the same problem everywhere, decided to build the fix. All true. What I left out is everything I got wrong once I actually started building it -- so here's the part I skipped.

I underestimated how different "connect your cloud" actually is per provider

The pitch sounds simple: connect AWS, connect GCP, connect MongoDB Atlas, see everything in one place. The pitch does not mention that each provider's credential model is a completely different mental object.

AWS gives you IAM roles and access keys -- account-scoped by default, one policy document, reasonably familiar if you've touched AWS before. GCP gives you service accounts that are project-scoped, authenticated with a JSON key instead of a password, where the same "viewer" role has to be granted separately in every single project you want visibility into. Atlas has its own API-key-and-project-scoping model that resembles neither of the other two.

I budgeted a few weeks to build "cloud connectors." It took a full quarter longer than planned, almost entirely because every provider needed its own permission model documented, tested, and explained to users who'd only ever worked deeply in one cloud. The connectors themselves were the easy part. Teaching people (and our own onboarding docs) what a least-privilege read-only credential looks like on three different platforms was the actual work.

I had the build order backwards at first

The early plan was to ship the natural-language querying piece -- what became Query1AI -- as the headline feature, with the unified inventory as a supporting dashboard around it.

That ordering doesn't work, and it took an embarrassing amount of time to admit it. Query1AI turns a plain-English question into SQL by reading schema metadata -- table names, column names, relationships -- that has to already be mapped before any question can be answered correctly. Without the inventory and schema-discovery layer built and working first, there's nothing for the natural-language layer to ground itself in. It's not two features that happen to pair well together; one is a strict prerequisite for the other. I rebuilt the roadmap around that dependency instead of around which feature looked more impressive in a demo.

"No agents" was the right call, and also the hardest sentence to say out loud

Read-only, API-based, nothing installed on a database node -- that was non-negotiable from day one, because I'd spent too many years cleaning up after agents and sidecars that someone forgot about, that broke on an OS upgrade, or that a security review flagged as an unexplained process with database access.

What I didn't expect: how often that constraint sounds like a weaker pitch in a first conversation. An agent-based competitor can promise deeper metrics, finer-grained monitoring, more knobs. We can't match that list, because matching it would mean breaking the constraint. The lesson wasn't to second-guess the decision -- it's held up. The lesson was to stop trying to win that feature comparison and instead lead with what the constraint actually buys: nothing to deploy, nothing to patch, nothing running on infrastructure we don't own the risk for.

Azure demand showed up faster than the honest answer could

AWS and GCP covered the large majority of early conversations. Then enterprise prospects started asking about Azure sooner than the roadmap had room for it -- a Microsoft-shop acquisition here, a data-residency requirement there.

The tempting move is to say "yes, supported" and scramble to catch up quietly. We didn't do that, and I'd make the same call again: Azure is still in active development, and every piece of content and every conversation says exactly that instead of implying otherwise. It has cost some deals that wanted all three clouds on day one. It's also meant nobody who signed up based on what we said felt misled by what they got. Given the choice again, I'd rather lose the deal that needed something we hadn't built yet than win it on a sentence that wasn out true at the time.

The non-technical side wasn't a stretch feature, it was half the point

I originally scoped this as a tool for DBAs and platform engineers -- people like the one I used to be. Non-technical, self-service access via plain-English questions was on the roadmap, but mentally filed as a secondary audience.

It wasn't secondary. Once the inventory and schema mapping existed, the question "can a PM or a support lead just ask this in English and get a real answer" turned out to matter as much as anything built for engineers -- because the ticket queue of "can someone pull me a number" is exactly the tax non-technical teams pay today, and it's one of the clearest places read-only, schema-aware querying actually removes work instead of just moving it around.

What this adds up to

None of these were catastrophic mistakes -- nothing got rebuilt from scratch, nothing shipped and had to be pulled. They were sequencing and communication mistakes: underestimating the unglamorous work of credential models, getting the dependency order backwards, undervaluing a constraint I was already committed to, and being too slow to take a growing audience seriously. The common thread is that the actual engineering judgment calls -- read-only by default, no agents, say what's not ready yet -- all held up fine. It was the plan built around them that needed the corrections.

If you've built something in a space you used to work in professionally, I'm curious what you got wrong going in versus what you expected to get wrong. The gap between those two lists is usually the interesting part.

How GCP Service Accounts Work: A Practical Guide for DBAs New to GCP

Abd Alrhman Alloush — Fri, 25 Sep 2026 15:16:52 +0000

If you've spent years in AWS and now find yourself connecting to a GCP project for the first time, service accounts are usually the first thing that trips people up.

They look like IAM roles. They aren't quite IAM roles. And the defaults GCP nudges you toward — a JSON key with broad project access — are almost never what you actually want for something like database connectivity.

Here's what a service account actually is, how the permission model works, and how to scope one down to exactly what a tool (or a person) needs to read your Cloud SQL or Spanner instances — nothing more.

What a service account actually is

A GCP service account is an identity, not a person's login. It's meant for a program, a script, or a third-party platform to authenticate as — the equivalent of an AWS IAM role, but with a few structural differences that matter in practice:

It has its own email-like identifier (something@project-id.iam.gserviceaccount.com), and you grant it IAM roles the same way you'd grant a human user roles.
It authenticates with a key, not a password. Usually a JSON key file you generate and download once, or short-lived credentials if you're running inside GCP already (a GKE pod, a Compute Engine VM).
It's scoped to a project by default, which is the detail that catches people coming from AWS's account-wide IAM model off guard — see below.

The JSON key is the part to treat carefully. Anyone who has that file can authenticate as the service account until you rotate or revoke it. Unlike an AWS access key pair, there's no secondary secret — the whole file is the credential.

The permission model: roles, not policies

AWS IAM policies are JSON documents you write by hand, attaching specific actions and resources. GCP's model is role-based: you pick predefined roles (or build a custom one) and grant them to the service account, scoped to a project, folder, or individual resource.

For anything touching a database, three roles come up constantly:

roles/cloudsql.viewer   — read instance metadata (engine, region, tier, status)
roles/cloudsql.client   — permission to connect to Cloud SQL instances
roles/spanner.viewer    — read Spanner instance metadata

Notice what's missing: nothing here grants the ability to create, modify, or delete an instance, and nothing grants write access to the data inside one. That's on purpose — cloudsql.client lets a service account connect, it doesn't touch data or schema by itself. Whatever connects using that credential still needs its own database-level permissions (a MySQL user, a Postgres role) to actually run queries once connected, and those should be read-only too if that's all the use case calls for.

The mistake people make here isn't malicious — it's convenience. roles/cloudsql.admin or, worse, roles/editor at the project level "just works" on the first try, so it's what ends up in a lot of scripts and internal tools. It also means that JSON key, if it ever leaks, can modify or delete infrastructure — not just read it.

Project scoping: the thing that's different from AWS

In AWS, one set of IAM credentials can usually see an entire account — all regions, all services, unless you've written a policy that restricts it. GCP inverts this: everything lives inside a project, and a service account only has the roles you've explicitly granted in that project (or inherited from a folder/org above it).

This is good for isolation — a compromised service account in a staging project can't touch production by default. It's bad for visibility: if your Cloud SQL instances are spread across five projects (production, staging, three regional projects), you need that service account's roles granted in every one of them, or you'll get an incomplete picture and no error telling you why.

This is the exact gap that shows up when teams try to build their own "list every database we have" script — it works fine until someone spins up a sixth project and the discovery script silently stops covering it.

Generating and handling the key

The mechanics are simple; the discipline around them is where most of the risk actually lives:

In the GCP Console, go to IAM & Admin → Service Accounts, create one, and grant it only the roles it needs (start from cloudsql.viewer and cloudsql.client, add more only if something concrete requires it).
Generate a key under the Keys tab — this downloads a JSON file. This is the only time you'll see the private key in plaintext.
Store it in a secrets manager, not a repo, not a Slack message, not a shared drive folder. Treat it the way you'd treat an AWS access key with production read access, because functionally that's what it is.
Set a reminder to rotate it. GCP doesn't force key rotation on you, which means it's easy to have a two-year-old key nobody remembers issuing.

If you're running the workload inside GCP itself (Compute Engine, GKE, Cloud Run), skip the JSON key entirely and attach the service account directly to the resource — you get short-lived, automatically rotated credentials instead of a static file to protect.

Applying this to database access specifically

For read-only database inventory and querying — which is the common case for any tool that needs to see what Cloud SQL or Spanner instances exist and connect to them — the minimum viable service account looks like this:

roles/cloudsql.viewer and roles/cloudsql.client for Cloud SQL
roles/spanner.viewer for Spanner, if you're using it
Granted at the project level, repeated for every project you need visibility into
No editor, no owner, no cloudsql.admin

That's the same scoping model 1DataCloud asks for when you connect a GCP project — a service account JSON limited to those viewer and client roles, nothing that can create, modify, or delete an instance. It's a useful baseline to hold any tool to, including ones you build in-house: if a script only needs to read instance metadata and connect for querying, its service account should never be able to do more than that.

The short version

A service account is an identity for machines, authenticated by a key instead of a password — protect the key like a production credential, because it is one.
Grant specific roles (cloudsql.viewer, cloudsql.client, spanner.viewer), never editor or admin, for anything that only needs to read and connect.
Remember that GCP's permissions are project-scoped — a service account needs to be granted in every project you want it to see, unlike AWS's account-wide default.
Rotate keys on a schedule, since GCP won't do it for you.

Get the scoping right once, and every tool you point at your GCP databases afterward — whether it's a script you wrote or something you connect — inherits the same minimal blast radius.

Coming from AWS to GCP and hit a permissions surprise I didn't cover here? Drop it in the comments — curious what else trips people up in that transition.

Self-Service Database Access for Non-Technical Teams

Abd Alrhman Alloush — Mon, 21 Sep 2026 08:38:00 +0000

Self-Service Database Access for Non-Technical Teams

Here is a scenario that plays out in almost every engineering team, every single week.

A product manager needs to know how many users completed onboarding last month. A sales lead wants to know which enterprise customers haven't logged in for 30 days. A CEO asks for a quick revenue breakdown before a board meeting.

In each case, the answer lives in a database. In each case, getting that answer requires someone who knows SQL, knows the schema, and has the right credentials to run the query. That person is usually an engineer in the middle of something else.

The engineer stops. Opens a SQL client. Writes the query. Sends the result. Fifteen to twenty minutes later, both people are behind on what they were actually doing.

This is not a data problem. It's an access problem. The data exists. The bottleneck is the interface between the people who need answers and the systems that have them.

Why Non-Technical Teams Can't Access Databases Directly (Today)

There are three legitimate reasons why most organizations don't give non-technical staff direct database access:

1. SQL is a hard prerequisite

Querying a relational database requires knowing SQL syntax — and not just generic SQL. You need to know this specific database's table names, column names, data types, and join relationships. Even experienced SQL writers slow down in unfamiliar schemas.

For someone who doesn't write code, the barrier is essentially total. They physically cannot get the data themselves, regardless of how clear the question is in their head.

2. Direct database access is a security risk

Giving non-technical users raw database credentials introduces real risk:

Accidental write operations (UPDATE or DELETE sent when they meant SELECT)
Credentials shared over email or Slack
No audit trail for who ran what
Potential exposure of sensitive columns (PII, payment data)

These concerns are valid. But they're also arguments for a better interface — not arguments for denying data access entirely.

3. Schema complexity doesn't translate to non-technical intuition

Even if someone had SQL knowledge, most production database schemas are not self-explanatory. Tables have abbreviated names. Columns have non-obvious meanings. Relationships between tables are implied by foreign keys that no one documents.

Reading a production schema without context is like reading source code without comments — technically possible for an expert, completely opaque for everyone else.

What Self-Service Database Access Actually Means

Self-service database access means that any member of your team — regardless of their technical background — can get answers from your databases directly, without involving an engineer, without knowing SQL, and without any risk of accidentally modifying the data.

The key ingredients:

Natural language as the interface
The user types a question in plain English — the same way they'd ask a colleague. The system translates that question into the correct query and executes it. No SQL required.

Schema awareness built in
The system already knows your database structure. The user doesn't need to know table names or column names. They just ask what they want to know.

Read-only by design
Self-service access is read-only. The system can only run SELECT queries. No matter what a non-technical user types, it is physically impossible for them to modify, delete, or corrupt any data.

Results in a format anyone understands
Results come back as a clear table or an automatically generated chart. No raw data dumps, no CSV that requires further processing — just the answer, ready to share.

The Business Case: What the Bottleneck Actually Costs

Let's put a number on the problem.

Assume your team handles 10 ad-hoc data requests per week from non-technical stakeholders. Each request takes an engineer an average of 20 minutes — finding the right database, writing the query, formatting the result, sending it back.

That's 200 minutes of senior engineering time per week — roughly 3.3 hours — spent on work that adds no technical value and could be completely self-served.

Over a year, that's over 170 hours of engineering time spent playing data retrieval assistant.

Beyond the cost: stakeholders are waiting hours or days for data they could have in seconds. Decisions get delayed. Reports get assembled manually. The same questions get asked and answered repeatedly with no institutional memory.

Self-service access eliminates this entirely. The engineer never gets the interrupt. The stakeholder gets the answer immediately.

What Changes With Self-Service Access in Practice

For product managers

A product manager preparing for a sprint review can check: active users this week, feature adoption rates, conversion from trial to paid — all without waiting for an engineer. They prepare better, they present faster, and they don't burn engineering time on reporting tasks.

For sales teams

A sales rep who wants to know which customers are showing low engagement — sessions declining, features unused — can check directly before a renewal call. They personalize the conversation using real data, without pulling in a data analyst.

For executives

A CEO or department head who wants a quick read on a business metric before a meeting can get it themselves in 30 seconds. Not through a static dashboard that may be stale — directly from the live database, with a fresh query.

For operations teams

Operations staff who need to check order status, support ticket volume, or inventory counts can do so without creating engineering tickets. The operational workflow speeds up. The engineering team stays focused.

The Security Model That Makes This Safe

Self-service access doesn't mean unrestricted access. A well-designed system enforces strict boundaries:

Control	How It Works
Read-only enforcement	Only SELECT queries are generated and executed. INSERT, UPDATE, DELETE, and DDL are blocked at the system level — not just by convention.
No raw credential exposure	Users access the database through the platform. They never see connection strings, passwords, or cloud credentials.
Query audit trail	Every query executed is logged — who ran it, when, what was asked, what SQL was generated.
Schema-only context	The AI works from table and column names, types, and relationships — never your actual data. Raw records are never sent to or stored by the AI.
Organization-level access control	Access is managed at the team level. Only users added to your organization can query connected databases.

This model gives non-technical users meaningful data access while maintaining the security posture your team requires.

How 1DataCloud Enables Self-Service Database Access

1DataCloud's Query1AI is designed specifically for this use case. Here's how it works for a non-technical team member:

They log into the 1DataCloud dashboard (no cloud console, no database client)
They see the databases their organization has connected (they never see credentials or configuration)
They click the database relevant to their question
They type their question in plain English: "How many users signed up this week by country?"
Query1AI generates the SQL, executes it read-only, and returns the result as a table or chart
They export to CSV or share the chart

The engineer who set up the connection never gets interrupted. The data is live and accurate. The result is in the stakeholder's hands in under a minute.

What the non-technical user never sees or needs:

The SQL query
The database credentials
The table names or schema
The AWS or GCP console

What they do get:

Their answer
A chart if the data supports it
A CSV if they need to share it

Frequently Asked Questions

Is it safe to let non-technical users query production databases?

Yes — when the interface enforces read-only access at the system level. Query1AI generates and executes only SELECT statements. It is architecturally impossible for a user to modify, delete, or corrupt data through the platform, regardless of what they type.

What if a user asks a question the AI can't answer accurately?

The system shows the generated SQL alongside the result. If a result seems unexpected, the user can share the SQL with an engineer for review. The transparency of the generated query is a feature, not a complication.

Do non-technical users need to understand the database schema?

No. Query1AI reads the schema when the database is connected, and uses that knowledge to generate accurate queries. Users just describe what they want to know — the system handles the translation.

Can we restrict which tables non-technical users can access?

Access is controlled at the connection level today: your team only sees the databases you've connected, and anyone querying a connection works from that database's full schema. There's no per-column or per-table masking yet — if a database has tables non-technical staff shouldn't touch, keep it on a separate connection your organization doesn't expose to them.

How is this different from a BI tool like Tableau or Looker?

BI tools require data to be modeled and prepared by a data engineer before it becomes queryable by business users — a setup process that can take weeks or months. Query1AI works directly against your existing database structure, with no data modeling required. The tradeoff is that BI tools offer more sophisticated visualization and report-building; Query1AI prioritizes instant, zero-setup access.

The Bottom Line

Every ad-hoc data request that goes through an engineer is a tax on your team's velocity. The question is not whether non-technical staff should have data access — they need it to do their jobs. The question is what the interface should look like.

Natural language querying with strict read-only enforcement is the answer: non-technical users get fast, self-serve access to real data; engineers stop being interrupted for reporting tasks; and the security model remains intact.

How does your team currently handle ad-hoc data requests from non-technical stakeholders — a shared BI tool, a Slack-and-hope process, or an engineer on rotation? Curious what's actually working for other teams.

Abd Alrhman Alloush is the Founder of 1DataCloud — a unified dashboard for managing and querying databases across AWS, GCP, and MongoDB Atlas, plus Query1AI for natural-language querying.

Stop Switching Between AWS Console, GCP Console, and DBeaver

Abd Alrhman Alloush — Fri, 18 Sep 2026 06:05:36 +0000

If you manage databases across AWS and GCP, your daily routine probably looks something like this:

Open AWS Console → navigate to RDS → find the instance you want
Realize it's actually on GCP → open GCP Console → navigate to Cloud SQL
Need to inspect the schema → open DBeaver, find the right connection profile, connect
Your colleague asks about a MongoDB Atlas cluster → open a fourth tab

By the time you've found what you need, you've spent 10 minutes just navigating, before doing any actual work.

This is console fatigue. And it's quietly burning hours every week across every DevOps and platform team running multi-cloud infrastructure.

TL;DR

We built 1DataCloud — a unified dashboard that connects AWS, GCP, MongoDB Atlas, and on-prem databases in one place. No agents. No scripts. Just connect your IAM role or service account and see everything. Try it free →

The Real Cost of Console Switching

It's not just the time. It's the context-switching tax.

Every time you jump between AWS Console, GCP Console, DBeaver, and MongoDB Atlas, you lose the thread. You forget what you were looking for. You miss something. You open another ticket to ask someone who "knows where that database lives."

Here's what a typical multi-cloud team is actually dealing with:

No single inventory. There's no one place that lists every database instance across all your accounts and providers. AWS has its own view. GCP has its own view. Atlas is entirely separate.
No unified metadata. Want to know the engine version, region, instance class, and connection count for all your RDS and Cloud SQL instances at once? You're running queries manually across multiple consoles.
No shared context. When a new engineer joins, how do they know what databases exist? They get a tour. Or they find out by asking around. Or they discover something exists when it breaks.

This gets worse as your infrastructure scales. More accounts, more regions, more engines — and the problem compounds.

What a Unified Dashboard Actually Looks Like

When we set out to build 1DataCloud, the goal was simple: one place to see everything, without installing anything on your database nodes.

Here's what it gives you:

One inventory across all clouds

Connect your AWS account (via IAM role or access key), your GCP project (via service account), MongoDB Atlas (via API key), or an on-prem database (via connection string). 1DataCloud discovers all your supported instances automatically.

You end up with a single list showing every database across every provider — engine type, region, size, status, configuration — in one view.

AWS us-east-1    |  prod-mysql-rds       |  MySQL 8.0   |  db.r6g.large   |  running
AWS eu-west-1    |  analytics-redshift   |  Redshift     |  ra3.xlplus     |  running
GCP us-central1  |  orders-cloud-sql     |  PostgreSQL   |  db-n1-std-4    |  running
GCP asia-east1   |  spanner-prod         |  Spanner      |  —              |  running
Atlas            |  user-data-cluster    |  MongoDB 7.0  |  M30            |  running
On-prem          |  legacy-mysql         |  MySQL 5.7    |  —              |  running

Auto-discovery — connect once, see everything

You don't have to manually add each instance. Connect the account, and 1DataCloud discovers what's there. New instances show up automatically.

Filter and group by cloud provider, region, engine type, or tags. Useful when you need to answer "how many PostgreSQL instances are we running in eu-west-1 across all providers?"

Schema exploration without DBeaver

Click any instance and you can browse its tables, columns, data types, indexes, and relationships — all fetched read-only through the cloud API. No need to open a separate DB client, manage connection profiles, or handle VPN tunneling just to look at a schema.

No agents. No installation.

This was a hard requirement for us. We didn't want to ask DevOps teams to deploy anything on their database nodes or set up sidecar processes. Everything is read-only and API-based. If you have an IAM role for RDS, you're already set up.

Who This Actually Helps

DBAs — stop juggling multiple consoles just to answer "what's running and where."

Platform/DevOps engineers — onboard new databases in minutes, not days. No agents, no scripts, nothing to maintain.

Engineering managers — shared visibility without creating a bottleneck. Anyone on the team can see the inventory.

New engineers — instead of a tribal knowledge tour, they open the dashboard and see everything that exists.

The Setup

Connecting takes about 2 minutes:

Sign up at dashboard.1datacloud.ai
Add your AWS access key or IAM role, GCP service account, Atlas API key, or on-prem connection string
1DataCloud fetches your instances and shows them in the unified inventory

That's it. No configuration files. No agents. No infrastructure changes.

What's Next

The dashboard is the foundation. Once you have a single inventory with schema metadata, you can do more with it — like querying any database in plain English using Query1AI, which generates SQL automatically from your question and executes it read-only.

But that's a separate post.

If your team is managing databases across more than one cloud and you're tired of the console maze, give 1DataCloud a try. It's free to start.

👉 1datacloud.ai

Have a multi-cloud database setup that's particularly painful to manage? Drop it in the comments — genuinely curious what patterns you're dealing with.

GCP Cloud SQL Management Without the Google Console

Abd Alrhman Alloush — Mon, 14 Sep 2026 17:07:54 +0000

The Google Cloud Console is one of the more thoughtfully designed cloud management interfaces available. Compared to some of its peers, it's clean, well-organized, and relatively fast.

It's also not the right tool for day-to-day database management at scale.

If your team runs Cloud SQL instances across multiple GCP projects — or runs Cloud SQL alongside Cloud Spanner, AWS RDS, or on-premise databases — the GCP Console creates the same fragmentation problem that every cloud-native console creates: it shows you only what lives inside that one context, and getting a complete picture of your database infrastructure requires stitching together multiple views across multiple projects and providers.

This guide covers where the GCP Console falls short for database management, what an effective GCP Cloud SQL workflow looks like, and how teams are improving their Cloud SQL management today.

Where the GCP Console Falls Short for Cloud SQL Management

No cross-project database inventory

GCP organizes resources by project. If your organization uses separate projects for production, staging, and development — which is the recommended GCP architecture — your Cloud SQL instances are scattered across those projects.

The GCP Console has no view that shows you every Cloud SQL instance across all your projects at once. Getting that answer requires navigating to each project separately, opening SQL in each one, and mentally or manually compiling the list.

For teams with 5+ projects, this is a real daily friction point. For teams managing Cloud SQL alongside other cloud providers, it becomes untenable.

Context-switching between management and querying

The GCP Console lets you view and configure Cloud SQL instances. It has a built-in query editor (Cloud SQL Studio) that you can use for basic SQL execution. But the workflow is fragmented: you manage instances in one part of the console, you query in another, and the interface is optimized for administration tasks rather than fast, daily querying.

More importantly, Cloud SQL Studio only works with Cloud SQL. If your organization also runs Cloud Spanner, AWS RDS, or any other database engine, you're back to maintaining separate tools for each.

Service Account management complexity

Connecting to Cloud SQL securely — especially from external tools — requires configuring a Service Account with the correct IAM roles, downloading a JSON key, and often setting up the Cloud SQL Auth Proxy for private instances.

This is the right architecture for production security. But it creates real friction for teams who want to iterate quickly or onboard new engineers to existing infrastructure. Getting a new team member connected to a Cloud SQL instance for the first time is not a five-minute task.

Schema exploration is manual

Once you're in Cloud SQL Studio, exploring your database schema still requires manual effort: run SHOW TABLES;, then DESCRIBE table_name; for each table you want to understand. For complex databases with dozens or hundreds of tables, building a mental model of the schema takes significant time.

A Better Workflow for GCP Cloud SQL Management

Here's what effective Cloud SQL management looks like with the right tooling:

Step 1 — Connect your GCP account once

Provide a GCP Service Account JSON with read-only permissions — specifically roles/cloudsql.viewer and roles/spanner.viewer. The platform uses the GCP API to discover every Cloud SQL and Cloud Spanner instance across all your projects automatically. No manual project-by-project browsing.

Step 2 — View your complete GCP database inventory

Every Cloud SQL instance — across every project, region, and database engine — appears in a single list. Instance name, project, region, database version, tier, disk size, status, and connection name. Filter by project, region, or status. Engine and version are shown right in the table, so you can scan for what you need at a glance.

Step 3 — Connect to any instance directly

Select an instance and connect to it — no Auth Proxy to configure, no separate client to open. The platform handles the connectivity. Once connected, your full schema is loaded automatically: every table, every column, every data type.

Step 4 — Query in plain English or SQL

Ask your question in plain English. The AI reads your actual schema — your real table and column names — and generates correct MySQL or PostgreSQL syntax for your specific instance. Execute read-only, get results as a table or chart, export to CSV.

Supported GCP Database Services

Google Cloud SQL

Cloud SQL is GCP's fully managed relational database service. 1DataCloud supports all three Cloud SQL engines:

Engine	Version Support	Common Use Cases
MySQL	5.7, 8.0	Web applications, CMS, legacy migration
PostgreSQL	12, 13, 14, 15	Modern SaaS, analytics, PostGIS
SQL Server	2017, 2019	Enterprise applications, .NET workloads

Google Cloud Spanner

Cloud Spanner is GCP's globally distributed, horizontally scalable relational database — designed for applications that need strong consistency across regions. Managing Spanner instances and querying Spanner databases is supported alongside Cloud SQL in a unified view.

Coming Soon

BigQuery: GCP's serverless data warehouse. Natural language querying for BigQuery tables is on the roadmap.
Firestore: Document database support is planned.

Common GCP Cloud SQL Use Cases This Solves

Use case 1: Cross-project database audit

Before: Log into the GCP Console → navigate to each project → open SQL → note instance states and configurations → repeat for each project → compile manually.

After: Open your unified dashboard → every Cloud SQL instance across every project is listed automatically → filter by project or status → done in 30 seconds.

Use case 2: Querying a Cloud SQL instance without the Auth Proxy

Before: Configure Cloud SQL Auth Proxy → install gcloud CLI → authenticate → start proxy → open a separate SQL client → configure connection → connect → write SQL from memory.

After: Select the Cloud SQL instance in the dashboard → connect directly → ask your question in plain English → results back as a chart.

Use case 3: Onboarding a new engineer to GCP infrastructure

Before: Share Service Account credentials → walk through each project → explain which instances exist → hand over schema documentation → wait while they set up Cloud SQL Studio or a local client.

After: Add them to the 1DataCloud organization → every instance is visible → they can connect and explore schemas by asking questions immediately.

Use case 4: Multi-cloud inventory (GCP + AWS)

Before: GCP Console for Cloud SQL instances, AWS Console for RDS instances — two separate workflows with no unified view.

After: Both appear in the same dashboard. Filter by provider. Query any database — Cloud SQL, Cloud Spanner, AWS RDS, MongoDB — from the same interface.

This last use case is where GCP-specific tools hit their ceiling. If you run any workloads outside GCP, a GCP-only tool solves half the problem.

Security Model for GCP Cloud SQL

Connecting a third-party platform to your Cloud SQL instances requires careful consideration. Here's the security model that matters:

Minimum required IAM permissions

The Service Account used by 1DataCloud requires only:

roles/cloudsql.viewer         — read instance metadata
roles/cloudsql.client         — connect to instances for querying
roles/spanner.viewer          — read Spanner instance metadata

No write permissions. No admin roles. No access to other GCP services.

Read-only query execution

All queries executed through Query1AI are strictly read-only. The platform generates and executes only SELECT statements — never INSERT, UPDATE, DELETE, DROP, or any DDL operation. This is enforced at the application level.

Encrypted credential storage

Your Service Account JSON is encrypted at rest using industry-standard encryption. It is never exposed in the UI, never logged, and never transmitted outside the platform's secure environment.

No data storage

1DataCloud stores only metadata — table names, column names, data types. Your actual database contents are never stored, cached, or replicated by the platform. Query results are returned to your browser session and are not persisted server-side.

GCP Cloud SQL vs Cloud Spanner: Managing Both in One Place

Teams running workloads on GCP often use both Cloud SQL and Cloud Spanner — Cloud SQL for standard relational workloads and Spanner for applications requiring global distribution and horizontal scaling.

Managing both through the GCP Console means navigating separate service pages, with different configuration models and different query syntaxes (standard SQL for Cloud SQL vs Spanner SQL with its own specifics).

1DataCloud shows both Cloud SQL and Cloud Spanner instances in the same inventory view. You can connect to either and query both using plain English — the AI handles the syntax differences between MySQL, PostgreSQL, and Spanner SQL automatically.

1DataCloud for GCP Cloud SQL Management

1DataCloud connects to your GCP account using a Service Account JSON and automatically discovers every Cloud SQL and Cloud Spanner instance across all your projects.

What you get:

Complete Cloud SQL + Spanner inventory across all GCP projects in one view
Filter by project, region, or status
Direct database connectivity — no Auth Proxy setup required
Full schema metadata loaded automatically on connect
Natural language querying via Query1AI — works with MySQL, PostgreSQL, and Spanner SQL
Results as tables or charts, exportable to CSV
Unified view alongside AWS RDS, MongoDB Atlas, and on-premise databases

Free to try. Setup in under five minutes.

👉 Connect your GCP account at 1datacloud.ai

Frequently Asked Questions

What GCP permissions does 1DataCloud require?

Read-only IAM roles: roles/cloudsql.viewer, roles/cloudsql.client (for connecting to instances), and roles/spanner.viewer. No write or admin permissions are required.

Does it work with private Cloud SQL instances (no public IP)?

For instances without a public IP, direct connectivity requires the Cloud SQL Auth Proxy or a network path to the instance. Metadata discovery (inventory) works regardless via the GCP API.

Can I connect multiple GCP projects?

Yes — all projects associated with the Service Account are discovered automatically. Instances from all projects appear in the same unified inventory view.

Does it support Cloud Spanner?

Yes. Cloud Spanner instances are discovered alongside Cloud SQL instances. You can connect to Spanner databases and query them in plain English — Query1AI generates correct Spanner SQL syntax.

Is the Service Account JSON stored securely?

Yes. It is encrypted at rest and never exposed in the UI or logs. You can revoke the Service Account at any time from the GCP Console to immediately remove the platform's access.

Can I use this alongside my AWS databases?

Yes — this is one of the primary use cases. Add both your GCP Service Account and your AWS IAM credentials, and all instances from both providers appear in the same unified dashboard.

Summary

The GCP Console is the right tool for provisioning, configuring, and administering Cloud SQL instances. It is not the right tool for the daily workflow of managing, inventorying, and querying those databases at speed — especially when your infrastructure spans multiple GCP projects, or when you also run databases on AWS or other providers.

The gap is filled by a unified dashboard that connects to your GCP account, discovers every Cloud SQL and Spanner instance automatically, handles connectivity without requiring the Auth Proxy, and lets your entire team query those databases in plain English — without switching tools, without writing SQL from memory, and without navigating the GCP Console for answers.

Connect your GCP account free at 1datacloud.ai — your Cloud SQL inventory is ready in under five minutes.

Schema Drift: Why Your Database Docs Are Always Wrong

Abd Alrhman Alloush — Thu, 10 Sep 2026 05:52:48 +0000

Every team has a database schema doc somewhere — a wiki page, a Notion doc, a diagram someone exported from a tool three quarters ago. And every team has the same unspoken rule about it: don't fully trust it.

TL;DR

Schema documentation goes stale the moment someone ships a migration without updating it — which is most migrations, most of the time. 1DataCloud doesn't try to fix the discipline problem. It sidesteps it: the schema map is read from your actual database each time you connect and sync, not maintained by hand. Try it free →

The Doc Was Right the Day Someone Wrote It

Schema docs aren't wrong because someone was careless. They're wrong because they're a snapshot, and the database is not.

Someone adds a deleted_at column for soft deletes. Someone renames user_id to account_id halfway through a refactor and updates every reference except the wiki. A migration adds three tables for a feature that shipped and got ripped out four months later, and the tables are still there — just not in anyone's mental model anymore.

None of this is a process failure. It's what happens to any document that describes something which keeps changing, written by people whose actual job is to ship the change, not to update the description of it afterward.

Where This Actually Costs You Time

The failure mode isn't dramatic. It's small and constant:

Onboarding takes longer than it should. A new engineer reads the schema doc, builds a mental model from it, then discovers in code review that the doc was describing a version of the schema from two migrations ago.

Queries fail on names that don't exist anymore. Someone writes a query against a column the doc lists, and it errors out, because that column was renamed six weeks ago and nobody circulated a memo.

Nobody wants to be the one who "owns" the doc. Documentation with a single owner rots the moment that person is busy for a sprint. Documentation with no owner rots immediately.

Cross-team requests get the wrong answer confidently. A product manager or analyst asks an engineer a question, the engineer answers from memory or from the doc, and the answer is wrong because the schema moved since either was last checked.

The Fix Isn't "Try Harder at Docs"

Most teams' response to schema drift is a process fix: assign an owner, add a doc-review step to the PR template, schedule a quarterly audit. These help, briefly. They fail for the same reason the original doc failed — they depend on someone remembering to do a thing that isn't their primary job, every single time, forever.

The alternative isn't a better documentation process. It's not treating the schema as something you describe at all. It's reading it directly, whenever you need it.

What This Looks Like in 1DataCloud

This is the model behind how 1DataCloud's dashboard and Query1AI work.

The schema map isn't hand-maintained — it's read from the database. When you connect an AWS, GCP, or MongoDB Atlas database, 1DataCloud reads the actual tables, columns, data types, and relationships that exist right now. There's no separate document to keep in sync, because there's no separate document — the map comes from the source.

It's re-read on sync, not written once and left. Add a column, drop a table, rename a field — the next sync reflects it. The schema map isn't a point-in-time doc that ages; it's re-derived from the database each time.

Query1AI works from that same live map, not a cached description. When you ask a plain-English question, Query1AI generates SQL against the schema it actually read — the real table names, the real column names — not against whatever the last person to update a wiki page thought the schema looked like.

You can browse it directly, too. If you just want to see what tables and columns exist right now — without asking a question — the mapped schema is browsable in the dashboard. No DESCRIBE loop, no out-of-date ERD.

None of this requires anyone to remember to update anything. The map can't drift from the database, because it isn't a copy of the database's structure — it's read from it.

A Question Worth Asking About Your Own Setup

Next time you open your team's schema documentation, check one thing: does it say when it was last updated, and does that date line up with your most recent migration? If there's a gap of more than a sprint, you're not looking at your schema — you're looking at a plausible guess about your schema from a while ago.

That gap is what schema drift actually costs: not a catastrophic failure, just a slow accumulation of small wrong assumptions that everyone quietly works around.

Try It

1DataCloud is free to start — connect up to 3 instances across AWS, GCP, or MongoDB Atlas, no credit card required, and see your actual current schema instead of last quarter's diagram.

👉 1datacloud.ai
👉 Start free

How does your team currently keep schema documentation in sync — a manual wiki, an auto-generated ERD, or the honest answer of "we don't, we just ask whoever touched it last"?