Privacy-friendly analytics help us see which jobs people explore. They stay off unless you agree.Analytics off unless you agree. Details

Read the record
Back to the river
Skip to sources
Time Machine

Database architects

Also called Data architect, Sr database architect, Senior database architect, Enterprise data architect, Data warehouse architect

In brief

In May 2025, BLS counted 67,140 US database architects, with median pay of $139,500 a year. Of the BLS counts since 2021, the May 2025 count is the highest. The earliest figure here is an estimate of 30,000 from 1980, not measured the same way as today's count. The last full technology era for database architects: Data governance and compliance architecture, 2018 to 2023.

What the sources say

Official outlook

BLS projects employment to grow 9.4% from 2025 to 2035.

BLS Employment Projections 2025-35

AI exposure studies

Data as of BLS OEWS May 2025; BLS Employment Projections 2025-35. BLS publishes these counts as yearly survey snapshots and cautions against reading them as a precise trend.

Last updated .

Cite this page
APA

Future History. (2026, October 11). Database architects: jobs and pay since 1980 [Data set; data as of BLS OEWS May 2025; BLS Employment Projections 2025-35]. https://futurehistory.earth/timeline/15-1243

Chicago

Future History. "Database architects: jobs and pay since 1980." Data as of BLS OEWS May 2025; BLS Employment Projections 2025-35. Last modified October 11, 2026. https://futurehistory.earth/timeline/15-1243.

BibTeX

@misc{futurehistory_15_1243, author = {{Future History}}, title = {Database architects: jobs and pay since 1980}, year = {2026}, month = oct, howpublished = {\url{https://futurehistory.earth/timeline/15-1243}}, note = {Last updated 2026-10-11. Data as of BLS OEWS May 2025; BLS Employment Projections 2025-35}, }

The access date is today's date on your device.

drag to travel through time
19752000now
2026
Known then as Data Base Manager / Database Administrator (first-generation mainframe data custodians)
Known then as Database Administrator (relational-era DBA, SQL-trained)
Known then as Data Architect / Database Architect (data warehouse era, distinct from DBA operations)
Known then as Enterprise Data Architect / Data Warehouse Architect / Data Modeler (pre-cloud era breadth)
Known then as Database Architects (BLS SOC 15-1243, separated from 15-1242 DBAs)
Known today as Database Architects (BLS SOC 15-1243, separated from 15-1242 DBAs)
Projected to still be called Database Architects (BLS SOC 15-1243, separated from 15-1242 DBAs)
Data from the May 2025 survey
US Employment
67K
Est.

Stated in source: BLS OEWS

Official statistic
Report an error
Median Annual Wage
$139,500
Est.

≈ $135,923 in 2024 prices (derived by us, CPI-adjusted)

Official statistic
Report an error
Beat · 1970

Edgar Codd published "A Relational Model of Data for Large Shared Data Banks" in Communications of the ACM (June 1970). IBM suppressed commercial implementation to protect IMS revenue. Codd's ideas were implemented first by Oracle (1979) and then by IBM's own DB2 (1983) after the commercial threat from Oracle forced IBM's hand. The paper is among the most cited in computer science and is the intellectual foundation for the entire database architect profession.

Beat · 1976

Peter Chen published "The Entity-Relationship Model: Toward a Unified View of Data" in ACM Transactions on Database Systems (1976), introducing the entity-relationship diagram (ERD). The ERD became the universal visual language for database architects: every schema design for the next five decades would begin with boxes, diamonds, and lines on paper or a whiteboard before touching a SQL terminal. Chen's notation is still taught in every database design course and still used in commercial modeling tools like ERwin, Lucidchart, and SqlDBM Copilot.

Beat · 1980

The Data Management Association (DAMA) was founded in 1980 as the first professional organization specifically for data practitioners. DAMA's Data Management Body of Knowledge (DMBOK), first published in 2009 and revised in 2017, remains the canonical reference for data governance, data architecture, and data modeling standards. Certification under DAMA (the Certified Data Management Professional, CDMP) became a recognized credential for senior data architects.

Beat · 1992

Bill Inmon published "Building the Data Warehouse," giving the data warehousing discipline its first formal methodology. Inmon defined the warehouse as subject-oriented (organized around business entities, not applications), integrated (consistent definitions across sources), time-variant (capturing historical state), and nonvolatile (append-only, not updated in place). These four properties remain the definitional criteria for warehouse architecture today. Inmon's top-down, normalized enterprise data warehouse approach competed with Ralph Kimball's bottom-up dimensional approach, and the debate between them structured database architect career training for three decades.

Beat · 2018

The Bureau of Labor Statistics 2018 SOC revision created the first clean separation between Database Administrators (15-1242) and Database Architects (15-1243), formally recognizing what the labor market had acknowledged for two decades: that designing a data system and operating one are distinct jobs with distinct skill sets, career paths, and wage levels. The separation was long overdue; Snowflake's founders (all three former Oracle data architects) had launched their company in 2012 precisely because the architectural design of a cloud-native warehouse was a fundamentally different discipline from on-premise DBA operations.

How to read this number

OEWS is a point-in-time survey snapshot, not a continuous time series; BLS advises against using it for year-over-year trend comparison.

Each dot is a cited figure over time; the dotted line only links them (values between aren't measured). Hollow dots are estimates.

Official statistic: Copied by a script from a statistics agency table or a published study's table, not retyped by hand. BLS figures and the forecast and exposure tables are also re-checked against that table on every data run. Researched context: Researched from the cited source rather than copied from it by a script, so it is not machine-checked yet. Spot a mistake? Each figure has a “Report an error” link.

Cited forecasts · present → 2035

Will AI replace database architects? What the research says

Each figure is stated by the named source; we publish no forecasts of our own. Where sources disagree, we show the disagreement rather than an average.

Each figure is stated by the named source; we publish no forecasts of our own. Where sources disagree, the spread is the honest signal.

What published forecasts say
Forecast change in the number of people doing this work, as published by each named source. Bars share one scale on every role, centred on zero and reaching the end at ±30%. Grey marks a small change, 3% or less either way.
BLS Employment Projections 2025-35
→ 2035
+9.4%
BLS National Employment Matrix, 2025-35 cycle, line for SOC 15-1243 (Database architects): 69.5 thousand jobs in 2025, projected 76.0 thousand in 2035, a change of +6.5 thousand (+9.4%). Matrix employment counts all jobs in the occupation, including self-employed workers (2.1% of this occupation in 2025). The average for all occupations in this cycle is +3.5%.
Official statisticReport an error
How exposed is this work to AI (research measures)
Scores as published by each study. Each row says what it measures. These measure what AI could technically do, not forecasts of jobs lost.
Eloundou et al. (2023), "GPTs are GPTs"
2023 study · Share of tasks exposed to LLMs (β, human-rated)
59.8%
of tasks
What this measures

Published occupation-level exposure from the paper's occ_level.csv for O*NET-SOC 15-1243.00 Database Architects. Shown: human-rated β = 0.598, the share of the occupation's tasks an LLM could do in at least half the time at equal quality, counting tasks that need LLM-powered software at half weight (β = E1 + 0.5 × E2). Other published measures for this occupation: human-rated α (LLM alone) 0.244 and γ (all LLM-assisted) 0.951; GPT-4-rated β 0.878. This measures how much of the work an LLM could touch, not how many jobs disappear.

Official statisticReport an error
Today, in this role

What's changing day to day for database architects

Three parts of your work where AI is already doing real lifting, and what stays yours.

AI is sitting alongside you hereAuthor and enforce database development standards: using AI tools (dbt Copilot, Atlan AI, Informatica CLAIRE GPT) to generate and apply naming conventions, documentation templates, and data quality rules at scale across hundreds of tables, then owning the standard itself: which column names are canonical across domains, what the required metadata fields are, and how violations are escalated in the engineering review process.

Author and enforce database development standards: using AI tools (dbt Copilot, Atlan AI, Informatica CLAIRE GPT) to generate and apply naming conventions, documentation templates, and data quality rules at scale across hundreds of tables, then owning the standard itself: which column names are canonical across domains, what the required metadata fields are, and how violations are escalated in the engineering review process.[8],[1]

Where your edge is

Own the standard-setting layer rather than the enforcement mechanics: AI tools enforce naming conventions and generate documentation at scale (Atlan Context Agents, Informatica CLAIRE GPT Metadata Enrichment), but the canonical vocabulary decisions (what "customer_id" means across all domains, which foreign key naming pattern is authoritative, when a column requires a business description vs. a technical one) require organizational authority and cross-team consensus that AI cannot establish.

AI is sitting alongside you hereDevelop dimensional models and data vault schemas for analytical workloads: using dbt Copilot to generate fact and dimension table stubs, staging models, and semantic layer metric definitions from natural language, then applying dimensional modeling expertise (Kimball vs

Develop dimensional models and data vault schemas for analytical workloads: using dbt Copilot to generate fact and dimension table stubs, staging models, and semantic layer metric definitions from natural language, then applying dimensional modeling expertise (Kimball vs. Inmon vs. Data Vault 2.0) to validate grain, conformed dimensions, slowly changing dimension (SCD) strategies, and the business process–to–fact table mapping that drives correct aggregation behavior downstream.[5],[1]

Where your edge is

Deepen expertise in the dimensional modeling judgment layer AI cannot provide: dbt Copilot generates syntactically correct model SQL efficiently, but determining the correct grain for a new fact table (transaction-level vs. daily snapshot vs. accumulating snapshot), selecting the right SCD type for each dimension attribute (Type 1/2/3/6), and mapping the business process to the fact table in a way that supports five years of future reporting requirements requires the modeling intelligence that distinguishes an experienced data architect from an AI code generator.

AI is sitting alongside you hereDesign the logical and physical data model for enterprise databases and data warehouses: using AI-assisted modeling tools (SqlDBM Copilot, GitHub Copilot) to generate ERD first drafts, AI-suggested relationship mappings, and DDL boilerplate, then applying architectural judgment on normalization trade-offs, partitioning strategy, and the organizational constraints (legacy app contracts, team skill sets, multi-year migration budgets) that make one design durable and another a five-year refactor.

Design the logical and physical data model for enterprise databases and data warehouses: using AI-assisted modeling tools (SqlDBM Copilot, GitHub Copilot) to generate ERD first drafts, AI-suggested relationship mappings, and DDL boilerplate, then applying architectural judgment on normalization trade-offs, partitioning strategy, and the organizational constraints (legacy app contracts, team skill sets, multi-year migration budgets) that make one design durable and another a five-year refactor.[7],[1]

Where your edge is

Own the normalization-vs-denormalization decision layer and the organizational trade-off analysis that AI tools cannot access: AI-generated schemas are syntactically correct and pattern-matched to observed workloads, but they cannot evaluate the application contracts a foreign key change will break in production, the regulatory sensitivity of a column that will need classification, or the budget ceiling that makes a pure-3NF design impractical for the migration timeline your organization can fund.

Where database architects go next

Natural next steps for someone with your foundation: not exits, evolutions.

What each move takes

Senior Database Architects who accumulate cross-team authority, budget ownership, vendor relationship management, and the ability to translate data infrastructure risk into business-impact language are well-positioned for IT Management. The CRI gain reflects a materially more resilient role: IS Managers own the decision layer rather than the design layer. The 2026 market specifically demands IT managers who can govern autonomous database adoption, set data governance strategy across AI and traditional workloads, and evaluate data platform investments against business outcomes: all skills that emerge naturally from a senior architect background.

What you'd add
  • · IT governance frameworks: ITIL v4, DAMA-DMBOK data governance, change advisory board (CAB) leadership
  • · Budget management: CapEx/OpEx planning for cloud data platform licensing (Snowflake, Databricks, BigQuery), vendor negotiation
  • · Data strategy communication: translating semantic layer readiness, vector database architecture investments, and data governance program ROI into executive-level business outcomes
  • · Team leadership: managing data engineering, analytics engineering, and data governance teams; workforce planning as AI tools compress delivery timelines
  • · Certifications: PMP, ITIL 4 Managing Professional, or AWS/Azure Solutions Architect Professional
What it takesSome new skills to pick up
Tools of the era

How has the work of database architects changed since 1968?

The tools that defined the work, one line per era. Select an era to see how it reshaped the work.

  • Hierarchical and network DBMS (IBM IMS, CODASYL)

    The first generation of database work was hand-navigation through tree-shaped data structures. IBM's Information Management System, built for the Apollo program and commercially released in 1969, stored data in parent-child hierarchies that matched the bill-of-materials structure of manufacturing. CODASYL, the database standard ratified in 1971 after Charles Bachman's work in the 1960s, used network-pointer navigation. Designing a schema in these systems required deep knowledge of the physical access paths, because the logical and physical models were the same thing: you could only query data along the paths you had physically encoded at design time. The database architect in this era was almost always called a "data base manager" and worked directly alongside the application programmers because changing a hierarchical schema was so expensive (requiring application rewrites) that design decisions were effectively irreversible.

    Effect on the work

    Employment of specialized database professionals was limited by the number of organizations running IBM mainframes.

  • Relational DBMS + SQL (Oracle 1979, DB2 1983, Sybase 1984)

    Edgar Codd's 1970 paper proposed that data should be independent of its physical storage layout, navigable by content rather than by pointer. Oracle shipped the first commercial SQL-based database in 1979; IBM's DB2 followed in 1983; Sybase was founded in 1984. SQL standardized in ANSI/ISO in 1986 and 1987. For database architects, the relational era was transformative in two directions simultaneously: it made design enormously more flexible (you could add a column or a new table relationship without rewriting the application) and it made design enormously more consequential (because now the entire analytical surface of the organization depended on how the architect had modeled the entities and their relationships). The craft of normalization emerged as the central discipline: the architect's job was to reduce data redundancy and anomalies by structuring data into Third Normal Form or beyond, while modeling referential integrity through foreign keys. IBM DB2 reached $1 billion in revenue by 1989, evidence of the scale of the market the relational revolution had created.

    Effect on the work

    The relational era expanded the database professional market dramatically. Every organization deploying an Oracle or DB2 application needed schema design expertise. The combined DBA/architect workforce grew between the late 1970s and the early 1990s, as client-server computing pushed relational databases into mid-size organizations that could not previously afford mainframe-class systems.

  • Data warehousing and dimensional modeling (Inmon 1992, Kimball 1996, Teradata)

    Bill Inmon defined the data warehouse in his 1992 book "Building the Data Warehouse" as a subject-oriented, integrated, time-variant, and nonvolatile store of data for management decision-making. Ralph Kimball's "The Data Warehouse Toolkit" in 1996 introduced the rival approach: dimensional modeling, organizing data into fact tables (numeric measurements) and dimension tables (business context), optimized for query and reporting rather than transaction processing. Teradata had been selling parallel-processing data warehouse appliances since its first commercial customer (Citibank) in 1984, and by the mid-1990s had Fortune 500 retailers and banks running billion-row analytical databases. The warehouse era created a new role category: the Data Architect who worked on analytical, read-optimized systems (OLAP), distinct from the DBA managing the transactional, write-optimized operational databases (OLTP). The Data Warehousing Institute (TDWI) was founded in 1995 to train and certify this emerging specialist cohort. Entity-relationship modeling tools like ERwin (founded 1983, acquired by Computer Associates 1995) became standard equipment for architects who needed to document logical models before implementing physical schemas.

    Effect on the work

    The data warehousing era doubled the market for database architects relative to the pure OLTP DBA market, because now every large organization needed both: operational DBAs keeping transactional systems running and data architects designing the analytical copy of those systems for reporting and decision support.

  • Big Data and NoSQL (Hadoop 2006, Cassandra 2008, MongoDB 2009)

    Google's MapReduce paper (2004) and its BigTable paper (2006) triggered a wave of open-source alternatives to the relational model. Apache Hadoop (2006), originally developed at Yahoo, offered distributed batch processing across commodity servers. Cassandra (2008, open-sourced by Facebook) provided a wide-column store optimized for write-heavy, high-availability workloads. MongoDB (2009) offered document-oriented storage with flexible schemas. These systems challenged the relational orthodoxy: not every problem was a well-structured table. Database architects had to add a second skill set alongside their SQL and dimensional modeling fluency: understanding when to reach for a relational schema versus a document store, a columnar store, a key-value cache, or a graph database. The era also elevated the concept of the polyglot persistence architecture, where a single application might persist data across three or four different database technologies, each chosen for its access pattern strengths. This made the architect's design judgment more valuable (more possible choices, higher stakes of picking wrong) but also more demanding.

    Effect on the work

    The big-data era initially created a parallel workforce of "data engineers" and Hadoop specialists that was distinct from the traditional database architect career path, but by 2012-2015 the two communities began converging as architects needed to design systems that spanned both SQL and NoSQL tiers.

  • Cloud data platforms and the modern data stack (Snowflake 2014, AWS Redshift 2012, dbt 2016)

    Snowflake came out of stealth in October 2014, built by three former Oracle data architects (Benoit Dageville, Thierry Cruanes, Marcin Zukowski) who had spent years watching the limitations of on-premise data warehouses. Snowflake's core architectural innovation was separating compute from storage on cloud object stores, enabling elastic scaling and consumption-based pricing. Amazon Redshift (launched November 2012) had already shown the market appetite for cloud-based analytics at a fraction of Teradata's cost. The "modern data stack" that crystallized around 2018-2020 combined cloud warehouses (Snowflake, Redshift, BigQuery) with ELT transformation tools (dbt, launched 2016 as an open-source project by Fishtown Analytics) and a catalog of SaaS connectors (Fivetran, Stitch). For database architects, the cloud era made platform selection a primary responsibility for the first time: the choice between Snowflake, Databricks, BigQuery, and Microsoft Fabric locked in vendor economics and ETL patterns for years. The physical hardware and on-premise tuning work that had occupied senior DBAs largely disappeared; the strategic work of designing schemas, semantic models, and governance frameworks intensified.

    Effect on the work

    The modern data stack era bifurcated the database professional market more sharply than any previous era: DBAs managing legacy on-premise Oracle and SQL Server installations saw their prospects plateau or decline, while architects with cloud data platform skills (Snowflake, BigQuery, Databricks) saw demand and wages rise steeply. The 2018 SOC revision, which created the separate 15-1243 code for Database Architects, reflected this market reality: the architect and operator functions had genuinely diverged.

  • Data governance and compliance architecture (GDPR 2018, data mesh, data catalog tools)

    The European General Data Protection Regulation came into force on May 25, 2018, and immediately elevated data governance from an internal discipline to a legal requirement with fines of up to 4% of global annual revenue. For database architects, GDPR created a new layer of required competency: column-level data classification, privacy by design in schema decisions, row-level access control, the right to erasure in production databases, and audit-trail architecture for data processing activities. US equivalents (CCPA in California, HIPAA in healthcare, SOX for financial reporting) added parallel requirements. Simultaneously, Zhamak Dehghani's 2019 paper introducing the "data mesh" concept proposed that data ownership should be decentralized to domain teams rather than owned by a central data team. The data mesh model made architects responsible for designing domain data products and their governance interfaces, rather than a single enterprise warehouse schema. Tools like Atlan (2019), Collibra, and Alation emerged to automate catalog enrichment and lineage tracking that architects had previously documented manually.

    Effect on the work

    The governance era added a compliance dimension to every database architecture role: architects who could design GDPR-compliant schemas with built-in PII classification, masking, and erasure workflows commanded a premium over those who understood only the data modeling and platform layers.

  • AI-assisted schema design and semantic layer tools (dbt Copilot 2025, Snowflake Cortex Analyst, Databricks Genie)

    The 2023-2026 wave of AI tooling has reached into the core of database architecture work. SqlDBM Copilot (2025) generates ERD first drafts and relationship suggestions in a cloud-native visual modeling IDE. dbt Copilot (GA March 2025) auto-generates semantic model definitions, metric configurations, and column documentation from existing model metadata and natural-language prompts. Snowflake Cortex Analyst and Databricks AI/BI Genie (GA June 2025, with year-over-year growth in monthly active users) provide natural-language analytics over architect-authored semantic models, creating a direct feedback loop between schema quality and analytics product quality. GitHub Copilot drafts DDL (CREATE TABLE, ALTER TABLE, index definitions) from natural-language descriptions. Atlan Context Agents generated 690,000 column descriptions across many enterprise customers in April 2026. The net effect is that the execution layer of architecture work is becoming AI-assisted or AI-automated, while the judgment layer (platform selection, normalization trade-offs, governance policy design, semantic model authorship, vector database architecture for AI/RAG pipelines) has become more critical because AI tooling amplifies the consequences of design decisions made at the top: a poorly designed semantic model causes Cortex Analyst and Databricks Genie to produce incorrect SQL at scale.

    Effect on the work

    BLS projects growth in database architect employment through 2034, against a combined DBA+Architect average of 4%, suggesting the market is reading AI tooling as a force that increases demand for the strategic architecture judgment layer while reducing demand for the operational DBA layer. Robert Half's 2026 Technology Salary Report identifies data-focused roles supporting AI as among the hardest positions for hiring managers to fill.

Part of Tech & Data · see all 28 roles →
Different role?

See the same long-arc view for your own profession.

Browse the directory by industry, or search by title or SOC code.

Browse all roles

Database Architects employment and pay by year

On record since1968
Latest US employment67,140 (May 2025)Source: BLS OEWS May 2025Official statisticReport an error
Latest US median pay$139,500 (May 2025)Source: BLS OEWS May 2025Official statisticReport an error
Outlook+9.4% by 2035Source: BLS Employment Projections 2025-35Official statisticReport an error
View all 8 years of cited US data, each linked to its source
YearUS employmentAnnual pay (median unless marked)SourceReport
198030,000n/aEst., Encyclopedia.com Researched contextReport
1990n/a$38,000Est., Dataversity Researched contextReport
199587,000n/aEst., Derived estimate Researched contextReport
202150,440$123,430BLS OEWS May 2021 Official statisticReport
202262,470$134,870BLS OEWS May 2022 Official statisticReport
202359,920$134,700BLS OEWS May 2023 Official statisticReport
202464,770$135,980BLS OEWS May 2024 Official statisticReport
202567,140$139,500BLS OEWS May 2025 Official statisticReport
Embed this timeline on your site

Free for any site. Paste this where the timeline should appear; it stays interactive, every datapoint stays cited, and it sets no cookies on your page. How embedding works

<iframe src="https://futurehistory.earth/embed/15-1243"
  width="100%" height="430" style="border:0"
  title="Database Architects, a Future History timeline"
  loading="lazy"></iframe>
<p style="font-size:13px;margin:4px 0 0"><a href="https://futurehistory.earth/timeline/15-1243">Database Architects: jobs and pay over time</a>, from Future History</p>

See all roles in Tech & Data