# Methodology Revision 1 (11 October 2026) · Modeled snapshot · through 8 October 2026. All figures are research-informed estimates of analytical activity. Significant errors may remain; decimal places do not imply measurement precision. This chart combines documented product history with estimates of how analytical work was done. It is a way to explore changes in the data stack over time. No consistent public dataset measures all three layers across this period, so the percentages are editorial estimates informed by the available evidence. ## What the percentages measure Think of each year as 100 representative units of analytical work, divided among access interfaces, query engines, and storage options. Each layer totals 100%. A share describes that technology’s place in the year’s analytical activity, rather than its share of revenue, customers, installations, bytes stored, or individual queries. The scope covers SQL reporting, data warehousing, and batch or interactive analysis of persisted data. It includes analytical work on general-purpose databases, but excludes their day-to-day application transactions. Streaming, document and other nonrelational databases, vector search, and BI presentation or semantic layers are outside this view. Specialized multimodal, geospatial, and scientific array or raster workloads are also outside scope. Their dedicated engines and formats are omitted to keep the focus on mainstream relational and tabular analytics. Ordinary tabular analysis of data derived from those systems remains in scope when it uses the engines and storage categories modeled here. A falling share can still accompany growth in absolute use. A missing name may be included in a broader family or be too small to show separately. ## Reading the bars from left to right Each year shows a cross-section of the technologies still in use in this model. Read each bar from left to right as a broad history: older families generally sit to the left, and newer ones to the right. Their order stays fixed as their shares change. “Other” categories can include newer technologies that are not named separately, and later versions stay with their original family. The order also keeps related categories together: vendor-specific interfaces come before shared APIs, and database-native stores come before shared storage. It is a guide to the history, not a strict release-date sequence across the whole bar. ## What the fills and patterns mean In access and storage, gray marks system-specific interfaces and storage: vendor interfaces, database-native storage, and the application files and older database stores grouped under Pre-relational reporting. That reporting pool combines several systems; it is not one vendor’s proprietary format. “Federated native” uses the same gray because the data still resides in another database’s native storage. White marks portable interfaces and shared files, storage systems, and table formats. This distinction describes coupling to a system, not whether its software is open source. All compute boxes use the same neutral white fill. Within split boxes, diagonal hatching marks the vendor-managed portion. The unmanaged, or customer-managed, portion stays white with a subtle boundary. Management is a separate distinction from coupling: a vendor can manage an open table format or a portable interface. Selecting a box strengthens its outline and connections while fading unrelated outlines and connections; it leaves the fills and hatching unchanged. Caption highlights also use outlines. Box widths carry the percentages; darkness does not represent a larger share. ## How the percentages were chosen **The percentages are research-informed estimates, refined through repeated review.** Product histories, technical documentation, adoption reports, and evidence about established use informed the allocations. We iterated on them as we checked release dates, product groupings, supported connections, storage mixes, and consistency across years. We also challenged the implied rankings, growth curves, client mixes, and storage migrations against the evidence. We focused on making both individual estimates and the overall historical trends plausible to people knowledgeable about the database industry. Special thanks to [Matthew Mullins](https://www.linkedin.com/in/msmullins/) for his feedback. No comparable measured dataset covers this whole history. The model therefore combines informed judgments with explicit assumptions, then calculates the bars and connections from those inputs. Checks ensure that the allocations agree and add up correctly; uncertainty remains in the underlying estimates. 1. **Establish what was available.** Release announcements, documentation, papers, and historical accounts set the earliest years in which a product or connection can appear. 2. **Estimate compute shares at selected years.** Divide 100% of analytical work among the engine families. These allocations reflect evidence about their relative use, the persistence of older installations, and the growth of newer systems. Adoption reports, customer counts, and vendor revenue inform the estimates, but none is converted directly into a workload percentage. 3. **Estimate each engine’s storage mix.** Estimate how much of that engine’s work uses each supported storage option. Multiply those fractions by its compute share and sum across engines to get the Storage bar. Storage shares are therefore calculated from two sets of estimated inputs. 4. **Estimate each engine’s client mix.** Divide its work among supported interfaces, using evidence about its client ecosystem and adoption of newer drivers. Add those connections across engines to get the Access bar. Engines can have different mixes of native clients, ODBC, JDBC, Python DB-API, Arrow, and ADBC. 5. **Fill the intervening years.** Interpolate between the chosen values, exclude products and connections before their modeled availability, and round while preserving the totals. The smooth motion between years comes from interpolation. Figures describe a representative late-year configuration. The historical research ends on 8 October 2026, so that year is a snapshot through that date. A company’s founding, a research prototype, and a shipping product are different milestones. A new product starts with a small allocation when it enters use. Earlier reporting remains in “Pre-relational reporting,” so the first relational databases do not appear to own the whole market. Release dates are generally better established than the numerical shares, especially in the earliest years. ## Example: Oracle in 2026 Oracle is used here as an illustrative example; the same calculation applies to every engine. For 2026, our research-informed estimate puts Oracle at **5.5% of compute activity**. Within Oracle’s analytical work, we estimate that 90% uses native storage, 2% reads Iceberg, and the remaining 8% uses other storage options. Those estimates contribute **5.5% × 90% = 4.95%** to Oracle native storage in the full Storage bar, and **5.5% × 2% = 0.11%** to Iceberg. Adding every engine’s Iceberg contribution gives 10.0025%. The extra decimal places come from combining the estimates. Despite extensive research and iteration, there are likely still significant errors in these estimates. If you think a date, grouping, or percentage should be corrected, please [let us know at hello@columnar.tech](mailto:hello@columnar.tech). Please include sources or other information that supports your claims or proposed changes. ## Access: count the path the client uses Access means the interface through which a client receives analytical results. Each path is counted once, even when software is layered: a Python client using an ADBC driver belongs to ADBC; one using ODBC belongs to ODBC. ADBC also serves Python and notebook workflows, including through DB-API wrappers. “Python DB-API” covers the remaining Python driver paths; it does not mean all Python use. Direct Arrow access means clients receiving Arrow results from an engine through an Arrow API, HTTP, Flight/Flight SQL, or an embedded interface. Arrow used internally by an engine, or client-side conversion of results fetched through another interface, does not qualify. An ordinary ODBC or JDBC interface stays in its own category even if its driver uses Arrow underneath. ADBC and direct Arrow are separate boxes, so they can be added without counting the same work twice. Driver availability establishes a possible route, not how often it is used. The estimates allow for adoption through BI tools, transformation tools, and notebooks, including drivers users may never configure themselves. Interface preferences vary by engine and year to reflect their different client ecosystems. Before ODBC, most applications used interfaces supplied with their database. Some earlier desktop systems already shared languages and file conventions, so the database-specific access boxes do not mean that all portability began in 1992. ## Compute: count the engine or service once The compute layer follows the engine or service that executes the analytical work. A separately shown hosted service is excluded from the underlying engine’s family, so the same activity is counted once. Work passed through to another engine belongs to the engine that executes it; reading linked files locally belongs to the local engine. Groupings follow product families and analytical use, rather than corporate ownership alone. Related versions and distributions may share a box, while a distinct engine or hosted service may have its own. Shared code, a common vendor, or compatible SQL does not by itself determine the grouping. Select a box to see its specific inclusions and boundaries. Broader categories cover earlier reporting systems, desktop databases, and smaller engines without assigning every product an unsupported individual share. They include only analytical activity, even when transaction processing was a product’s main use. Category composition changes as products appear and decline. “Pre-relational” describes the origins of the reporting systems in that pool; it does not imply that they disappeared or could never offer SQL access. ## Storage: count the representation being queried Storage describes the durable representation serving the analytical work. An engine’s native tables remain native storage whether their files sit on local disks, shared storage, or cloud object storage. Shared storage includes files, independently operated storage systems, and open table formats. File sharing predates the modern data lake. “Local/shared row files” covers direct analytical reads of row-oriented files on local disks or shared filesystems; differences in file dialects, indexes, and application logic can still limit portability. An open table format includes both its data files and table metadata. For example, Parquet files inside an Iceberg table count only as Iceberg; standalone Parquet counts separately. A table exposed through another format’s metadata stays with the format that controls its updates and history. Read compatibility alone does not change that assignment. “Other open formats · object” pools eligible tabular work in additional open file or table representations on object storage. It does not estimate each format separately or include specialized workloads outside this chart’s scope. A different file encoding inside a named table format does not create another share. If data is copied into a native warehouse, subsequent work on that copy counts as native storage. Temporary caches, spill files, and catalog databases do not create extra shares. Work that reads several storage types is divided among them. Queries into another database’s native tables use a separate federated-storage pool where the source vendors cannot be reliably assigned. A product may use “federation” to describe access to files, tables, and databases alike. Here, files and open tables retain their own categories; “Federated native” refers specifically to another database’s native storage. ## How the connections are estimated Each engine’s analytical activity is divided among the storage options it uses. For example, if an engine has 10% of compute activity and uses Iceberg for 30% of its work, that connection contributes 3% to the full storage layer. Adding the connections from every engine gives each storage box’s width. Access connections divide each engine’s work among its estimated client interfaces. Adding those connections gives the interface totals. Vendor-specific access can be much more common for one engine than another. All connections are estimates of use, rather than a map of every possible integration. The two sets of connections are estimated separately. Following a path from access through an engine to storage does not establish which interface was used for a particular storage option. ## What “managed” means For Iceberg and Delta, managed means a vendor service handles ongoing table maintenance, such as compaction, optimization, and cleanup. Customer-owned storage can qualify. A hosted catalog alone, or a maintenance job the customer operates, does not. Unmanaged means customer-managed, not unmaintained. For ADBC, managed means a vendor-operated access service. Simply bundling an ADBC driver inside a client application does not make it managed under this definition. These are subdivisions of the parent box. Their chart percentages use the full-layer denominator and add to the parent’s share before rounding. Selection and “All percentages” also show each part’s percentage within its parent. The engine connections remain attached to the full box. ## Rounding and animation The number of decimal places or significant figures displayed is not a claim about the precision of the estimates. Extra digits arise from combining estimates and keeping the totals consistent; they do not indicate greater accuracy or statistical confidence. Box labels are rounded, so displayed numbers may not add up exactly. Very small storage-management subdivisions stay hidden while their values remain available in the details. ADBC's subdivisions appear from their first nonzero allocation; an outside label shows the managed percentage when it cannot fit inside. Some first-year slivers mark documented releases, betas, or previews. These small allocations make arrivals visible; they are editorial choices, not measured adoption. Selecting a box explains its release status. Playback interpolates between annual estimates to make changes easier to follow. Those in-between frames are not additional observations. Pausing settles the chart on the displayed year’s values. ## Changelog **Revision 1** (11 October 2026) — Expanded early reporting and desktop coverage, split out notable engines from Other analytics, and adjusted shares and their access and storage allocations. **Revision 0** (8 October 2026) — Original version. Created with assistance from GPT-6 Astra. ## Sources The research draws on product histories and technical documentation. These sources support dates, architecture, and availability; the usage percentages remain our estimates. [Browse the public bibliography](https://history.columnar.tech/sources.md) --- [Markdown overview](https://history.columnar.tech/index.md) · [Interactive visualization](https://history.columnar.tech/#methodology) · [Methodology](https://history.columnar.tech/methodology.md) · [Terms of use](https://history.columnar.tech/terms.md) © 2026 Columnar Technologies Inc.