DEV Community: Abd Alrhman Alloush

Stop Switching Between AWS Console, GCP Console, and DBeaver

Abd Alrhman Alloush — Thu, 30 Jul 2026 11:06:29 +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.

How to Query Your Database in Plain English (No SQL Required)

Abd Alrhman Alloush — Thu, 18 Jun 2026 06:09:21 +0000

Here's a scenario that happens more than it should:

A manager walks up to an engineer and asks: "How many active customers do we have by region?"

The engineer knows the data exists. But answering the question requires:

Remembering which database it's in (or asking)
Recalling the table structure — is it customers, users, or accounts?
Writing the join between two or three tables
Figuring out what "active" means in this schema — is it a boolean column, a status string, or a date range?
Running the query, fixing the syntax error, running it again
Formatting the output

Twenty minutes later, the manager has their answer. The engineer has lost their flow.

This is a solved problem — and the solution is not "make engineers faster at SQL."

TL;DR

Query1AI is a natural language query tool built into 1DataCloud. You ask a question in plain English, it reads your database schema automatically, generates the SQL, and executes it read-only. Results come back as a table or chart. You can export to CSV. Try it free →

How Natural Language Querying Actually Works

The promise of "query your database in plain English" has been around for a while. Most implementations fall short because they generate generic SQL without understanding your specific schema.

Query1AI works differently. Before it generates any SQL, it fetches your actual database schema — table names, column names, data types, indexes, and relationships. It uses that context when generating the query, which means:

It knows your table is called user_accounts, not users
It knows status is an ENUM with values 'active', 'inactive', 'pending'
It knows that orders joins to products via product_id, not item_id

The result is SQL that actually runs against your database, not a template that needs to be corrected.

Real Examples

Here are actual questions you can ask, and what gets generated:

Question: "How many active users do we have by region?"

SELECT region, COUNT(*) AS active_users
FROM user_accounts
WHERE status = 'active'
GROUP BY region
ORDER BY active_users DESC;

Question: "Show me the top 10 products by revenue last month"

SELECT p.product_name, SUM(o.revenue) AS total_revenue
FROM orders o
JOIN products p ON p.id = o.product_id
WHERE o.created_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND o.created_at < DATE_TRUNC('month', CURRENT_DATE)
GROUP BY p.product_name
ORDER BY total_revenue DESC
LIMIT 10;

Question: "Which customers haven't placed an order in the last 90 days?"

SELECT c.id, c.email, c.created_at, MAX(o.created_at) AS last_order_date
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.email, c.created_at
HAVING MAX(o.created_at) < NOW() - INTERVAL '90 days'
   OR MAX(o.created_at) IS NULL
ORDER BY last_order_date ASC NULLS FIRST;

Question: "Give me the average response time per API endpoint for this week"

SELECT endpoint, ROUND(AVG(response_time_ms), 2) AS avg_response_ms,
       COUNT(*) AS request_count
FROM api_logs
WHERE created_at >= DATE_TRUNC('week', CURRENT_DATE)
GROUP BY endpoint
ORDER BY avg_response_ms DESC;

The Workflow in Practice

Here's the actual flow when you use Query1AI:

Step 1 — Connect a database
Pick any instance from your 1DataCloud inventory. Works with MySQL, PostgreSQL, Redshift, BigQuery, Spanner, DynamoDB, and more.

Step 2 — Schema is loaded automatically
Query1AI fetches table names, columns, types, indexes, and relationships. No manual mapping. No configuration.

Step 3 — Ask your question
Type it naturally. You don't need to use SQL syntax, name the tables, or specify the join. Just describe what you want to know.

Step 4 — Review the generated query
Query1AI shows you the SQL before executing. You can inspect it, modify it, or just run it.

Step 5 — Execute and explore
Results come back as a paginated table. Switch to chart view (bar, line, or pie) without leaving the interface. Export to CSV with one click.

Who Gets the Most Value

Developers who know what data should exist but don't want to look up the schema every time they need a quick answer.

DBAs who get asked business questions by non-technical stakeholders all day. Now those stakeholders can answer their own questions.

DevOps engineers who need to pull operational data — running instance counts, error rates, connection metrics — without writing custom scripts.

Managers and data teams who need production data answers but shouldn't need to file a ticket every time they have a question.

What It Won't Do (By Design)

Query1AI is read-only. It will never run INSERT, UPDATE, DELETE, or DDL statements — even if you ask it to. This is intentional. The goal is to give people access to data, not to give them write access to production.

There are also current limitations worth being upfront about:

One database per session today — cross-database querying (asking a question that spans multiple instances) is in active development
Read-only only — if you need to write data, you still need direct database access

The Security Model

Before you connect a production database to anything, you should ask how credentials are handled.

In 1DataCloud:

Credentials are encrypted at rest using Fernet encryption
They are never exposed in the UI or logs
All query execution is read-only — guardrails are enforced at the application layer, not just by trusting the LLM
Nothing is installed on your database nodes

Try It

If you're managing a database that people constantly come to you with questions about, Query1AI is worth trying. It takes about 2 minutes to connect your first database.

👉 1datacloud.ai/queryai

👉 Start free

What questions do you get asked about your database most often? Curious whether Query1AI handles your specific schema patterns — drop them in the comments.

New DBA & Founder joining

Abd Alrhman Alloush — Thu, 18 Jun 2026 05:53:05 +0000

19 Years as a DBA → Building a Product. Hello, DEV Community!
I spent nearly two decades managing databases before deciding to build the tool I always wished existed. Here's my story and what I'll be writing about.

Hey DEV Community 👋

My name is Abd, and I'm genuinely glad to finally be here.

A bit about me

I've spent 19 years working as a Database Administrator — starting at a time when "the cloud" wasn't yet a thing and databases lived in physical racks you could walk up and touch.

Over those years I've worked with pretty much every database engine that matters: MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, Redshift, BigQuery, Spanner — and watched the industry shift from on-prem to hybrid to full cloud and then to "we're on three clouds and nobody planned this."

My last role before going the founder route was Staff Database Engineer — the kind of job where you're not just managing databases but setting the patterns that entire engineering organizations follow.

Along the way I got certified in Data Science from the University of Toronto and the University of Waterloo in Canada, which pushed me to think differently about what databases are actually for — not just storing data, but making it accessible and useful to the people who need it.

Why I decided to build something

After nearly two decades, the problem I kept running into — at every company, at every scale — was the same one:

Nobody actually knows what databases they're running.

Not fully. Not across all their accounts, all their clouds, all their engines. The bigger the company, the worse it got. And when someone needed to query that data, they had to either write SQL from memory or file a ticket and wait.

I tried to solve this internally at every company I worked at. Spreadsheets, internal tooling, wikis. Nothing stuck. Nothing scaled.

So I decided to build it properly.

What I'm building

I'm the Founder & CEO of 1DataCloud — a unified hybrid cloud database management platform.

The short version: one dashboard for all your databases across AWS, GCP, MongoDB Atlas, and on-prem. Connect your cloud credentials, see every instance in one place, then query any of them in plain English using our AI layer called Query1AI — which reads your schema automatically and generates the SQL for you.

No agents. No scripts. Read-only by default. Operational in minutes.

It's the tool I spent 19 years wishing existed.

What I'll be writing about here

I'm planning to post regularly on topics I know well and care about:

Multi-cloud database management — the operational reality of running databases across AWS, GCP, and on-prem simultaneously
AI-powered querying — how natural language → SQL actually works in practice, and where it falls short today
DBA life — lessons from nearly two decades managing production databases (there are some stories)
Founder journey — building a B2B SaaS as a technical founder, what I'm learning, what I got wrong
Cloud database deep dives — RDS vs Cloud SQL, Spanner's consistency model, Redshift gotchas, and more

If any of those topics sound useful, follow along — I'll be posting consistently.

A question for the community

What's the hardest part of managing databases at your current company? Is it visibility across environments, schema drift, slow queries, cross-team access, something else entirely?

I've got 19 years of opinions on this and I'd love to hear where others are struggling — drop it in the comments.

Looking forward to being part of this community properly. 🙏

— Abd

Founder & CEO, 1DataCloud.ai