Best Practices
CMDB
Cloud Infrastructure
Comparisons
Cloud CMDB vs Traditional CMDB: A 2026 Comparison
Traditional CMDBs were built for a world where servers had names. In 2026, your infrastructure doesn't even exist until someone invokes it - and some of it is now a foundation model your team deployed last Tuesday that's burning through compute you can't account for.
That EC2 instance running your Lambda cold start? It lives for 45 seconds. Your Bedrock AI agent? Traditional CMDB discovery has no CI type for it, let alone a way to discover it. And your MID Server doesn't know what an Azure AI Services deployment looks like. The assumptions that made CMDBs valuable in 2006 - permanent infrastructure, scheduled changes, named servers - no longer cover what platform teams are actually managing.
Gartner reports 70-80% of traditional CMDB projects fail to deliver value. The architecture can't handle what cloud infrastructure has become.
Key Differences: Traditional vs. Cloud CMDB #
Traditional CMDB implementations take 2-3 months minimum according to ServiceNow timelines. Full enterprise rollouts take 6-18 months. Getting CloudQuery syncing your AWS account to PostgreSQL takes under an hour. (If you're still evaluating whether a cloud CMDB is the right tool for your situation, What Is a Cloud CMDB? covers the definition and decision criteria.)
Why Do Traditional CMDBs Fail in Cloud Environments? #
Traditional CMDBs were designed around a core assumption: infrastructure is permanent and predictable. Servers have hostnames like
web-prod-01. They sit in racks you own. Changes flow through Change Advisory Boards. Discovery agents scan the network on a schedule and report back what they find.That model worked. Then cloud infrastructure happened. (If you want the full story of why this architecture broke, The Death of Agent-Based Discovery has the detailed breakdown.)
Today, your auto-scaling group spins up 200 instances at peak and terminates them 40 minutes later. Lambda executes 10,000 times today across temporary compute that didn't exist yesterday. You deploy 50 times. Nothing waits for tomorrow's 6 a.m. discovery scan.
The bottlenecks in traditional CMDB architecture are obvious once you try this at cloud scale. Agent installation requires access to every system - but how do you install agents on ephemeral instances that scale dynamically and terminate before the agent even registers? The MID Server becomes a single point of failure. Discovery schedules create data lag measured in hours.
And then there's reconciliation. When resources change rapidly or use dynamic naming, the deduplication logic breaks constantly. The real issue - and this is where we've seen teams get stuck - is that reconciliation alone can consume significant engineering time every month. That's your platform team's time, burned on an infrastructure problem that shouldn't exist.
How Do Cloud CMDBs Work? #
Cloud CMDB architecture is simpler because it works with cloud infrastructure instead of against it. You call provider APIs, extract resource data with all native attributes, load it into a SQL database, and query on demand. That's the whole model.
This works because APIs like
DescribeInstances return current state in under a second. No discovery schedules, no agent installation, no reconciliation - the API is the source of truth. Standard SQL means any analyst on your team can query without training on a proprietary query language.Here's what a CloudQuery configuration looks like:
kind: source
spec:
name: aws
path: cloudquery/aws
version: "latest"
destinations: [postgresql]
tables:
- aws_ec2_instances
- aws_rds_instances
- aws_s3_buckets
- aws_bedrock_custom_models
Run
cloudquery sync configuration.yml and all your AWS resources are in PostgreSQL within minutes. You can point that same sync at Snowflake or BigQuery if your team already has a data warehouse - the destination is your choice, not the vendor's. Get started in under an hour.For most tables, CloudQuery supports incremental sync - fetching only changed resources rather than re-scanning everything on each run. That's what makes frequent syncs practical at scale without hitting API rate limits.
Why Don't ITIL Templates Work for Cloud Resources? #
Traditional CMDBs force cloud resources into templates designed for physical servers. A Server CI captures hostname, IP address, and OS. An AWS EC2 instance has 50+ native attributes:
instance_id, instance_type, vpc_id, subnet_id, security_groups, iam_instance_profile, public_ip_address, private_ip_address, tags, state_name, launch_time, availability_zone, ebs_optimized, monitoring_state, network_interfaces. The CI template captures maybe 10 of those.Application CIs were designed for monolithic apps on physical servers. They can't represent containerized microservices, serverless functions, or service meshes. Database CIs miss replication topology, automatic backups, parameter groups, subnet groups - everything that makes RDS different from a MySQL server you rack yourself. Relationship CIs require manual configuration to link resources, which breaks constantly when resources change dynamically.
Cloud-native approaches skip the translation layer entirely. An EC2 instance table includes all 50+ native attributes. RDS clusters include replication topology. Lambda functions include environment variables and permissions. No generic templates, no lost attributes - the actual infrastructure state. Teams that already use dbt can model this data into custom views — joining EC2, RDS, and S3 with team ownership tags, without touching the sync configuration.
The query difference is stark:
-- Traditional CMDB proprietary query
SELECT name, ci_type, status
FROM cmdb_ci
WHERE ci_type = 'Server'
-- Basic info. Cloud-specific attributes: missing.
-- Cloud CMDB with standard PostgreSQL
SELECT
instance_id,
instance_type,
vpc_id,
public_ip_address,
tags
FROM aws_ec2_instances
WHERE state_name = 'running'
AND tags->>'Environment' = 'production'
AND public_ip_address IS NOT NULL;
What Does Managing AI Infrastructure Look Like in 2026? #
This is where the comparison gets interesting, because it's where traditional CMDBs have a gap they genuinely cannot close.
A year ago, most cloud teams were managing EC2, RDS, S3. Today, those same teams have deployed Bedrock agents, Azure AI Services endpoints, and vector databases - and these are infrastructure. They have costs, dependencies, compliance requirements, and failure modes. When a credit-scoring model fails, you need to know every AI service it depends on, which accounts they're running in, and who owns them.
Traditional CMDB has no CI type for a foundation model. There's no template for an AI agent, a vector database, or a model invocation logging configuration. You'd have to create custom CI types through expensive professional services, then manually populate them, because the MID Server doesn't know how to probe a Bedrock endpoint.
Cloud CMDBs discover AI infrastructure the same way they discover EC2 instances: through provider APIs. AWS Bedrock exposes model deployments and configurations through the same API pattern as any other AWS service. CloudQuery syncs these alongside your other cloud resources:
-- Find all custom Bedrock models deployed across AWS accounts
SELECT
account_id,
region,
model_arn,
model_name,
tags
FROM aws_bedrock_custom_models
ORDER BY account_id, region;
-- Identify AI workloads without cost allocation tags
SELECT account_id, region, model_arn
FROM aws_bedrock_custom_models
WHERE NOT tags ? 'CostCenter' OR NOT tags ? 'Team';
Gartner projects that by 2029, 50% of cloud compute resources will be devoted to AI workloads. If your CMDB can't see those resources today, your asset inventory is already incomplete.
If your team is already using Claude Desktop or Cursor, CloudQuery's MCP server gives those tools direct query access to your inventory — an AI agent can answer "which accounts have Bedrock models without cost tags?" without anyone writing SQL. We wrote more about this in AI for Analyzing Your Cloud Asset Inventory.
What Are Platform Teams Actually Using CMDBs For in 2026? #
The use cases have shifted beyond asset tracking for financial audits. Platform teams are running real-time security queries, catching configuration drift, and using CMDB data to answer incident questions in seconds.
Security queries that actually work:
-- All public-facing instances with SSH open to 0.0.0.0/0
SELECT
i.instance_id,
i.public_ip_address,
sg.group_id
FROM aws_ec2_instances i
JOIN LATERAL JSONB_ARRAY_ELEMENTS(i.security_groups) AS sg_ref ON true
JOIN aws_ec2_security_groups sg ON sg.group_id = sg_ref->>'GroupId'
WHERE i.public_ip_address IS NOT NULL
AND sg.ip_permissions @> '[{"IpProtocol": "tcp", "FromPort": 22, "ToPort": 22, "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}]'::jsonb;
With a traditional CMDB, answering this question requires a 2-hour discovery scan, 30 minutes of reconciliation, a manual export, and cross-referencing security group data the CMDB may not have captured. By the time you have an answer, it's already outdated. With a cloud CMDB, this query runs in under a second against current state. (Note: the JOIN above covers the most common case - security groups attached directly to the primary network interface. Instances with multiple ENIs may have additional security groups not captured here.)
Configuration drift detection (for a deeper look at tagging strategy and enforcement, see Cloud Tagging Best Practices):
-- Find EC2 instances missing required governance tags
SELECT instance_id, tags
FROM aws_ec2_instances
WHERE NOT tags ? 'Owner'
OR NOT tags ? 'Environment'
OR NOT tags ? 'CostCenter';
Blast radius analysis for incident response:
-- Running EC2 instances in the same VPC as the RDS cluster (starting scope for blast radius analysis)
SELECT
i.instance_id,
i.instance_type,
i.tags->>'Service' AS service
FROM aws_ec2_instances i
WHERE i.vpc_id = (
SELECT vpc_id FROM aws_rds_clusters
WHERE db_cluster_identifier = 'prod-api-cluster'
)
AND i.state_name = 'running';
Cost optimization:
-- Unused EBS volumes older than 30 days
SELECT account_id, region, volume_id, size, volume_type, create_time
FROM aws_ebs_volumes
WHERE attachments = '[]'::jsonb
AND create_time < NOW() - INTERVAL '30 days';
Point-in-time compliance evidence:
Auditors ask for configuration state on a specific date. Traditional CMDBs have snapshots from the day before and the day after, but rarely the actual date. With CloudQuery in append mode, historical syncs accumulate as audit evidence you can query directly:
-- Which RDS clusters lacked encryption on a specific audit date?
-- Requires a sync to have run on that date; use <= with ORDER BY _cq_sync_time DESC for nearest-prior snapshot
SELECT
_cq_sync_time::date AS snapshot_date,
account_id,
region,
db_cluster_identifier,
storage_encrypted
FROM aws_rds_clusters
WHERE _cq_sync_time::date = '2026-01-15'
AND storage_encrypted = false
ORDER BY account_id, region;
Platform teams are also feeding this data into their internal developer portals. If your team runs Backstage or Port, you can pipe CloudQuery data directly into service catalogs - no ServiceNow license required, no ITSM training for engineers who won't touch it anyway. The data lands in PostgreSQL (or Snowflake, or BigQuery) and goes anywhere you already query.
If you don't want to write every query from scratch, CloudQuery Platform includes pre-built Policies covering CIS AWS Benchmark, SOC 2, and cost governance — the SQL is already written and mapped to specific controls. But the underlying data layer is yours to query however your team works.
What Are Traditional Vendors Actually Shipping? #
The traditional CMDB vendors aren't standing still, and it's worth being honest about what they've actually built vs. what they're marketing.
ServiceNow's Zurich release (December 2025) shipped Now Assist for CMDB, which adds generative AI for duplicate CI detection and natural-language summaries of configuration item history. It's a real improvement for teams already running ServiceNow at scale. Device42, acquired by Freshworks in 2024, launched InsightsAI in October 2025 with natural-language querying of CMDB data.
Both are genuinely useful features. But the underlying architectures haven't changed - discovery still runs through MID Servers on schedules, data models are still ITIL CI types, and implementations still require professional services measured in months. AI features on top of scheduled, agent-based discovery don't change the fundamental mismatch with ephemeral cloud infrastructure. An AI assistant that tells you "I found 47 duplicate Server CIs" is solving a problem that cloud CMDBs don't have in the first place.
We think the "AI-powered discovery" rebrand is the most misleading marketing in the space right now. AI can make it easier to search what's in your CMDB. It can't change the fact that your CMDB doesn't know an ephemeral instance existed and terminated before the next scan ran.
When Should You Stick with a Traditional CMDB? #
Honestly, if your infrastructure is 90%+ on-premises with no cloud migration plans, traditional CMDB is probably fine. The failure modes described in this post happen at cloud scale, with ephemeral resources and multi-cloud complexity. A data center with 500 physical servers, scheduled change windows, and ITIL workflows built around permanence is the environment traditional CMDBs were designed for.
The question is whether that describes your environment in 2026. For most platform teams it doesn't, and the mismatch shows up in adoption rates - most of your engineers are maintaining spreadsheets or querying AWS directly because the CMDB data is stale or incomplete.
The Path Forward #
The technology to do this right already exists. Cloud provider APIs return current state in under a second. SQL runs on the database your team already uses. A working sync takes an afternoon to set up, not a six-month implementation engagement.
If your CMDB data is stale, incomplete, or perpetually behind a reconciliation backlog, those aren't team failures. They're architectural mismatches. The question is whether to keep working around them or switch to an approach that actually fits how cloud infrastructure works.
Get started with CloudQuery and have your first AWS sync running in under an hour. Add AI workloads to your inventory the same way you add EC2 instances - through the same API-based sync, no custom CI types required. If you're approaching this from scratch, Getting Started with Cloud Asset Inventory covers the broader landscape before you commit to a specific approach.
See Cloud-Native Asset Inventory in Action
Learn how CloudQuery's API-based sync and SQL-first querying work for your environment. Or start with the docs and have your first AWS sync running in under an hour.
Frequently Asked Questions #
What Is a Cloud CMDB? #
A cloud CMDB uses cloud provider APIs to continuously sync infrastructure data into a queryable SQL database. Rather than installing agents and running scheduled scans, cloud CMDBs call APIs like AWS DescribeInstances to get current resource state. You store the data in PostgreSQL, Snowflake, BigQuery, or your database of choice - then query it with standard SQL. CloudQuery supports 500+ integrations across cloud providers, SaaS tools, and infrastructure platforms.
What Is the Difference Between a CMDB and a CSPM? #
A CMDB stores configuration data about infrastructure - what exists, how it's configured, what it connects to. A CSPM (Cloud Security Posture Management) is a security-specific tool that evaluates infrastructure against compliance frameworks and vulnerability databases. The two are complementary, not alternatives. CSPMs need an accurate inventory to function; a cloud CMDB provides that inventory. The difference is scope: CSPMs focus on security findings; a cloud CMDB gives you the complete infrastructure context - security, cost, and configuration - in one place.
Do I Need a CMDB If I Use Terraform? #
Yes, and this is a common gap. Terraform tracks what it deployed. A CMDB tracks what's actually running. Those aren't always the same. Console-created resources, manual changes, resources provisioned by other teams, and infrastructure that drifted from its IaC definition all exist outside the Terraform state. A cloud CMDB lets you validate IaC state against reality:
-- Find running instances not tracked in your known IaC inventory
WITH tf_instances AS (
SELECT unnest(ARRAY['i-abc123', 'i-def456']) AS instance_id
)
SELECT a.instance_id, a.instance_type, a.tags
FROM aws_ec2_instances a
LEFT JOIN tf_instances t ON a.instance_id = t.instance_id
WHERE t.instance_id IS NULL
AND a.state_name = 'running';
Why Do Traditional CMDBs Fail in Cloud Environments? #
Three causes, consistently: agent-based discovery can't capture ephemeral resources (Lambda functions, auto-scaling instances, spot instances that terminate before the next scan), ITIL CI templates don't represent cloud-native attributes (EC2 instances have 50+ attributes; traditional Server CIs capture around 10), and implementation timelines measured in months exhaust organizational patience before the system delivers value. Gartner reports 70-80% of traditional CMDB initiatives fail to deliver business value.
What Is AI Inventory in a CMDB? #
AI inventory means treating AI infrastructure - foundation models, AI agents, vector databases, model endpoints - as first-class configuration items. A team deploying AWS Bedrock agents or Azure AI Services endpoints has infrastructure that needs tracking for cost allocation, compliance, and incident response. Traditional CMDBs have no CI type for these resources. Cloud CMDBs discover them the same way they discover EC2 instances: through provider APIs that expose model deployments, invocation logging, and resource configurations.
Can I Query a Cloud CMDB with SQL? #
Yes. Cloud CMDBs store infrastructure data in standard SQL databases - no proprietary query language, no vendor-specific tooling. Any engineer who knows SQL can query your infrastructure data without CMDB training. CloudQuery supports PostgreSQL, BigQuery, Snowflake, ClickHouse, and other destinations - whichever database your team already uses. See the CloudQuery docs for query examples.
Can I Migrate from Traditional CMDB to a Cloud CMDB? #
The practical path is to run them in parallel. Set up CloudQuery to sync your cloud resources, validate that the data is accurate and complete for your use cases, then gradually shift queries and workflows. Most teams can move security and compliance queries to the cloud CMDB within the first week. A full migration - including deprecating the traditional CMDB for cloud resources - typically takes days to weeks depending on how many integrations depend on the old system. Solving CMDB Challenges in Cloud Environments covers five of the most common migration blockers teams hit and how to work through them. Join the CloudQuery community to connect with teams that have made this transition.
How Often Does a Cloud CMDB Sync? #
CloudQuery syncs on configurable schedules. You can run full syncs hourly, every few minutes, or on-demand. Incremental syncs (for supported tables) append data rather than replacing it, preserving historical state. Each sync queries cloud provider APIs and updates your database with current state. Unlike traditional CMDBs that scan daily and spend hours reconciling duplicates, cloud CMDB syncs complete in minutes with no reconciliation step.