Research Frontiers and Future Database Developments

Introduction and Context

Database research is entering a period in which the central question is no longer simply how to store and retrieve data. Modern systems must simultaneously provide transactional correctness, analytical speed, geographic distribution, privacy, elasticity, sustainability, and resilience. These goals are often in tension. Strong consistency can increase coordination costs; data replication can improve availability but complicate governance; edge processing can reduce latency while making administration more difficult.

The emerging technologies discussed in this chapter—NewSQL, hybrid transactional/analytical processing (HTAP), edge databases, data mesh, data fabric, confidential computing, disaggregated storage, quantum technologies, and self-managing systems—should therefore be evaluated as architectural responses to particular workload and governance problems, not as universal replacements for relational or NoSQL databases.

A postgraduate engineer must be able to distinguish marketing claims from demonstrated capability. This requires explicit workload definitions, measurable hypotheses, reproducible experiments, awareness of failure modes, and evaluation of economic, ethical, and regulatory consequences.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Explain the motivations, architectures, and limitations of major emerging database paradigms.

2. Compare NewSQL, HTAP, edge databases, data mesh, and data fabric using technical and governance criteria.

3. Evaluate confidential computing and disaggregated storage in terms of security, performance, and operational complexity.

4. Discuss realistic implications of quantum computing for database algorithms and security.

5. Explain the architecture of self-managing database systems and the role of machine learning in administration.

6. Formulate research questions and design evidence-based experiments for emerging database technologies.

7. Assess ethical, regulatory, financial, and organizational consequences of adopting new database architectures.

1. NewSQL: Relational Semantics at Distributed Scale

NewSQL describes systems that retain relational data models and SQL interfaces while attempting to provide horizontal scalability, distributed fault tolerance, and strong transactional guarantees. The term is broad rather than a single formal architecture. Examples include distributed SQL systems based on consensus replication, globally distributed relational systems, and cloud-native systems that separate compute from storage.

Traditional relational database management systems scale primarily by increasing the capacity of one server or by using read replicas and application-level sharding. Sharding can improve capacity but transfers cross-shard transactions, rebalancing, and query routing to application developers. NewSQL attempts to make distribution more transparent.

A typical distributed NewSQL transaction involves:

• partitioning rows across nodes;
• replicating each partition for fault tolerance;
• coordinating replicas using a protocol such as Raft or Paxos;
• assigning transaction timestamps or another ordering mechanism;
• enforcing isolation and durability despite concurrent failures.

The principal attraction is a familiar relational abstraction with ACID transactions. However, SQL syntax does not imply identical semantics across products. Engineers must inspect isolation levels, handling of stale reads, schema-change behavior, index maintenance, distributed deadlock detection, and consistency during network partitions.

CAP, PACELC, and the Cost of Coordination

The CAP perspective states that during a network partition, a distributed system cannot simultaneously guarantee unrestricted availability and strong consistency. This does not mean that systems are always forced to choose only two properties; it means that partition behavior creates a fundamental trade-off.

PACELC extends the discussion: if there is a partition, a system chooses between availability and consistency; else, even during normal operation, it chooses between lower latency and stronger consistency. NewSQL systems commonly favor consistency and transactional semantics, accepting coordination latency.

The practical question is not whether a system is “distributed,” but where coordination occurs and how much it costs. A transaction that touches one partition may be inexpensive, whereas a transaction spanning several regions may require multiple rounds of communication. Consequently, schema design remains important even when a product claims to hide sharding.

Evaluation Criteria for NewSQL

A rigorous comparison should measure:

• transaction throughput and tail latency, not only average latency;
• performance under contention and skewed access patterns;
• behavior during node, disk, and network failures;
• cross-partition transaction cost;
• operational effort for rebalancing and upgrades;
• SQL compatibility and migration complexity;
• storage, licensing, and network costs.

A benchmark should include realistic transaction mixes. A high result from independent point writes says little about a workload dominated by multi-row, cross-region transactions.

2. HTAP: Combining Transactional and Analytical Workloads

Hybrid transactional/analytical processing seeks to support operational transactions and analytical queries on a common data platform or through tightly integrated systems. Conventional architectures often copy operational data into a warehouse or lakehouse using extract-transform-load pipelines. This creates delay, duplicated storage, and semantic drift. HTAP reduces this separation by using one database, synchronized replicas, or a shared storage layer.

HTAP architectures generally use one of three approaches:

1. Single-engine HTAP: one engine optimizes both row-oriented transactional access and column-oriented scans.

2. Dual-engine integrated HTAP: transactional and analytical engines are specialized but share storage or maintain low-latency replication.

3. Operational database with analytical replicas: changes are streamed to read-optimized replicas with stronger integration than a conventional batch warehouse.

The central technical conflict is resource interference. Transactions require predictable latency, short locks, and efficient point access. Analytical queries require large scans, joins, memory, and CPU. Resource governance is therefore essential. Workload admission control, priority scheduling, separate compute pools, columnar replicas, and incremental materialized views are common techniques.

Freshness and Analytical Correctness

“Real time” must be defined operationally. A report may be considered fresh if its maximum data age is below a stated threshold. If events arrive at time \(t_i\) and become visible to analytics at time \(v_i\), the visibility delay is \(d_i=v_i-t_i\). A useful experiment reports the distribution of \(d_i\), including median, 95th percentile, and maximum under load. The metric is meaningful only when event clocks, ingestion semantics, late-arriving data, and failures are controlled.

HTAP can reduce pipeline delay but does not eliminate data-quality problems. A transaction may commit while downstream indexes or analytical projections are still updating. Analysts must understand whether a query sees committed data, a transactionally consistent snapshot, or a partially refreshed projection.

When HTAP Is Appropriate

HTAP is particularly valuable for fraud detection, inventory visibility, personalization, industrial monitoring, and financial risk calculations where recent operational events influence decisions. It is less attractive when analytical workloads are massive, infrequent, and easily isolated in a warehouse, or when operational and analytical schemas have fundamentally different retention and governance requirements.

3. Edge Databases and Data-Intensive Applications

Edge databases place data processing and sometimes persistent storage near devices, users, or production sites. The objective is to reduce round-trip latency, preserve operation during disconnection, reduce bandwidth usage, or keep sensitive data within a locality.

An edge system may contain sensors, gateways, regional servers, and a central cloud database. It must address:

• intermittent connectivity;
• constrained CPU, memory, and power;
• synchronization and conflict resolution;
• device identity and secure update mechanisms;
• local retention and eventual reconciliation;
• physical compromise of devices.

Strong global consistency is often impractical at the edge. Applications may instead use local transactions followed by asynchronous synchronization. This is appropriate only when temporary divergence is acceptable. Conflict policies must be domain-specific. For example, merging two shopping-cart additions may be straightforward, while merging two independent updates to a medical prescription may not be safe.

Edge databases also raise observability challenges. A central administrator may not know whether a device is online, whether its clock is accurate, or whether its local data has been tampered with. Therefore, synchronization logs, monotonic version identifiers, authenticated updates, and explicit reconciliation states are essential.

4. Data Mesh and Data Fabric

Data mesh is an organizational and architectural approach that treats data as a product owned by domain teams. Its commonly stated principles are domain-oriented ownership, data as a product, self-serve data infrastructure, and federated computational governance. The goal is to reduce the bottleneck created when one central data team must understand every business domain.

Data mesh is not a database product. It is a sociotechnical operating model. Domain ownership does not remove the need for shared standards. Product teams must publish discoverable datasets with documented schemas, quality indicators, lineage, access policies, and service expectations.

Data fabric is a broader architectural concept focused on integrating data across heterogeneous platforms through metadata, catalogues, lineage, semantic models, policy enforcement, virtualization, and automation. A fabric may connect warehouses, lakes, databases, SaaS systems, and edge sources. It emphasizes consistent access and governance across locations.

The concepts overlap but are not identical. Data mesh emphasizes ownership and accountability; data fabric emphasizes integration and intelligent metadata-driven access. An organization can implement fabric technologies without adopting mesh governance, or adopt domain ownership without possessing a mature fabric.

Critical Evaluation

Both approaches can fail when they are treated as slogans. A mesh without platform engineering creates duplicated pipelines and inconsistent security. A fabric without accountable data owners becomes an elaborate catalogue with poor data quality. Evaluation should examine whether users can find data, understand its meaning, access it lawfully, and verify its quality.

Useful measures include time to discover a dataset, percentage of assets with owners and lineage, policy violations, schema-breaking incidents, data-product adoption, and the cost of maintaining integration metadata.

5. Confidential Computing and Trusted Data Processing

Confidential computing protects data while it is being processed by using hardware-supported trusted execution environments (TEEs). Conventional security commonly protects data at rest through encryption and data in transit through transport protocols. TEEs aim to reduce exposure while data is in memory and being operated upon.

A confidential workload typically involves:

1. creating an isolated execution environment;

2. loading a measured software image;

3. producing an attestation report;

4. allowing a data owner to release keys only if the expected code and platform are verified;

5. executing queries while limiting access by the host operating system or cloud operator.

This model is useful for collaborative analytics, outsourced database services, regulated workloads, and machine-learning inference. It does not automatically protect against all threats. Side-channel leakage, denial of service, malicious application code, compromised firmware, incorrect attestation policy, and data leakage through query results remain possible.

Database engineers must also evaluate encryption overhead, memory limitations, secure paging, key rotation, backup behavior, and the trustworthiness of the complete software stack. Confidential computing is a defense-in-depth mechanism, not a substitute for least privilege, auditability, secure coding, and governance.

6. Disaggregated Storage and Composable Database Infrastructure

In a conventional server, compute, memory, and storage are closely coupled. Disaggregated storage separates these resources over a high-speed network. Database compute nodes access shared storage services, often through distributed block, object, or log-structured systems. The separation permits independent scaling and may improve utilization.

Potential advantages include elastic compute, rapid replacement of failed workers, centralized durability, and better resource pooling. Challenges include network dependence, tail latency, metadata bottlenecks, failure-domain design, cache coherence, and noisy neighbors.

A database using disaggregated storage must clarify where durability occurs. A commit acknowledgment is meaningful only if the acknowledged log or page has reached a failure-tolerant medium according to the system’s durability contract. Engineers should test failures during writes, delayed acknowledgments, network partitions, storage-node loss, and recovery after partial replication.

The economic case depends on utilization. If compute is frequently idle while storage is large, independent scaling can reduce cost. If the workload is latency-sensitive and the network is oversubscribed, disaggregation may worsen performance. TCO analysis should include network equipment, data transfer, replication, operational labor, and failure recovery—not merely the price of storage capacity.

7. Quantum Implications for Databases

Quantum computing is not an imminent universal replacement for classical database systems. Its potential relevance lies in specialized algorithms, optimization, cryptography, and search-like tasks. Quantum search can provide a theoretical quadratic speedup in an unstructured search model, but database access is not automatically a quantum-accessible oracle. Loading classical data into quantum states can dominate the cost.

Possible research areas include quantum approaches to query optimization, graph analysis, combinatorial scheduling, sampling, and database security. Most proposed advantages remain conditional on hardware scale, error correction, data-loading assumptions, and algorithmic fit.

The most immediate database implication is cryptographic migration. Cryptographically relevant quantum computers could threaten public-key systems based on integer factorization or discrete logarithms. Organizations should therefore inventory cryptographic dependencies, prioritize long-lived sensitive data, and investigate post-quantum cryptographic standards and migration strategies. Symmetric cryptography is generally less dramatically affected, although appropriate key sizes and implementation practices remain important.

A responsible evaluation distinguishes a theoretical complexity result from an end-to-end system improvement. A quantum algorithm that reduces the number of oracle queries may still lose after data preparation, communication, error correction, and result verification are included.

8. Self-Managing and Autonomous Database Systems

Self-managing databases automate provisioning, indexing, tuning, scaling, backup, patching, anomaly detection, and recovery. Their design is often described through autonomic-computing functions: monitoring, analysis, planning, and execution, operating under explicit policies.

Machine learning can recommend indexes, predict workload changes, detect anomalies, estimate cardinalities, and select configurations. Reinforcement learning may choose actions through trial and feedback, but unsafe exploration is unacceptable on production data. A practical system therefore uses constraints, canary deployments, rollback, approval thresholds, and workload-aware objectives.

Automation quality depends heavily on observability. If metrics do not capture tail latency, queueing, lock waits, storage saturation, and business-level service objectives, an optimizer may improve one metric while damaging the real service. An autonomous controller must also avoid oscillation—for example, repeatedly adding and removing resources because its measurements lag behind workload changes.

Human oversight remains necessary for destructive changes, compliance-sensitive data movement, major schema changes, and ambiguous incidents. Explainability is important because database administrators must understand why an index was created, why a query plan changed, or why data was relocated.

9. A Framework for Evidence-Based Evaluation

Emerging technologies should be evaluated through explicit claims. A useful research process contains the following stages.

Define the Research Question

A good question identifies a workload, intervention, comparison, and outcome. For example: “Under a 70:30 read-write workload with 20 percent cross-region transactions, does a distributed SQL system maintain the required 99th-percentile latency during a regional failure more effectively than application-sharded PostgreSQL?”

State Hypotheses and Variables

The independent variable may be architecture, replication mode, or workload intensity. Dependent variables may include throughput, latency, freshness, recovery time, cost, or energy. Controlled variables include hardware, dataset, client concurrency, software version, and network conditions.

Select Metrics Carefully

For latency observations \(x_1, x_2, \ldots, x_n\), the arithmetic mean is

\[

\bar{x}=\frac{1}{n}\sum_{i=1}^{n}x_i.

\]

It summarizes average latency but can conceal long stalls. Percentiles, especially p95 and p99, are therefore essential for user-facing systems. Percentile calculations must state the estimator and sample-handling method when precision matters.

Throughput should be reported with its unit, such as committed transactions per second. Cost efficiency may be expressed as cost per million committed transactions, but the cost boundary must include relevant compute, storage, network, licensing, and operational expenses.

Design the Experiment

Use representative data distributions, warm-up periods, repeated trials, randomized run order, and controlled failure injections. Avoid comparing a highly optimized deployment of one system with a default deployment of another. Record versions, configuration files, hardware, workload generators, and raw results.

Analyze Trade-offs

A technology that improves latency but doubles cost may be justified for a safety-critical workload but not for a low-value batch process. Multi-objective analysis should show the Pareto trade-off rather than reduce every outcome to one unexplained score.

10. Illustrative Case: A Global Clinical Logistics Platform

Background

This illustrative case concerns MedSupply, a fictional organization distributing temperature-sensitive medicines through hospitals and regional warehouses. It operates in areas with unreliable connectivity and must meet strict audit and privacy requirements.

Problem

The central relational database provided strong consistency but caused high latency for warehouse operations. Batch analytical reports were several hours behind. Local staff sometimes continued receiving and dispatching medicines during network outages, creating reconciliation conflicts. Management considered NewSQL, edge databases, HTAP, confidential computing, and a data-mesh operating model.

Analysis

The workload contained short inventory transactions, occasional cross-warehouse transfers, continuous sensor readings, and analytical queries for expiry risk. A single architecture was unlikely to optimize all workloads. Strong consistency was essential for controlled-substance movements, while sensor summaries could tolerate delayed synchronization.

Approach

The organization adopted a mixed design. Regional edge databases stored operational queues and sensor data locally. Transactions involving controlled substances required online validation or explicit supervisory authorization during disconnection. Synchronization used authenticated event logs and domain-specific conflict rules. A distributed relational service supported globally coordinated inventory metadata. Analytical projections were maintained through an HTAP-capable platform, with resource isolation for operational transactions.

Sensitive cross-organizational analytics used confidential-computing features where supported, combined with pseudonymization and strict query policies. Domain teams published data products describing inventory, shipment, and sensor datasets; a central platform supplied cataloguing, lineage, identity, and policy services.

Outcome

The architecture reduced dependence on continuous connectivity and shortened local transaction latency. However, it increased operational complexity. The organization had to train domain owners, test synchronization conflicts, monitor edge devices, and maintain clear data-retention policies. The project succeeded not because one technology solved every problem, but because consistency requirements were classified by business risk.

Learning Points

1. Edge autonomy must be limited by safety and legal requirements.

2. HTAP requires workload isolation and explicit freshness definitions.

3. Data mesh requires organizational accountability, not merely decentralized storage.

4. Security controls must be layered; confidential computing does not remove application risk.

5. Architecture decisions should follow workload and risk analysis rather than product popularity.

11. Governance, Ethics, and Professional Responsibility

Emerging database systems can amplify surveillance, exclusion, and inequity. Edge analytics may process personal information outside established oversight. Automated tuning can move data across jurisdictions or change access paths without adequate review. Data products can reproduce biased definitions when domain owners lack diverse stakeholder input.

Governance should address purpose limitation, data minimization, retention, consent or lawful basis, access control, explainability, auditability, and deletion. Cross-border architectures must account for applicable privacy and sector regulations. Security assessments should include supply-chain risk, firmware, hardware trust assumptions, and incident response.

AI-assisted database administration also raises accountability issues. A recommendation system should preserve decision logs, confidence indicators, and rollback capability. Organizations remain responsible for automated decisions even when a vendor supplies the model.

12. Research Agenda and Best Practices

Promising research questions include:

• How can distributed SQL systems provide predictable tail latency under correlated regional failures?
• Which conflict-resolution policies are safe for particular edge-domain invariants?
• How should data-product quality be measured across federated organizations?
• What side channels remain in confidential database execution under realistic workloads?
• Can disaggregated storage achieve predictable durability and recovery under network congestion?
• How can autonomous tuning optimize cost, energy, and service objectives simultaneously?
• Which database workloads, if any, obtain end-to-end benefit from quantum subroutines?

Best practices are to define invariants before selecting technology, separate experimental claims from vendor benchmarks, test failure conditions, report tail behavior, include total cost and energy, document security assumptions, and preserve human review for high-impact changes. Reproducibility requires versioned configurations, public or well-described datasets, workload generators, and transparent statistical procedures.

Chapter Summary

Future database development is shaped by competing requirements for scale, freshness, locality, privacy, elasticity, automation, and resilience. NewSQL extends relational semantics into distributed environments but incurs coordination and operational costs. HTAP reduces analytical delay while requiring careful isolation from transactions. Edge databases improve locality and resilience but introduce synchronization and device-management problems. Data mesh addresses ownership and accountability, whereas data fabric emphasizes heterogeneous integration and metadata-driven governance.

Confidential computing protects data during processing but depends on trustworthy hardware, attestation, software, and policy. Disaggregated storage enables independent scaling but makes networks and failure domains central to database performance. Quantum computing currently offers research possibilities rather than a general database replacement, while its cryptographic implications require immediate migration planning. Self-managing databases can reduce administrative effort but require observability, safety constraints, explainability, and human oversight.

The appropriate evaluation method is evidence-based: define a precise workload and hypothesis, control variables, measure throughput and tail latency, test failures, include cost and governance, and report limitations. The central professional principle is to match architecture to business invariants and risk rather than adopt emerging technology as an end in itself.

Key Terms

NewSQL: Distributed relational database approach combining SQL and transactional semantics with horizontal scalability.

HTAP: Hybrid transactional/analytical processing on an integrated or closely coupled platform.

Edge database: Database deployed near data producers or users to reduce latency or support disconnected operation.

Data mesh: Domain-oriented operating model in which teams own governed data products.

Data fabric: Architecture integrating heterogeneous data through metadata, lineage, semantic models, and policy services.

Confidential computing: Protection of data during processing using hardware-supported trusted execution environments.

Trusted execution environment: Isolated execution area intended to protect code and data from unauthorized access.

Attestation: Evidence that a workload is running approved code on an expected trusted platform.

Disaggregated storage: Storage architecture separated from compute and accessed through a network.

HTAP freshness: Delay between an operational event and its availability for analytical queries.

Tail latency: High-percentile response time, such as p95 or p99 latency.

Cross-partition transaction: Transaction requiring coordination across distributed data partitions.

Data product: Governed, documented dataset or data service designed for reliable consumption.

Autonomous database: Database capable of automating administrative and optimization tasks.

Reconciliation: Process of resolving or integrating divergent data states.

Post-quantum cryptography: Cryptographic methods designed to resist attacks by quantum computers.

Failure domain: Set of components likely to fail together.

Workload interference: Performance degradation caused when different workloads compete for resources.

Federated governance: Shared governance in which local teams operate within common organizational policies.

Reproducibility: Ability of others to repeat an experiment using documented methods and materials.

Review Questions

Short Answer Questions

1. What problem does NewSQL attempt to solve compared with application-level sharding?

2. Why is p99 latency important in evaluating distributed database systems?

3. State two challenges associated with edge databases.

4. Distinguish data mesh from data fabric.

5. Why does confidential computing not eliminate the need for application security?

Long Answer Questions

1. Critically compare single-engine HTAP, dual-engine HTAP, and analytical-replica architectures.

2. Explain how CAP and PACELC reasoning informs the design of a globally distributed NewSQL system.

3. Discuss the benefits and limitations of disaggregated storage for cloud database platforms.

4. Evaluate the organizational and technical prerequisites for implementing a data mesh.

5. Explain the architecture, benefits, and risks of self-managing database systems.

Analytical / Application Questions

1. Design an experiment comparing a distributed SQL database with an application-sharded relational system under cross-region failures. Specify hypotheses, variables, metrics, and failure scenarios.

2. A hospital network wants local operation during connectivity outages but cannot tolerate unsafe conflicts in medication orders. Propose an edge synchronization and governance strategy, identifying which operations may be eventually consistent.

3. An organization claims that a quantum database algorithm is faster because it reduces query complexity. Develop a framework for testing whether the claimed advantage remains after data loading, communication, error correction, and result verification costs are included.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes NewSQL from conventional application-sharded relational systems?

A. It eliminates the need for transactions.

B. It attempts to provide distributed scalability while preserving relational SQL and transactional semantics.

C. It stores all data exclusively in document format.

D. It requires analytical workloads to be processed in batch mode.

Correct Answer: B. It attempts to provide distributed scalability while preserving relational SQL and transactional semantics.

Question 2

What is a primary technical challenge in HTAP systems?

A. Preventing all SQL queries from executing concurrently

B. Eliminating the need for data quality controls

C. Managing interference between predictable transactions and resource-intensive analytical queries

D. Ensuring that analytical data is always older than one day

Correct Answer: C. Managing interference between predictable transactions and resource-intensive analytical queries

Question 3

Which workload is most naturally suited to an edge database?

A. A disconnected warehouse requiring local inventory operations

B. A centralized archival workload with no locality requirements

C. A single annual report generated from historical data

D. A workload requiring every read to contact a distant central server

Correct Answer: A. A disconnected warehouse requiring local inventory operations

Question 4

Data mesh primarily emphasizes which principle?

A. Replacing all databases with one central warehouse

B. Domain-oriented ownership of governed data products

C. Encrypting every query with quantum hardware

D. Removing all organizational governance

Correct Answer: B. Domain-oriented ownership of governed data products

Question 5

What is the main purpose of attestation in confidential computing?

A. To compress database backups

B. To verify that approved code is running in an expected trusted environment

C. To increase the number of database indexes automatically

D. To resolve data conflicts between edge devices

Correct Answer: B. To verify that approved code is running in an expected trusted environment

Question 6

Which is a likely benefit of disaggregated storage?

A. Independent scaling of compute and storage resources

B. Guaranteed elimination of network latency

C. Removal of all storage failure domains

D. No requirement for durability testing

Correct Answer: A. Independent scaling of compute and storage resources

Question 7

Why should quantum database claims be evaluated end to end?

A. Quantum algorithms cannot perform any computation.

B. Data loading, communication, error correction, and verification may offset theoretical algorithmic speedups.

C. Classical databases cannot store quantum results.

D. Quantum systems always have lower energy consumption.

Correct Answer: B. Data loading, communication, error correction, and verification may offset theoretical algorithmic speedups.

Question 8

Which safeguard is most appropriate for autonomous database tuning in production?

A. Allowing unrestricted experimentation on live data

B. Disabling monitoring to avoid administrative overhead

C. Using constraints, canary deployment, and rollback mechanisms

D. Accepting every recommendation without human review

Correct Answer: C. Using constraints, canary deployment, and rollback mechanisms

Question 9

For a latency-sensitive service, why are p95 and p99 measurements valuable in addition to the mean?

A. They reveal behavior experienced by slower requests that the mean may conceal.

B. They always produce a lower value than the mean.

C. They measure database storage capacity directly.

D. They remove the need to repeat experiments.

Correct Answer: A. They reveal behavior experienced by slower requests that the mean may conceal.

Question 10

Which research practice best supports reproducibility?

A. Reporting only the best benchmark run

B. Changing hardware and software versions between trials without documentation

C. Publishing or documenting datasets, configurations, workload generators, and analysis methods

D. Excluding failure tests from the evaluation

Correct Answer: C. Publishing or documenting datasets, configurations, workload generators, and analysis methods