The history of databases and SQL How data became queryable.

IBM introduced an 80-column punched card that stored twice as much information as its predecessor while working with a new family of tabulating equipment.

The physical record format became an industry convention for decades. Its 80-column width later survived in terminals, programming languages, and source-code habits.

UNIVAC I processed administrative data electronically and used magnetic tape for input, output, and retained records at the Census Bureau.

Record processing moved beyond electromechanical tabulators. Tape made sequential data much denser and faster, setting the storage assumptions for early commercial computers.

IBM announced the 726 tape drive in 1952. It entered use with the 701 in 1953, using vacuum-column buffering to move plastic tape rapidly without tearing it.

Tape removed a storage bottleneck and made large electronic files practical. Its sequential nature also made sorting, batching, and careful file layout central to data work.

The IBM 305 RAMAC stored business records on rotating magnetic disks and moved a read-write head to the requested location without scanning an entire tape.

Direct access changed what online record systems could promise. Applications could retrieve and update an individual item quickly enough for interactive business use.

ERMA joined check readers, magnetic-ink characters, computers, tape, and printers into a production system that posted transactions against customer accounts.

The project showed that a very large record system could ingest standardized documents and update centralized account data as part of daily operations.

IDS placed linked record structures, data descriptions, recovery, and transaction-oriented access behind a reusable software layer. Applications reached data by following named paths.

A database management layer could serve more than one program while controlling shared records. IDS also became the direct ancestor of the CODASYL network model.

ICS/DL/I tracked bills of material and engineering revisions for millions of Apollo and Saturn V components using hierarchical records. IBM commercialized its lineage as IMS.

Hierarchical database management and high-volume transaction processing became a durable enterprise platform rather than a laboratory demonstration.

The DBTG report described schemas, subschemas, records, owner-member sets, and host-language operations for moving through a network database.

Commercial systems gained a shared vocabulary and programming contract, helping network databases spread across vendors and industries.

Codd represented data as relations and argued that users should not have to know where records sat on disk or which pointer path reached them.

Data independence became a design goal that could be stated mathematically. Relations and high-level operations created the foundation for declarative query languages and relational systems.

Bayer and McCreight described a height-balanced, multiway search tree whose nodes matched storage pages and stayed shallow as records were inserted or removed.

Ordered lookup could remain predictably efficient on disk. B-tree descendants became the default index family in relational databases and many storage engines.

INGRES combined relations, catalogs, access methods, protection, concurrency, and the nonprocedural QUEL language on Unix and DEC minicomputers.

A university team built a public relational lineage outside IBM. Its code, alumni, and ideas fed several commercial systems and later Berkeley database projects.

SEQUEL expressed relational retrieval and updates through composable clauses without requiring the user to choose an index, join algorithm, or pointer route.

Its descendant, SQL, became the interface connecting relational theory, optimizers, applications, and commercial database products.

Chen described entities, relationships, and attributes as a conceptual layer that could be discussed before a design was mapped into a particular database model.

Designers and domain experts gained a shared visual language for reasoning about structure, cardinality, and meaning before writing schemas.

System R integrated SQL, views, authorization, constraints, logging, recovery, concurrency, and physical access methods behind a relational interface.

It supplied the architectural bridge from Codd's proposal to later relational products and established patterns that database engines still use.

The authors formalized transactions, schedules, and database consistency, then showed why a transaction must stop acquiring locks once it begins releasing them.

Two-phase locking became a central route to serializable execution, connecting logical correctness with an implementable concurrency protocol.

The System R optimizer estimated result sizes and resource costs, explored access paths and join orders, and selected a plan for a declarative SQL query.

Users could state what they wanted while the database decided how to execute it. Cost-based planning made high-level relational languages practical at production scale.

Relational Software Inc. released Oracle V2 as an SQL-based relational system for commercial customers before IBM shipped its own relational products.

A software-only vendor could sell a database independently of a mainframe manufacturer, accelerating the commercial spread of SQL.

SQL/DS served IBM's VM and VSE environments, while DB2 brought relational data management to MVS. Both drew on System R research without being simple copies of the prototype.

SQL and relational databases entered IBM's enterprise product line, hastening adoption across organizations that ran critical work on mainframes.

Härder and Reuter organized database recovery around atomicity, consistency, isolation, and durability, then compared mechanisms through that common framework.

The ACID acronym gave engineers a compact way to state what reliable transaction processing must preserve across concurrency and failure.

The DBC/1012 distributed relational data across access-module processors, each with its own compute and disk, and used a switching network to coordinate parallel work.

A shared-nothing SQL architecture reached customers as an appliance built for large decision-support workloads, foreshadowing later massively parallel warehouses.

The preliminary design proposed user-defined types, operators, procedures, rules, complex objects, historical data, and multiple storage representations on a relational foundation.

The database could become a platform for new data domains instead of a fixed set of built-in record types. The research lineage ultimately produced PostgreSQL.

ANSI approved X3.135-1986, defining a common core for SQL data definition, manipulation, embedded modules, and conformance levels.

Vendors, buyers, and public agencies gained a portability target. SQL could now spread as a shared language even while products kept distinct dialects.

The EBIS architecture separated operational processing from an integrated relational warehouse built for reporting and end-user analysis.

Source systems, shared analytical data, metadata, and user access appeared as parts of one enterprise architecture rather than isolated extracts.

Gamma partitioned relations across 32 processors and disks, then ran scans, joins, aggregates, and updates in parallel while reporting scaleup and speedup measurements.

Shared-nothing parallel SQL became an experimentally documented architecture rather than a broad performance claim.

ARIES combined write-ahead logging, repeating history during redo, and compensation log records so a system could recover committed work and roll back incomplete work after a crash.

A rigorous recovery protocol supported fine-grained locking, partial rollbacks, and high-concurrency systems. Its ideas entered major databases and storage systems.

ISO/IEC 9075:1992 expanded standard SQL across 587 pages and defined entry, intermediate, and full levels for a much wider relational language.

Application portability gained a more ambitious target, and familiar features such as joins, constraints, data types, and embedded SQL received a common specification.

The report used online analytical processing to describe interactive, multidimensional business analysis and proposed twelve rules for evaluating systems.

OLAP became a durable vocabulary for cubes, dimensions, measures, drill-down, and analytical work that differed from transaction processing.

CWI researchers began a kernel that represented relations through vertically fragmented Binary Association Tables and used a simple intermediate language for query execution.

Column-oriented storage and execution became a sustained public research program, influencing analytical databases that optimized for scanning a few attributes across many rows.

MySQL grew from TCX's ISAM routines and an effort to provide an mSQL-compatible interface with better performance and functionality.

A fast, approachable relational server became a natural companion to web programming and later a core part of the LAMP stack.

Version 6.0 changed the Postgres95 name to PostgreSQL and restored version numbering that acknowledged the Berkeley POSTGRES lineage.

A research codebase became a recognizable, independently maintained community database whose extensibility and standards support would keep growing.

SQL:1999 added structured user-defined types, inheritance, methods, triggers, recursion, and other features developed during the SQL3 effort.

The standard pulled extensibility and object-oriented ideas into SQL without abandoning relational querying, reflecting the convergence that POSTGRES and commercial systems had explored.

SQLite packaged SQL parsing, transactions, storage, and a database file into a library linked directly into an application, with no separate server to install.

A full relational engine could travel inside phones, browsers, desktop software, and devices. Local structured storage became infrastructure that application users rarely had to see.

Brewer's invited talk argued that a distributed service could not guarantee consistency and availability while also tolerating arbitrary network partitions.

The conjecture gave practitioners a compact vocabulary for discussing failure behavior at internet scale and the limits behind system design choices.

Gilbert and Lynch supplied explicit definitions and an impossibility proof for consistent, available, partition-tolerant web services in an asynchronous network model.

An influential systems claim became something that could be examined through stated assumptions instead of repeated as a slogan.

GFS stored very large files across commodity servers, tolerated routine component failures, and optimized for Google's append-heavy processing workloads.

The paper showed how workload-specific assumptions could reshape distributed storage and later inspired open-source systems such as HDFS.

MapReduce let programmers express batch transformations as map and reduce functions while the runtime handled partitioning, scheduling, data movement, and failures.

Teams without deep distributed-systems expertise could process data across large clusters, helping batch pipelines grow outside traditional databases.

C-Store combined columnar projections, compression, shared-nothing execution, and separate read-optimized and write-oriented paths in one analytical system.

It supplied a coherent modern architecture for column-store engines and led directly to Vertica.

The distributed file-system and MapReduce code developed inside Nutch moved into its own Apache source tree and shipped its first Hadoop release.

A GFS-inspired storage layer and MapReduce-inspired processing framework became available as an open platform that organizations could run and extend.

Bigtable organized data by row key, column family, and timestamp, then distributed tablets across commodity servers at petabyte scale.

Its sparse, versioned data model and tablet architecture influenced HBase, Cassandra, and a broad family of wide-column stores.

Dynamo combined consistent hashing, replication, vector clocks, quorum-like reads and writes, and application-assisted conflict resolution for selected Amazon services.

The paper became a reference architecture for highly available key-value systems designed to keep accepting writes through failures.

Hive added tables, partitions, metadata, and the SQL-like HiveQL language, compiling analytical queries into Hadoop jobs.

Analysts could work with petabyte-scale cluster data without writing a custom MapReduce program for every question.

Dremel combined a multilevel execution tree with a columnar representation for nested records, producing interactive aggregations over very large read-only datasets.

Columnar storage, nested data, and massively parallel query execution came together in an architecture that later informed BigQuery.

Megastore layered entity groups, secondary indexes, synchronous replication, and Paxos coordination over Bigtable.

A large-scale key-value substrate could support strong transactions inside carefully chosen boundaries rather than abandoning consistency everywhere.

F1 placed schemas, SQL, indexes, and general transactions over a distributed store. Spanner added synchronous cross-datacenter replication and externally consistent transactions using TrueTime.

The systems challenged the simplified idea that scale required abandoning relational structure or strong transactional guarantees.

AWS opened Redshift to customers as a managed, columnar, petabyte-scale warehouse accessed through SQL and existing business-intelligence tools.

A data warehouse could be acquired by the hour instead of through a long appliance procurement and operations project.

Parquet 1.0 supplied an open columnar file format with nested-data encodings and integrations across the Hadoop query ecosystem.

Stored data could outlive one query engine. Shared files became a practical foundation for data lakes and later open table formats.

Spark 1.0 introduced Spark SQL so applications could mix SQL queries with distributed code. Catalyst later made relational optimization extensible inside Spark.

SQL became an interface within a wider engine for ETL, machine learning, graphs, and streaming rather than a language confined to one database server.

Snowflake separated durable storage, elastic compute clusters, and a cloud-services layer while presenting one transactional SQL warehouse.

Independent compute clusters could share data and isolate workloads, making storage and compute separation a defining cloud-warehouse pattern.

Arrow 0.1 introduced a shared in-memory columnar representation with C++, Java, and Python implementations underway.

Databases, DataFrames, query engines, and language runtimes could exchange tables with fewer copies and less serialization.

Aurora pushed redo processing into a replicated, self-healing storage service so the database tier sent compact log records instead of repeatedly shipping modified pages.

A relational engine could be redesigned around cloud networking, fault domains, and storage services rather than treated as software on a larger virtual machine.

Cloud Spanner offered Google's globally distributed relational design as a managed service, while CockroachDB 1.0 offered an independently deployable SQL database built on consensus replication.

Distributed SQL became a category that users outside a few large internet companies could adopt directly.

Iceberg managed large analytical tables through metadata trees, snapshots, atomic commits, schema evolution, and hidden partitioning over open data files.

A table's transactional and evolutionary state could live with its data rather than inside one warehouse or processing engine.

Delta Lake combined Parquet data files with a transaction log for snapshot isolation, optimistic concurrency, schema controls, versioning, and batch and streaming access.

Data-lake files gained database-like table semantics without requiring every reader to use a proprietary warehouse store.

The CIDR paper proposed an architecture built on directly accessible open formats with transactions, versioning, optimization, BI performance, and data-science support.

It gave a memorable name to the effort to place warehouse management features over open object-store tables.

pgvector added a vector type and similarity operations to PostgreSQL so embeddings and ordinary relational data could share transactions, filters, joins, and one SQL system.

Vector retrieval became a workload that an established relational database could absorb through its extension model.

ISO/IEC 9075-16:2023 standardized SQL/PGQ, allowing property-graph pattern matching to be expressed inside the SQL language family.

SQL continued absorbing workloads once treated as separate database categories, this time graph navigation and pattern matching.

DuckDB placed a vectorized analytical SQL engine inside an application process. Version 1.0 guaranteed future compatibility for files created with 1.0 and adopted a stronger stability policy for SQL and the C API.

Local files, DataFrames, notebooks, browsers, and applications could gain an optimizer and analytical SQL engine without operating a separate server.