DEV Community: Abd Alrhman Alloush

Why Your Team Needs a Multi-Cloud Database Inventory

Abd Alrhman Alloush — Thu, 20 Aug 2026 04:25:46 +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.

AWS RDS Management Without Living in the AWS Console

Abd Alrhman Alloush — Tue, 04 Aug 2026 06:35:36 +0000

If you've used the AWS Console to manage RDS instances, you know the drill.

You navigate to RDS, wait for the instance list to load, click into an instance to check its configuration, open another tab to check the parameter group, switch to a different region to find the other instance you were looking for, and by the time you've answered a single question about your database infrastructure, you've spent fifteen minutes navigating a UI that was designed for everything — which means it's optimized for nothing.

Now multiply that by multiple AWS accounts, multiple regions, and a team of engineers all trying to do the same thing.

This post covers why the AWS Console creates friction at scale, what a better workflow looks like, and how teams are managing RDS today without living inside the AWS Console.

The Real Cost of Managing RDS Through the AWS Console

It's built for breadth, not depth

The AWS Console covers hundreds of services. RDS is one of them. As a result, it is designed for occasional, broad use — not for the kind of fast, focused, daily work that DBAs and DevOps engineers actually do.

Finding a specific instance requires knowing which region it's in. Comparing instances across regions requires opening multiple browser tabs. Viewing configuration details, parameter groups, and connection information requires clicking through multiple nested pages per instance.

Multiple accounts compound the problem

Most organizations beyond startup size use multiple AWS accounts — one per environment (dev, staging, production), one per team, or both. The AWS Console has no native cross-account database inventory view. Each account requires a separate login or role switch, and there is no single page that shows you all your RDS instances across all your accounts in one list.

This means the question "what RDS instances do we have, across all our accounts?" has no quick answer in the AWS Console. Getting that answer requires manually checking each account, in each region, and compiling the results somewhere else.

Accessing and querying the database is a completely separate workflow

Even after you've found the instance you're looking for in the RDS Console, you still can't query it from there. You need a separate database client — pgAdmin, MySQL Workbench, DBeaver, or a command-line tool — with its own connection setup, its own credentials, its own interface.

So the full workflow for answering a simple database question looks like this:

Open AWS Console → navigate to RDS → find the right account → find the right region → find the instance
Note the endpoint, port, and engine
Open a separate database client
Configure the connection
Connect to the database
Remember the table names and write a SQL query
Get your answer

Seven steps, multiple tools, and often 20–30 minutes — for a question that should take seconds.

What Effective AWS RDS Management Actually Requires

A single inventory view across all accounts and regions

You should be able to see every RDS instance your organization has deployed — regardless of account or region — in a single list. With filtering by engine type, region, account, status, and instance size. No tab switching. No manual cross-account lookups.

Key configuration details at a glance

For each instance, you need to see immediately: engine and version, instance class, storage type and size, Multi-AZ status, backup configuration, and connection endpoint. Not buried three clicks deep — at a glance.

Fast connectivity to the database itself

Once you've identified the instance you need, getting connected should be one click — not a multi-step process involving a separate tool. The inventory and the query interface should live in the same place.

The ability to query without writing SQL from memory

Once connected, getting answers from the database requires either writing SQL (with full knowledge of the schema) or going through the friction described earlier. Removing this requirement — through natural language querying — changes the daily workflow entirely.

A Better Workflow: From Instance Discovery to Query Results

Step 1 — Connect your AWS account once
Provide your AWS Access Key ID and Secret Access Key. The platform uses the AWS API to discover every RDS instance across all regions on that account — automatically. No manual region-by-region browsing.

Step 2 — View your full RDS inventory in one list
Every instance appears in a single view: engine type, region, instance class, status, and endpoint. Filter by engine (MySQL, PostgreSQL, MariaDB), region, or status. Add multiple AWS accounts and they all appear in the same list.

Step 3 — Connect to any instance directly
Select an instance, provide connection credentials, and connect. No separate database client to open. No connection string to copy. The platform handles the connection from within the interface.

Step 4 — Query in plain English or SQL
Once connected, ask your question in plain English. The AI reads your database schema — your actual table and column names — and generates the correct MySQL or PostgreSQL query for you. Execute it with one click. Results come back as a table or chart. Export to CSV.

The full workflow — from nothing to query results — takes under two minutes. The AWS Console part of that workflow disappears entirely.

Common AWS RDS Use Cases This Solves

Use case 1: Daily RDS inventory check

Old workflow: Log into AWS Console → navigate to each account and region → manually note instance states.

New workflow: Open your unified dashboard → every RDS instance across every account and region is already listed with current status.

Use case 2: Answering a business question from RDS data

Old workflow: Find the RDS instance in the Console → open pgAdmin or MySQL Workbench → configure connection → write SQL from memory → get result → format for sharing.

New workflow: Select the database in the unified dashboard → type the question in plain English → get result as a table or chart → export CSV.

Use case 3: Onboarding a new engineer to existing RDS infrastructure

Old workflow: Walk through each AWS account and region, explain which instances exist, share connection strings and credentials per database, hand over schema documentation.

New workflow: Add them to the unified dashboard. Every instance is visible. They can connect to any database and explore the schema by asking questions — no documentation required.

AWS RDS Engines Supported

When evaluating tools for RDS management, verify support for the specific engines you're running:

Engine	Common Use Cases
MySQL	Web applications, WordPress, legacy systems
PostgreSQL	SaaS platforms, analytics, modern backends
MariaDB	MySQL-compatible workloads
Amazon Aurora MySQL	High-availability MySQL-compatible
Amazon Aurora PostgreSQL	High-availability PostgreSQL-compatible

Beyond RDS, most teams also run Amazon Redshift (data warehousing) and Amazon DynamoDB (NoSQL/key-value). A complete AWS database management solution should handle all of these, not just RDS.

Security Considerations When Using Third-Party RDS Tools

Read-only access only — any tool managing your RDS inventory should require only read permissions on the AWS API, specifically rds:DescribeDBInstances and related read-only calls.

Encrypted credential storage — your AWS Access Keys and database connection credentials must be encrypted at rest.

No data storage — the tool should not store your actual database contents, only metadata. Your data should never leave your AWS environment.

Database-level read-only enforcement — the tool should execute only read-only statements (SELECT), enforced by the tool itself, not just by convention.

Minimal IAM permissions — use a dedicated IAM user or role for the tool with the minimum required permissions.

1DataCloud for AWS RDS Management

1DataCloud connects to your AWS account using your IAM credentials and automatically discovers every RDS instance across all regions — MySQL, PostgreSQL, MariaDB, Redshift, and DynamoDB.

What you get:

Full RDS inventory across all regions in one view
Filter by engine type, region, or status
Connect to any RDS instance and browse its schema
Query any connected database in plain English via Query1AI
Results as tables or charts, exportable to CSV
Add multiple AWS accounts for a single cross-account view
Strictly read-only — your databases are never modified

Setup takes under five minutes. Free to try.

👉 Connect your AWS account at 1datacloud.ai

Have a war story about managing RDS across multiple AWS accounts? Drop it in the comments — curious how other teams are handling it.

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