Cloudy with high chance of DBMS: A 10-year prediction for Enterprise-Grade ML

Abhishek Roy; Alekh Jindal; Ashvin Agrawal; Avrilia Floratou; Brian Kroth; Carlo Curino; Fotis Psallidas; Hiren Patel; Jyoti Leeka; Karla Saur

REVIEW 3 major objections 4 minor 62 references

Cloudy with high chance of DBMS: A 10-year prediction for Enterprise-Grade ML

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper predicts that within ten years, enterprise machine learning will be trained in the cloud, scored inside database engines, and governed through continuous provenance tracking, making the database engine the default platform for…

desk verdict A credible industrial vision paper for in-DB ML scoring and governance, with early proof points—but the uniform-IR premise that holds the thesis together is still a hope, not a demonstrated result. read the letter →

arxiv 1909.00084 v2 pith:LO4GBJJJ submitted 2019-08-30 cs.DB cs.DCcs.LG

Ashvin Agrawal , Rony Chatterjee , Carlo Curino , Avrilia Floratou , Neha Gowdal , Matteo Interlandi , Alekh Jindal , Kostantinos Karanasos

show 14 more authors

Subru Krishnan Brian Kroth Jyoti Leeka Kwanghyun Park Hiren Patel Olga Poppe Fotis Psallidas Raghu Ramakrishnan Abhishek Roy Karla Saur Rathijit Sen Markus Weimer Travis Wright Yiwen Zhu

This is my paper · ORCID

classification cs.DBcs.DCcs.LG

keywords enterprisemachinelearningin-databaseinferencemodelscoringgovernanceprovenanceSQL/MLoptimizationcloudFlockarchitecture

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Enterprise-grade machine learning, the paper argues, will be reshaped by two forces at once: ML's spread beyond a few high-value web applications, and tightening regulatory pressure on data handling. The paper's prediction is that the next decade brings 'cloudy with a high chance of DBMS, and governance throughout': model training and development move to private or public clouds, trained models are stored and scored inside managed database environments rather than standalone serving containers, and provenance is tracked end to end from training data to the decisions made from predictions. The claim matters because if it holds, the database engine becomes the default execution and governance layer for enterprise ML inference, not just a repository. Early experimental results support the feasibility: integrating an ML runtime into a database engine and applying cross-optimizations such as predicate-based model pruning and model inlining yields up to 5.5x over standalone serving and up to 24x with combined optimizations.

What carries the argument

The load-bearing mechanism is Flock, a reference architecture for the canonical data-science lifecycle, together with an intermediate representation for inference pipelines that can be compiled into optimized database execution plans. The key technical move is to treat scoring as a foundational extension of relational algebra: given a uniform representation of a model, the system compiles the full featurization-plus-model pipeline into relational operators and lets the SQL optimizer apply predicate-based model pruning, model-projection pushdown, model clustering, model inlining, and physical operator selection across the SQL/ML boundary. For governance, the machinery is a provenance catalog that combines coarse-grained SQL provenance with static analysis of Python scripts, connecting database columns to trained models and enabling applications like model linting, compliance checks, and impact analysis.

What would settle it

Run a broad benchmark suite spanning deep networks, tree ensembles, text featurizers, and proprietary models, comparing compiled in-database inference against standalone serving on the same hardware and latency target; if any common model family either cannot be represented in the intermediate form or loses to standalone serving on realistic workloads, the 'score in the DBMS' prediction fails for that family.

Watch

Extended reading notes

Core claim

The central claim is a design point: an ML model should be thought of as software derived from data, and therefore as both a program to be engineered and a dataset to be governed. From that lens the paper derives three predictions: (1) training and model development will happen in the cloud, where centralized data, elastic resources, and latest hardware are available; (2) models must be stored, versioned, and scored in managed environments such as a DBMS, with inference expressed as an extension of relational query processing so data never has to be exfiltrated; and (3) provenance must be collected across all phases, connecting the data that trained a model to the decisions the model later influences. The paper supports these claims with a reference architecture (Flock), an analysis of over four million public notebooks, conversations with enterprises, and early benchmarks of in-database inference.

Load-bearing premise

The load-bearing premise is that the most widely used model families and their featurization pipelines can be captured in a uniform intermediate representation and compiled into efficient in-database code without data exfiltration, so in-database scoring matches or beats dedicated serving systems; the paper offers early benchmark evidence but not broad coverage.

Editorial extensions

If this is right

In-database model scoring becomes the default for batch and many latency-sensitive enterprise predictions, with transactional updates across multiple deployed models.
Database query optimizers gain a new class of ML-aware rewrites, so the same inference pipeline runs faster as data volumes grow rather than requiring separate serving infrastructure.
Model management inherits enterprise data features: access control, versioning, auditing, and high availability apply to models as first-class DBMS data types.
Automated provenance turns compliance checks into queries: detecting label leakage, PII usage, or the impact of a dropped column becomes a programmatic analysis of the captured lineage.
The division between application-level business policies and raw model predictions becomes explicit and auditable, with policies applied transactionally around model outputs.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Beyond the paper: if the uniform-intermediate-representation premise holds beyond the benchmarked models, the same compiled inference plans could be pushed to edge databases, making the database the governance boundary for on-device scoring.
Beyond the paper: the 24x speedup likely reflects workloads where predicate pruning applies; on dense scoring over all rows the advantage would narrow to parallelization and column pushdown, so a reproducible benchmark across model families would sharpen the decade-long prediction.
Beyond the paper: the provenance design implies row- and column-granular data versioning rather than file-granular versioning, since files are not the atomic unit of training data—a storage research agenda the paper only sketches.
Beyond the paper: the notebook analysis suggests the Python data-science ecosystem is consolidating around a core of packages; if that consolidation continues, the compiler-based IR approach becomes progressively more tractable.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

Here's my take on the Cloudy with DBMS paper. It's a solid, articulate industrial vision paper. The main claim—enterprise ML will be governed and scored inside DBMSs—is presented as a ten-year prediction, supported by firsthand experience, customer conversations, a large-scale GitHub notebook analysis, and early benchmarks. The paper is honest that the details live in companion papers.

What's genuinely new: the Flock reference architecture, which treats models as derived data and lays out a data-management-centric lifecycle; the in-database cross-optimizer that does predicate-based model pruning, projection pushdown, model inlining, etc.; and the SQL and Python provenance modules that track lineage across heterogeneous systems. The early results (5.5x to 24x speedups) are encouraging, and the provenance coverage numbers on TPC-H/TPC-C and Kaggle scripts are a reasonable first step.

The soft spots are real but not fatal for a vision paper. The central premise—that widely used model families and featurization pipelines can be uniformly represented (e.g., ONNX) and compiled into the query runtime—is backed only by 'it appears likely' in the intro and a few benchmark teasers. Figure 2's coverage plot is about package popularity, not ONNX exportability. Figure 4 omits methodology, error bars, hardware, and whether the comparison includes end-to-end featurization or just model scoring. The paper even acknowledges the full systems papers are under preparation, so the evidence isn't independently checkable yet. If common featurizers or proprietary models don't fit the IR, the 'DBMS as default scoring layer' claim narrows considerably.

I think these are legitimate concerns, but they don't sink the paper. It's a provocation and a research agenda, and it does a good job of laying out the open problems for the database community. The self-citation pattern is reasonable here because the cited works are the actual companions where the details will appear.

Who should read it: anyone working at the intersection of database systems and ML, especially those interested in model serving, provenance, and governance. It would be a good reading-group starting point. I'd recommend a serious referee engage with it—it deserves peer review, probably at a venue that welcomes vision papers, with the expectation that the companion papers deliver the goods.

Referee Report

3 major / 4 minor

Summary. This CIDR-style vision paper predicts that over the next ten years enterprise-grade machine learning will converge on three themes: model training and development in the cloud, model scoring inside managed data platforms such as DBMSs, and pervasive governance and provenance across the ML lifecycle. The paper introduces the Flock reference architecture, grounds the prediction in the authors' industrial experience, customer conversations, a GitHub analysis of over four million notebooks, and a survey of the competitive landscape. It also presents early technical results: an ONNX Runtime integration into SQL Server with cross-optimizations for in-DBMS inference, and SQL/Python provenance capture modules with initial evaluation on TPC-H, TPC-C, Kaggle, and internal Microsoft scripts.

Significance. If the prediction is correct, the database community's role in ML shifts from peripheral to central: DBMSs become the default execution and governance layer for enterprise model scoring. The paper is valuable as a position piece because it names concrete open problems (provenance modeling, model versioning, inference-as-query-processing) and offers a falsifiable research agenda. Its strengths include grounding in a large-scale notebook analysis, early prototypes with reported speedups, and an explicit call to action. The main limitation is that the load-bearing evidence for the strongest claim (in-DBMS scoring) is preliminary and not fully specified, so the paper is better read as a roadmap than as a validated result. It should be publishable after the evidence for that claim is either made reproducible or explicitly scoped as speculative.

major comments (3)

[§4.1, Figure 4] The benchmark evidence for the central 'score in the DBMS' claim lacks methodology and internally inconsistent numbers. The figure reports speedups of 17x and 24x, while the text says 'up to 5.5x' for SQL Server/ORT integration and 'up to 24x' for combined optimizations in §4.1, and '5x to 24x' in §2. The figure does not specify the models, datasets, hardware, run counts, error bars, or whether the comparison includes the full featurization pipeline or only model scoring. Since this is the main empirical support for the paper's second core prediction, the authors should provide a detailed experimental setup, reference a public artifact, or clearly label the figure as an illustrative early result with the specific conditions under which it was obtained.
[§1 and §4.1] The premise that the most widely used model families can be uniformly represented and compiled into efficient in-database code is asserted with hedging language ('It appears likely') and cited to MLflow and ONNX, which are platforms/format specifications rather than coverage studies. Figure 2 measures notebook package coverage, not model or featurization representability. This assumption is load-bearing for the 'score in the DBMS' prediction: if common featurization pipelines or proprietary model types cannot be captured in the IR, the prediction narrows to a small subset of tabular models. The paper should either provide a coverage analysis over the model/featurizer space or explicitly state the scope of the claim.
[§4.2] The provenance results are presented as validation, but they are preliminary and not independently checkable. The SQL provenance table reports latency and graph size on TPC-H and TPC-C without a baseline, accuracy metric, or end-to-end correctness check; the Python provenance table covers only 49 Kaggle and 37 Microsoft scripts. The text and acknowledgements state that full papers are 'under preparation' and 'ongoing', meaning the described systems are not publicly available. This is acceptable for a vision paper, but the claims should be framed as early feasibility checks rather than demonstrated solutions, and the authors should make clear what fraction of the reported provenance capture is automated versus manually inspected.

minor comments (4)

[§2, Figure 1] The figure contains typographical issues: 'deploymen t' and 'policiesLive Data' appear without proper spacing, and the label 'Model deploymen t' is split across a line break. Please fix these in the final version.
[§3, Figure 2] The caption 'Total:3x more packagesTop10: 5% morecoverage' is malformed and lacks spacing. The x-axis labels are missing; while the text defines 'coverage' as the fraction of notebooks fully supported, the figure should be self-contained with axis labels and a short definition of the metric in the caption.
[§3, Figure 3] The comparison table is based on 'a few weeks of analysis of marketing material, code skimming, and light experimentation' as stated in footnote 5. Since the systems and their features are dated, the figure should include an explicit 'as of' date and a caveat in the main text that the comparison is subjective and may already be outdated.
[§4.2] The sentence introducing the provenance tables contains a repetition: 'The above table table shows...' Please remove the duplicated word.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is a self-described vision and position paper whose predictions are extrapolations from external trends and early prototypes, not reductions to fitted inputs or authoritative self-citations.

full rationale

This paper is a vision paper, not a derivation chain. The central claim that 'the future is likely cloudy with a high chance of DBMS, and governance throughout' is an explicit extrapolation from the authors' production experience, enterprise conversations, a GitHub notebook analysis, the competitive landscape, and early prototype results. No quantity is fitted and then renamed as a prediction: the 10%-of-developers estimate is an extrapolation from notebook counts, and it is not the load-bearing prediction about where inference is executed or how governance is supplied. The 'score in the DBMS' argument is grounded in a hedged premise ('It appears likely that the most widely studied or promising families of models can be uniformly represented [43,47]') and in early experiments (Figure 4), with the ONNX, MLflow, and TVM references being external formats and compilers rather than a same-author adequacy proof. The paper cites its own companion work, notably [40] for in-DB inference and [48] for notebook analysis, but these citations are not invoked to forbid alternatives or to define the target conclusion into existence; the key benchmark numbers are also presented in this paper itself. There are no equations or fitted parameters whose output equals an input by construction, and the paper contains no imported uniqueness theorem that forces its architectural choice. The main weaknesses, such as the unproven coverage of end-to-end featurization in a uniform intermediate representation and the sparse methodology for Figure 4, are evidence and correctness risks, not circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper's central claim is not a mathematical derivation, so there are no fitted free parameters or invented physical entities. The load-bearing inputs are domain assumptions about ML adoption, uniform model representation, regulatory pressure, and an extrapolation from GitHub notebooks and a small set of customer conversations.

assumptions (4)

domain assumption ML models are software artifacts derived from data, which implies dual governance requirements.
This framing, introduced in Section 2, drives the entire architecture. It is a viewpoint used to justify treating models as both code and data, not an established fact.
domain assumption Most widely used model families can be uniformly represented in an interchange format (e.g., ONNX) and compiled to efficient in-database code.
Stated in Section 1 and Section 4.1 as 'it appears likely'. If this fails for common featurization pipelines or proprietary models, the in-DB scoring prediction is weakened.
domain assumption Regulatory pressure such as GDPR and enterprise governance needs will make provenance and versioning mandatory for ML models.
Used in Sections 1 and 4.2 to justify the governance agenda. Plausible, but not formally established and depends on the future regulatory trajectory.
domain assumption The GitHub notebook analysis and five customer conversations generalize to the broader enterprise ML market.
Underlies the 10-year adoption predictions in Section 3. Public notebooks are not shown to be representative of regulated enterprise workloads, and the paper does not address selection bias in its quantitative projections.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Cloudy with high chance of DBMS: A 10-year prediction for Enterprise-Grade ML." pith.science (2026). https://pith.science/paper/LO4GBJJJ

@misc{pith2026190900084,
  author       = {Pith},
  title        = {Pith review of: Cloudy with high chance of DBMS: A 10-year prediction for Enterprise-Grade ML},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LO4GBJJJ}},
  note         = {Machine review of arXiv:1909.00084}
}

read the original abstract

Machine learning (ML) has proven itself in high-value web applications such as search ranking and is emerging as a powerful tool in a much broader range of enterprise scenarios including voice recognition and conversational understanding for customer support, autotuning for videoconferencing, intelligent feedback loops in large-scale sysops, manufacturing and autonomous vehicle management, complex financial predictions, just to name a few. Meanwhile, as the value of data is increasingly recognized and monetized, concerns about securing valuable data and risks to individual privacy have been growing. Consequently, rigorous data management has emerged as a key requirement in enterprise settings. How will these trends (ML growing popularity, and stricter data governance) intersect? What are the unmet requirements for applying ML in enterprise settings? What are the technical challenges for the DB community to solve? In this paper, we present our vision of how ML and database systems are likely to come together, and early steps we take towards making this vision a reality.

Figures

Figures reproduced from arXiv: 1909.00084 by the authors.

**Figure 2.** Notebook coverage (%) for top-K packages. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** ML Systems in the public cloud and major companies. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Benefits of integrating ONNX Runtime in SQL Server [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

62 extracted references · 61 canonical work pages

[1]

INTRODUCTION Machine learning (ML) has proven itself in high-value consumer applications such as search ranking, recommender systems and spam detection [45, 19]. These applications are built and operated by large teams of experts, and run on massive dedicated infrastructures.1 The (exorbitant) human and hardware costs are well justiﬁed by multi- billion d...

work page Pith review arXiv 2020
[2]

average model accuracy

THE FLOCK VISION In this section, we present our vision for Flock, a reference archi- tecture to support the canonical data science lifecycle for EGML applications. Flock is our vehicle to explore assumptions (§ 3), discover open problems and validate initial solutions (§ 4). We start from a key observation: Machine Learning models are software artifacts ...

work page
[3]

An ML model is software derived from data

THE V ANTAGE POINT Our perspective on what Enterprise-grade ML (EGML) will look like in 10 years is shaped by multiple inputs. First-hand experience. Collectively, the authors of this paper have extensive experience in using ML technologies in production settings, e.g., content recommenders [19], spam ﬁlters [45], big data learning optimizers [51, 54, 37,...

work page 2017
[4]

We speculate that this relates to the extra challenges introduced by EGML, and believe this area is primed for disruptive research, as we discuss in more details in § 4

mature proprietary solutions have stronger support for data management—this is consistent with our own direct experience, and 2) providing complete and usable third-party solutions in this space is non-trivial —or the cloud vendors who already had internal versions of this would have already done so. We speculate that this relates to the extra challenges ...

work page
[5]

automate it, and don’t get me sued

systems for scoring, 3) AutoML solutions, and 4) responsible AI. The systems for training area was initially dominated by big-data extensions [3, 44] ﬁrst and HPC-based solutions [50], and later by parameter servers with bounded staleness [28]. More recent attempts such as ML.NET [20] and TFX [23] have borrowed more profoundly from the dataﬂow/database li...

work page
[6]

We summarize some key challenges below and present some of our ongoing work

OPEN PROBLEMS & ADV ANCES The vision for EGML we presented is an exciting one and presents many challenging problems. We summarize some key challenges below and present some of our ongoing work. We focus on two categories that require attention from the DB community and are not well understood: 1) the systems support required to go from a trained model to...

work page
[7]

CONCLUSION AND CALL TO ACTION We live in interesting times. Database architectures are undergo- ing major transformations to leverage the elasticity of clouds, and a combination of increased regulatory pressures and data sprawl is forcing us to rethink data governance more broadly. Against this backdrop, the rapid adoption of ML in enterprises raises foun...

work page
[8]

https://calcite.apache.org

Apache Calcite. https://calcite.apache.org

work page

Show all 62 references

[9]

https://docs.microsoft.com/en-us/analysis-services/ analysis-services-overview, 2000

Microsoft SQL Server Analysis Services. https://docs.microsoft.com/en-us/analysis-services/ analysis-services-overview, 2000

2000
[10]

https://mahout.apache.org, 2011

Apache Mahout. https://mahout.apache.org, 2011

2011
[11]

https://docs.microsoft.com/en-us/sql/advanced-analytics/, 2017

Microsoft SQL Server Machine Learning Services. https://docs.microsoft.com/en-us/sql/advanced-analytics/, 2017

2017
[12]

https://www.kaggle.com/paultimothymooney/ 2018-kaggle-machine-learning-data-science-survey, 2018

2018 Kaggle Machine Learning and Data Science Survey. https://www.kaggle.com/paultimothymooney/ 2018-kaggle-machine-learning-data-science-survey, 2018

2018
[13]

https: //cloud.google.com/bigquery-ml/docs/bigqueryml-intro, 2018

Google BigQuery ML. https: //cloud.google.com/bigquery-ml/docs/bigqueryml-intro, 2018

2018
[14]

https://eng.uber.com/scaling-michelangelo/, 2018

Scaling Machine Learning at Uber with Michelangelo. https://eng.uber.com/scaling-michelangelo/, 2018

2018
[15]

https://engineering.linkedin.com/blog/2019/01/ scaling-machine-learning-productivity-at-linkedin, 2018

Scaling Machine Learning Productivity at LinkedIn. https://engineering.linkedin.com/blog/2019/01/ scaling-machine-learning-productivity-at-linkedin, 2018

2019
[16]

https://aws.amazon.com/sagemaker/, 2019

Amazon SageMaker. https://aws.amazon.com/sagemaker/, 2019

2019
[17]

https://hadoop.apache.org, 2019

Apache Hadoop. https://hadoop.apache.org, 2019

2019
[18]

https://azure.microsoft.com/ en-us/services/machine-learning-service/, 2019

Azure Machine Learning service. https://azure.microsoft.com/ en-us/services/machine-learning-service/, 2019

2019
[19]

https://cloud.google.com/ai-platform/, 2019

Google Cloud AI Platform. https://cloud.google.com/ai-platform/, 2019

2019
[20]

https://kubeﬂow.org, 2019

Kubeﬂow. https://kubeﬂow.org, 2019

2019
[21]

https://docs.microsoft.com/en-us/NimbusML, 2019

Microsoft Nimbus ML. https://docs.microsoft.com/en-us/NimbusML, 2019

2019
[22]

https://github.com/Microsoft/onnxruntime, 2019

Microsoft ONNX Runtime. https://github.com/Microsoft/onnxruntime, 2019

2019
[23]

https://www.microsoft.com/en-us/sql-server/sql-server-2019, 2019

Microsoft SQL Server 2019. https://www.microsoft.com/en-us/sql-server/sql-server-2019, 2019

2019
[24]

https://pandas.pydata.org/, 2019

pandas: Python Data Analysis Library. https://pandas.pydata.org/, 2019

2019
[25]

C. R. Aberger, A. Lamb, K. Olukotun, and C. Ré. Levelheaded: A uniﬁed engine for business intelligence and linear algebra querying. In ICDE, 2018

2018
[26]

Agarwal, B

D. Agarwal, B. chung Chen, P. Elango, N. Motgi, S. taek Park, R. Ramakrishnan, S. Roy, and J. Zachariah. Online models for content optimization. In NeurIPS. 2009

2009
[27]

Ahmed, S

Z. Ahmed, S. Amizadeh, M. Bilenko, R. Carr, W. Chin, Y . Dekel, X. Dupré, V . Eksarevskiy, E. Erhardt, C. Eseanu, S. Filipi, T. Finley, A. Goswami, M. Hoover, S. Inglis, M. Interlandi, S. Katzenberger, N. Kazmi, G. Krivosheev, P. Luferenko, I. Matantsev, S. Matusevych, S. Mora...

2019
[28]

Atkinson, D

M. Atkinson, D. DeWitt, D. Maier, F. Bancilhon, K. Dittrich, and S. Zdonik. The object-oriented database system manifesto. In Deductive and object-oriented databases . 1990

1990
[29]

https://atlas.apache.org/, 2019

Apache Atlas. https://atlas.apache.org/, 2019

2019
[30]

Baylor, E

D. Baylor, E. Breck, H.-T. Cheng, N. Fiedel, C. Y . Foo, Z. Haque, S. Haykal, M. Ispir, V . Jain, L. Koc, C. Y . Koo, L. Lew, C. Mewald, A. N. Modi, N. Polyzotis, S. Ramesh, S. Roy, S. E. Whang, M. Wicke, J. Wilkiewicz, X. Zhang, and M. Zinkevich. TFX: A tensorﬂow-based produc...

2017
[31]

Carlini, C

N. Carlini, C. Liu, ÃŽlfar Erlingsson, J. Kos, and D. Song. The secret sharer: Evaluating and testing unintended memorization in neural networks, 2018

2018
[32]

T. Chen, T. Moreau, Z. Jiang, L. Zheng, E. Yan, H. Shen, M. Cowan, L. Wang, Y . Hu, L. Ceze, C. Guestrin, and A. Krishnamurthy. TVM: An automated end-to-end optimizing compiler for deep learning. In OSDI, 2018

2018
[33]

T. Q. Chen, Y . Rubanova, J. Bettencourt, and D. K. Duvenaud. Neural ordinary differential equations. In Advances in neural information processing systems, pages 6571–6583, 2018

2018
[34]

Crankshaw, X

D. Crankshaw, X. Wang, G. Zhou, M. J. Franklin, J. E. Gonzalez, and I. Stoica. Clipper: A low-latency online prediction serving system. In NSDI, 2017

2017
[35]

H. Cui, J. Cipar, Q. Ho, J. K. Kim, S. Lee, A. Kumar, J. Wei, W. Dai, G. R. Ganger, P. B. Gibbons, G. A. Gibson, and E. P. Xing. Exploiting bounded staleness to speed up big data analytics. In Usenix ATC, 2014

2014
[36]

Curino, S

C. Curino, S. Krishnan, K. Karanasos, S. Rao, G. M. Fumarola, B. Huang, K. Chaliparambil, A. Suresh, Y . Chen, S. Heddaya, R. Burd, S. Sakalanaga, C. Douglas, B. Ramsey, and R. Ramakrishnan. Hydra: a federated resource manager for data-center scale analytics. In NSDI, 2019

2019
[37]

Floratou, A

A. Floratou, A. Agrawal, B. Graham, S. Rao, and K. Ramasamy. Dhalion: self-regulating stream processing in heron. PVLDB, 2017

2017
[38]

Florescu and D

D. Florescu and D. Kossmann. Storing and querying xml data using an rdmbs. IEEE data engineering bulletin , 22:3, 1999

1999
[39]

https://gdpr-info.eu/, 2016

GDPR. https://gdpr-info.eu/, 2016

2016
[40]

J. M. Hellerstein, C. Ré, F. Schoppmann, D. Z. Wang, E. Fratkin, A. Gorajek, K. S. Ng, C. Welton, X. Feng, K. Li, and A. Kumar. The MADlib Analytics Library: Or MAD Skills, the SQL. PVLDB, 2012

2012
[41]

Hutchison, B

D. Hutchison, B. Howe, and D. Suciu. Laradb: A minimalist kernel for linear and relational algebra computation. In BeyondMR@SIGMOD, 2017

2017
[42]

Hutter, L

F. Hutter, L. Kotthoff, and J. Vanschoren, editors. Automated Machine Learning: Methods, Systems, Challenges . Springer,
[43]

https://mlﬂow.org, 2019

MLﬂow: An open source platform for the machine learning lifecyle. https://mlﬂow.org, 2019

2019
[44]

Jalaparti, C

V . Jalaparti, C. Douglas, M. Ghosh, A. Agrawal, A. Floratou, S. Kandula, I. Menache, J. S. Naor, and S. Rao. Netco: Cache and i/o management for analytics over disaggregated stores. In Proceedings of the ACM Symposium on Cloud Computing , SoCC ’18, pages 186–198, 2018

2018
[45]

Jindal, L

A. Jindal, L. Viswanathan, and K. Karanasos. Query and Resource Optimizations: A Case for Breaking the Wall in Big Data Systems. CoRR, abs/1906.06590, 2019

1906 arXiv
[46]

S. A. Jyothi, C. Curino, I. Menache, S. M. Narayanamurthy, A. Tumanov, J. Yaniv, R. Mavlyutov, I. Goiri, S. Krishnan, J. Kulkarni, and S. Rao. Morpheus: Towards automated slos for enterprise clusters. In OSDI, 2016

2016
[47]

https://www.kaggle.com/datasets, 2019

Kaggle Dataset. https://www.kaggle.com/datasets, 2019

2019
[48]

Karanasos, M

K. Karanasos, M. Interlandi, D. Xin, F. Psallidas, R. Sen, K. Park, I. Popivanov, S. Nakandal, S. Krishnan, M. Weimer, Y . Yu, R. Ramakrishnan, and C. Curino. Extending relational query processing with ML inference. In CIDR, 2020

2020
[49]

Kunft, A

A. Kunft, A. Katsifodimos, S. Schelter, and V . Markl. An intermediate representation for optimizing machine learning pipelines. PVLDB, 2019

2019
[50]

Y . Lee, A. Scolari, B.-G. Chun, M. D. Santambrogio, M. Weimer, and M. Interlandi. PRETZEL: opening the black box of machine learning prediction serving systems. In OSDI, 2018

2018
[51]

Siddiqui, A

T. Siddiqui, A. Jindal, S. Qiao, H. Patel, and W. Le. Cost Models for Serverless Query Processing: Learning, Retroﬁtting, and Our Finding. SIGMOD (to appear), 2020

2020
[52]

https://spark.apache.org/docs/latest/ml-guide.html, 2019

Apache Spark MLLib. https://spark.apache.org/docs/latest/ml-guide.html, 2019

2019
[53]

Narayan, V

S. Narayan, V . T. Ramarao, B. Tseng, M. Weimer, Y . Maeng, and J.-S. Shue. Anti-spam transient entity classiﬁcation. US9442881B1, 2011

2011
[54]

Olston, F

C. Olston, F. Li, J. Harmsen, J. Soyke, K. Gorovoy, L. Lao, N. Fiedel, S. Ramesh, and V . Rajashekhar. Tensorﬂow-serving: Flexible, high-performance ml serving. In Workshop on ML Systems at NIPS 2017 , 2017

2017
[55]

https://onnx.ai

ONNX: Open Neural Network Exchange Format. https://onnx.ai
[56]

Psallidas, Y

F. Psallidas, Y . Zhu, B. Karlas, M. Interlandi, A. Floratou, K. Karanasos, W. Wu, C. Zhang, S. Krishnan, C. Curino, and M. Weimer. Data science through the looking glass and what we found there. ArXiv e-prints, 1912.09536, 2019

1912 arXiv
[57]

Ramachandra, K

K. Ramachandra, K. Park, K. V . Emani, A. Halverson, C. A. Galindo-Legaria, and C. Cunningham. Froid: optimization of imperative programs in a relational database. PVLDB, 2017

2017
[58]

Sergeev and M

A. Sergeev and M. D. Balso. Horovod: fast and easy distributed deep learning in TensorFlow. CoRR, abs/1802.05799, 2018

2018 arXiv
[60]

https://tinyurl.com/sqlserver2017, 2019

Execute external scripts in SQL Server. https://tinyurl.com/sqlserver2017, 2019

2019
[61]

Viswanathan, A

L. Viswanathan, A. Jindal, and K. Karanasos. Query and Resource Optimization: Bridging the Gap. In ICDE, 2018

2018
[62]

C. Wu, A. Jindal, S. Amizadeh, H. Patel, W. Le, S. Qiao, and S. Rao. Towards a Learning Optimizer for Shared Clouds. PVLDB, 2018

2018
[2018]

In press, available at http://automl.org/book

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

INTRODUCTION Machine learning (ML) has proven itself in high-value consumer applications such as search ranking, recommender systems and spam detection [45, 19]. These applications are built and operated by large teams of experts, and run on massive dedicated infrastructures.1 The (exorbitant) human and hardware costs are well justiﬁed by multi- billion d...

work page Pith review arXiv 2020

[2] [2]

average model accuracy

THE FLOCK VISION In this section, we present our vision for Flock, a reference archi- tecture to support the canonical data science lifecycle for EGML applications. Flock is our vehicle to explore assumptions (§ 3), discover open problems and validate initial solutions (§ 4). We start from a key observation: Machine Learning models are software artifacts ...

work page

[3] [3]

An ML model is software derived from data

THE V ANTAGE POINT Our perspective on what Enterprise-grade ML (EGML) will look like in 10 years is shaped by multiple inputs. First-hand experience. Collectively, the authors of this paper have extensive experience in using ML technologies in production settings, e.g., content recommenders [19], spam ﬁlters [45], big data learning optimizers [51, 54, 37,...

work page 2017

[4] [4]

We speculate that this relates to the extra challenges introduced by EGML, and believe this area is primed for disruptive research, as we discuss in more details in § 4

mature proprietary solutions have stronger support for data management—this is consistent with our own direct experience, and 2) providing complete and usable third-party solutions in this space is non-trivial —or the cloud vendors who already had internal versions of this would have already done so. We speculate that this relates to the extra challenges ...

work page

[5] [5]

automate it, and don’t get me sued

systems for scoring, 3) AutoML solutions, and 4) responsible AI. The systems for training area was initially dominated by big-data extensions [3, 44] ﬁrst and HPC-based solutions [50], and later by parameter servers with bounded staleness [28]. More recent attempts such as ML.NET [20] and TFX [23] have borrowed more profoundly from the dataﬂow/database li...

work page

[6] [6]

We summarize some key challenges below and present some of our ongoing work

OPEN PROBLEMS & ADV ANCES The vision for EGML we presented is an exciting one and presents many challenging problems. We summarize some key challenges below and present some of our ongoing work. We focus on two categories that require attention from the DB community and are not well understood: 1) the systems support required to go from a trained model to...

work page

[7] [7]

CONCLUSION AND CALL TO ACTION We live in interesting times. Database architectures are undergo- ing major transformations to leverage the elasticity of clouds, and a combination of increased regulatory pressures and data sprawl is forcing us to rethink data governance more broadly. Against this backdrop, the rapid adoption of ML in enterprises raises foun...

work page

[8] [8]

https://calcite.apache.org

Apache Calcite. https://calcite.apache.org

work page