Pith. sign in

REVIEW 4 major objections 6 minor 34 references

Introducing Schema Inference as a Scalable SQL Function [Extended Version]

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read The paper claims schema inference can run as a native SQL function inside a parallel DBMS, and that doing so beats external Spark-based pipelines by up to two orders of magnitude on real datasets.

desk verdict Genuine systems contribution with a headline speedup that is confounded by the ADM-vs-raw-JSON comparison; referee it but require a controlled benchmark. read the letter →

arxiv 2411.13278 v1 pith:PFTNW4D2 submitted 2024-11-20 cs.DB

Calvin Dani , Shiva Jahangiri , Thomas Hütter This is my paper · ORCID
classification cs.DB
keywords schemainferenceJSONSQLfunctionsApacheAsterixDBsemi-structureddataNodatabasesparallelqueryprocessingdiscovery
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

The paper argues that schema inference—automatically deriving a dataset's structure and types from raw semi-structured records—should be a built-in SQL operation rather than a job for an external data-processing pipeline. It introduces two SQL functions in Apache AsterixDB: Open-SI, which scans records and infers a JSON Schema, and Closed-SI, which reads the schema already stored in metadata. The paper reports that on real-world datasets the native implementation runs up to two orders of magnitude faster than existing Spark-based approaches. If this holds, users of NoSQL and semi-structured systems could discover schemas with familiar SQL queries, no data export, and no separate framework.

What carries the argument

The Schema Intermediate Structure (SIS) is a tree whose nodes—Primitive, Array, Multiset, Object, Union—model the AsterixDB Data Model (ADM), a superset of JSON. SIS carries the argument because it makes local-to-global merging simple: local SIS trees built per partition are merged by recursively combining nodes and creating Union nodes when the same field has different types across records. The same structure is converted into JSON Schema through a depth-first traversal that emits 'type', 'properties', 'items', and 'oneOf' keywords. The second piece of machinery is the aggregate-function execution model, which lets the existing parallel query engine pipeline records into local inference and then merge only the small SIS trees, avoiding movement of raw data.

What would settle it

Run the same schema-inference benchmark with AsterixDB reading raw JSON from HDFS, or Spark reading pre-parsed binary records, holding all other settings equal; if the reported two-order gap collapses to a small factor, the load-bearing part of the performance claim is the storage format rather than the SQL-function integration.

Watch

Extended reading notes

Core claim

The central claim is that schema inference can be natively supported as an on-demand SQL function in a DBMS, demonstrated through an implementation in Apache AsterixDB. The Open-SI function works like an aggregate query: records are scanned in parallel across data partitions, each partition builds a local Schema Intermediate Structure (SIS) tree, a central node merges these into a global SIS, and the tree is converted to a JSON Schema. Fields whose types conflict across records become Union nodes under the JSON Schema 'oneOf' construct. Closed-SI avoids scanning entirely by generating the JSON Schema from the dataset's declared metadata. The paper presents this design as the first of its kind and reports that, in experiments on Twitter, GitHub, Yelp, and Pharma datasets, it outperforms Spark-based schema inference methods by an order of magnitude in most cases and by up to two orders of magnitude on the Pharma dataset.

Load-bearing premise

The big speedup comes from comparing the native database scan of already-parsed records with external tools that must parse raw JSON text from disk; if both sides were given the same input format, the advantage could shrink or disappear.

Editorial extensions

If this is right

  • If the paper is right, schema inference becomes a query-time operation on both base datasets and query results, rather than a separate pipeline step.
  • Users can invoke schema inference with a SQL function call, so it composes with filters, joins, and aggregations inside the database.
  • Closed-SI can return a schema for structured datasets in milliseconds by reading metadata, something external tools cannot do without scanning records.
  • Other parallel DBMSs with distributed storage and aggregate execution could adopt the same two-phase local-then-global design for schema inference.

Reading between the lines

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

  • A large part of the reported speedup likely comes from the storage-format comparison: AsterixDB scans already-parsed native ADM records while the Spark baselines parse raw JSON text, as the paper itself credits ADM for avoiding costly parsing; this is an inference about the benchmark, not a paper claim.
  • A testable extension is to run Open-SI on datasets with heavy type heterogeneity and observe whether the growth of Union nodes slows the global merge phase enough to erode the speedup.
  • The SIS merge path could be reused to collect richer statistics such as min/max values and null percentages, turning schema inference into a lightweight profiling tool without a separate scan.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes schema inference (SI) as a native SQL function in Apache AsterixDB. It introduces two operations: Open-SI, which scans records of an open dataset and builds a Schema Intermediate Structure (SIS) tree via local aggregation per partition and global merging, and Closed-SI, which reads a predefined schema from metadata. The authors evaluate speed-up and scale-up on a Twitter dataset and compare against Spark-based SI implementations (Baazizi, Spoth, Mior) on GitHub, Yelp, and Pharma datasets, reporting up to two orders of magnitude speedup.

Significance. If the performance result is substantiated, the paper makes a useful systems contribution: turning SI into a declarative SQL function that runs in parallel inside a DBMS, with a real implementation (publicly available on GitHub). The algorithmic design of a local/global SIS merge is sensible and builds on prior work. The experiments use real-world datasets and address scalability in a multi-node cluster. However, the headline speedup currently rests on a comparison that conflates native execution with the storage format (ADM versus raw JSON parsing), and the lack of variance reporting weakens the empirical claims. The core idea of native SQL-function SI is credible and should be preserved; the experimental evidence needs to be sharpened.

major comments (4)
  1. [§4.6, Expr. 3] The comparison against Spark baselines is confounded by storage representation. AsterixDB scans records already stored in native ADM format, while the Spark implementations parse raw JSON text from HDFS. Section 4.6 explicitly credits the ADM format for avoiding 'the costly parsing Spark implementations require.' Because the abstract and conclusion present the two-orders-of-magnitude result as evidence for the value of the SQL-function integration, the experiment does not isolate the contribution of the proposed function. Please add a controlled condition, e.g., having AsterixDB ingest and scan raw JSON, or having Spark read a deserialized/binary representation, and report the resulting speedup ratios.
  2. [§4.5, Figure 6] Closed-SI is not directly comparable to the Spark baselines. It returns a schema already present in metadata without scanning records, so its 0.03-second runtime is essentially a metadata lookup rather than an inference cost. Presenting Closed-SI in the same aggregated comparison with Spark-based scanners overstates its advantage. Please either separate Closed-SI into its own evaluation or compare it against an equivalent metadata-only approach.
  3. [§4.1] The experiments report only the mean over 10 iterations, with no standard deviation, per-iteration values, or confidence intervals. Given the claim of 'up to two orders of magnitude' and the confounded comparison, variability reporting is necessary to assess whether the observed differences are stable and to support the strength of the claim.
  4. [§3.3, Algorithms 1–4] The pseudo-code is difficult to verify because of font-substitution artifacts in variable names (e.g., 𝑀𝑁𝑀, 𝑂𝑃𝑄𝑅𝑂𝑆, 𝑇𝑈𝑃𝑉𝑆) and inconsistent notation between the algorithms and the surrounding text. Additionally, there is no complexity analysis or memory-footprint characterization of the SIS tree. At minimum, provide readable pseudo-code and state the asymptotic complexity in terms of the number of records, total fields, and tree size.
minor comments (6)
  1. [Throughout] The text contains numerous ligature artifacts (e.g., '!exibility' instead of 'flexibility', '!eld' instead of 'field') that should be fixed in the camera-ready version.
  2. [Table 2] Table 2 lists dataset sizes as '274M', '3.2G', etc. without an explicit unit; please specify whether these are bytes, and clarify whether the size refers to the raw text size or the parsed size.
  3. [§5] The related-work discussion should explicitly distinguish the claimed 'first' native SQL-function SI from Wang et al. [30], which already supports inferring, managing, and querying schemas inside a repository; the current wording may be defensible but needs a precise differentiation.
  4. [§1] The statement that existing SI approaches 'depend on external data processing frameworks, such as Apache Spark' is too broad, since Section 5 describes several standalone algorithms that are not tied to Spark. Please qualify the sentence.
  5. [Figures 4 and 5] The speed-up and scale-up figures report normalized behavior without numerical execution times; including the underlying times (or a table) would allow quantitative verification of the claimed trends.
  6. [§6] The conclusion repeats the 'two orders of magnitude' claim without mentioning the parsing confound identified in Section 4.6; please adjust the wording to match the evidence presented in the evaluation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central claims are an implemented SQL function and measured benchmark comparisons, with no derivation that reduces to its own inputs.

full rationale

This paper makes two kinds of claims: (1) that schema inference can be implemented as a native SQL-style aggregate in Apache AsterixDB, and (2) that this implementation is faster than Spark-based external tools on specific datasets. Neither claim is derived from an input assumption that contains the conclusion. The Open-SI algorithm is described through Algorithms 1–4 and is implemented and benchmarked directly; the performance numbers in Expr. 3 are measured against Baazizi, Spoth, and Mior implementations rather than fitted or predicted from a model, so the speedup cannot be circular by construction. Closed-SI does retrieve schemas from metadata, but the paper explicitly defines this as the operation ('Closed-SI retrieves predefined schemas directly from metadata for structured datasets, skipping the need to scan records'), so it is not disguised inference. The self-citations are limited to background references: [20] is an AsterixDB memory-management paper co-authored by one of the present authors and is used only to describe the system's architecture, and [2] is cited for the SIS structure but is not authored by the present paper's authors. Neither citation carries the load of the central performance or functionality claims, and the code is publicly available on GitHub. The comparison in Section 4.6 does credit the native ADM format with avoiding 'the costly parsing Spark implementations require,' which is a legitimate benchmarking confound about whether the speedup isolates the SQL-function contribution, but it is not a circularity: the speedup is an empirical measurement, not a quantity defined to equal itself or a fitted parameter renamed as a prediction. No step in the paper's argument reduces, by definition or by self-citation, to its own inputs, so the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 1 invented entities

This is a systems paper, so the ledger is mostly domain assumptions about experimental fairness rather than free parameters or invented physical entities. The only new abstraction is SIS, which has an implementation. The key load-bearing assumption is that comparing native ADM scanning to raw JSON parsing in Spark is a fair attribution of the speedup.

assumptions (3)
  • domain assumption The native ADM representation used by Open-SI is semantically equivalent to the raw JSON consumed by the Spark baselines, so the runtime comparison measures the SI function rather than storage format.
    Section 4.5 compares AsterixDB reading stored ADM records with Spark parsing raw JSON from HDFS; Section 4.6 credits the ADM format for avoiding costly parsing, which is exactly the confound.
  • domain assumption The three Spark baselines (Baazizi, Spoth, Mior) are representative, fairly tuned implementations of external schema inference.
    Section 4.1 describes symmetric memory and core allocation, but there is no independent validation that the baseline implementations are optimally configured or that their preprocessing requirements are equal.
  • domain assumption Architectural similarities between AsterixDB and BigQuery, Couchbase, and CockroachDB suffice to generalize the results.
    Section 2.2 argues generalizability from shared horizontal scaling and distributed storage principles without implementing or measuring any other system.
invented entities (1)
  • Schema Intermediate Structure (SIS) tree independent evidence
    purpose: Internal tree representation for local schema aggregation and global merging before JSON Schema conversion
    SIS is implemented in the public AsterixDB fork referenced in [8] and exercised in the reported benchmarks, so it is a concrete software artifact rather than a speculative postulate.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Introducing Schema Inference as a Scalable SQL Function [Extended Version]." pith.science (2026). https://pith.science/paper/PFTNW4D2

@misc{pith2026241113278,
  author       = {Pith},
  title        = {Pith review of: Introducing Schema Inference as a Scalable SQL Function [Extended Version]},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PFTNW4D2}},
  note         = {Machine review of arXiv:2411.13278}
}
read the original abstract

This paper introduces a novel approach to schema inference as an on-demand function integrated directly within a DBMS, targeting NoSQL databases where schema flexibility can create challenges. Unlike previous methods relying on external frameworks like Apache Spark, our solution enables schema inference as a SQL function, allowing users to infer schemas natively within the DBMS. Implemented in Apache AsterixDB, it performs schema discovery in two phases, local inference and global schema merging, leveraging internal resources for improved performance. Experiments with real world datasets show up to a two orders of magnitude performance boost over external methods, enhancing usability and scalability.

Figures

Figures reproduced from arXiv: 2411.13278 by the authors.

Figure 1
Figure 1. Apache AsterixDB architecture 27, 33]. For example, Listing 2 shows the schema for the docu￾ment in Listing 1 in JSON Schema format. The schema consists of an object that contains four properties (i.e., attributes). Next to basic functionality as shown Listing 2, JSON Schema al￾lows for elaborated concepts such as bounding the values of integers, limiting the number of elements in an array, or refer￾encing repeating… view at source ↗
Figure 2
Figure 2. SI Aggregate Query Execution in a Database model records and their schema, and "nally discuss how SIS is employed and implemented within the SI aggregate function. 3.1 Leveraging Aggregate Functions for SI We developed two SI approaches in AsterixDB: Open-SI for semi-structured datasets and Closed-SI for structured datasets. Both approaches allow users to infer schemas easily using simple SQL queries, such as the fo… view at source ↗
Figure 3
Figure 3. Visualization of JSON Trees labeled “A" and “B" [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Speed-Up Evaluation of AsterixDB’s Open- [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Scale-Up Evaluation of AsterixDB’s Open- [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Expr. 3: SI operation Runtime for Datasets Referenced in Section 4.2 Compared to our solution, these approaches have been imple￾mented and analyzed in a standalone fashion. Consequently, users have to manually extract and pre-process the data in order to compute a sche…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 30 canonical work pages

  1. [1]

    Wail Y Alkowaileet, Sattam Alsubaiee, and Michael J Carey. [n. d.]. An LSM- based Tuple Compaction Framework for Apache AsterixDB. Proceedings of the VLDB Endowment 13, 9 ([n. d.])

    work page

  2. [2]

    Columnar Formats for Schemaless LSM-based Document Stores

    Wail Y. Alkowaileet and Michael J. Carey. 2021. Columnar Formats for Schemaless LSM-based Document Stores. CoRR abs/2111.11517 (2021). arXiv:2111.11517 https://arxiv.org/abs/2111.11517

    work page Pith review arXiv 2021

  3. [3]

    Sattam Alsubaiee, Yasser Altowim, Hotham Altwaijry, Alexander Behm, Vinayak Borkar, Yingyi Bu, Michael Carey, Inci Cetindil, Madhusudan Cheelangi, Khurram Faraaz, Eugenia Gabrielova, Raman Grover, Zachary Heilbron, Young-Seok Kim, Chen Li, Guangqiang Li, Ji Mahn Ok, Nicola Onose, Pouria Pirzadeh, Vassilis Tsotras, Rares Vernica, Jian Wen, and Till Westman...

    work page 2014

  4. [4]

    Amazon Web Services, Inc. n.d.. Key-Value Database: Overview of Key- Value NoSQL Databases on A WS. https://aws.amazon.com/nosql/key- value/ Accessed: 2024-10-04

    work page 2024

  5. [5]

    Apache Spark. 2024. RDD Programming Guide. https://spark.apache.org/ docs/latest/rdd-programming-guide.html. Accessed: 2024-10-01

    work page 2024

  6. [6]

    Apache AsterixDB. [n. d.]. The Asterix Data Model (ADM). https: //nightlies.apache.org/asterixdb/datamodel.html. Accessed: 2024-10-09

    work page 2024

  7. [7]

    Mohamed-Amine Baazizi, Houssem Ben Lahmar, Dario Colazzo, Giorgio Ghelli, and Carlo Sartiani. 2017. Schema Inference for Massive JSON Datasets. In Extending Database Technology (EDBT). Venise, Italy. https: //doi.org/10.5441/002/edbt.2017.21

    work page doi:10.5441/002/edbt.2017.21 2017

  8. [8]

    Dani Calvin and contributors. 2024. AsterixDB Schema Infer- ence. https://github.com/calvin-dani/asterixdb-schema-inference/tree/ schema-inference. Accessed: 2024-10-08

    work page 2024

Show all 34 references
  1. [9]

    Dario Colazzo, Giorgio Ghelli, and Carlo Sartiani. 2012. Typing Massive JSON Datasets. https://api.semanticscholar.org/CorpusID:12989741

    2012

  2. [10]

    Couchbase, Inc. 2023. Document Data Model. https://docs.couchbase. com/server/current/learn/data/document-data-model.html. Accessed: 2024-09-08

    2023

  3. [11]

    Couchbase, Inc. n.d.. Key-Value Database: Concepts and How It Works. https://www.couchbase.com/resources/concepts/key-value-database/ Ac- cessed: 2024-10-04

    2024

  4. [12]

    Michael DiScala and Daniel J. Abadi. 2016. Automatic Generation of Nor- malized Relational Schemas from Nested Key-Value Data. In Proceedings of the 2016 International Conference on Management of Data (San Francisco, California, USA) (SIGMOD ’16). Association for Computing Mac...

    2016

  5. [14]

    Angelo Augusto Frozza, Ronaldo dos Santos Mello, and Felipe de Souza da Costa. 2018. An approach for schema extraction of JSON and extended JSON document collections. In 2018 IEEE International Conference on Infor- mation Reuse and Integration (IRI) . IEEE, 356–363

    2018

  6. [15]

    Minos Garofalakis, Aristides Gionis, Rajeev Rastogi, Sridhar Seshadri, and Kyuseok Shim. 2000. XTRACT: A system for extracting document type descriptors from XML documents. In Proceedings of the 2000 ACM SIGMOD international conference on Management of data . 165–176

    2000

  7. [16]

    Google Cloud. 2023. New Blog Series: BigQuery Explained - Overview. https://cloud.google.com/blog/products/data-analytics/new- blog-series-bigquery-explained-overview. Accessed: 2024-09-08

    2023

  8. [17]

    Javier Luis Cánovas Izquierdo and Jordi Cabot. 2013. Discovering Implicit Schemas in JSON Data. In Proc. ICWE. 68–83

    2013

  9. [18]

    JSON-Schema. 2023. JSON Schema. https://json-schema.org

    2023

  10. [19]

    JSON Schema Organization. 2020. JSON Schema: Core De"nitions and Terminology. https://json-schema.org/draft/2020-12/json-schema-core. html Accessed: 2024-10-09

    2020

  11. [20]

    Carey, Murtadha Hubail, Shiva Jahangiri, Jianfeng Jia, Chen Li, Chen Luo, Ian Maxon, and Pouria Pirzadeh

    Taewoo Kim, Alexander Behm, Michael Blow, Vinayak Borkar, Yingyi Bu, Michael J. Carey, Murtadha Hubail, Shiva Jahangiri, Jianfeng Jia, Chen Li, Chen Luo, Ian Maxon, and Pouria Pirzadeh. 2020. Robust and ef- "cient memory management in Apache AsterixDB. Software: Practice and E...

    2020 doi

  12. [21]

    Meike Klettke, Uta Störl, and Stefanie Scherzinger. 2015. Schema Extraction and Structural Outlier Detection for JSON-based NoSQL Data Stores. In Proc. BTW, Vol. P-241. GI, 425–444

    2015

  13. [22]

    Michael J. Mior. 2023. JSONoid: Monoid-based Enrichment for Con"g- urable and Scalable Data-Driven Schema Discovery. ArXiv abs/2307.03113 (2023). https://api.semanticscholar.org/CorpusID:259360810

    2023 arXiv

  14. [23]

    MongoDB, Inc. n.d.. Key-Value Database: What it is and How it Works. https://www.mongodb.com/resources/basics/databases/key-value- database Accessed: 2024-10-04

    2024

  15. [24]

    Reutter, Fernando Suarez, Martín Ugarte, and Do- magoj Vrgo%

    Felipe Pezoa, Juan L. Reutter, Fernando Suarez, Martín Ugarte, and Do- magoj Vrgo%. 2016. Foundations of JSON Schema. In Proceedings of the 25th International Conference on World Wide Web (Montréal, Québec, Canada) (WWW ’16). International World Wide Web Conferences Steer- ing...

    2016

  16. [25]

    Roam Research. 2024. Prescription-Based Prediction Dataset. https://www. kaggle.com/datasets/roamresearch/prescriptionbasedprediction Accessed: 2024-10-03

    2024

  17. [26]

    Diego Sevilla Ruiz, Severino Feliciano Morales, and Jesús García Molina

  18. [27]

    William Spoth, Oliver Kennedy, Ying Lu, Beda Hammerschmidt, and Zhen Hua Liu. 2021. Reducing Ambiguity in Json Schema Discovery. In Proceedings of the 2021 International Conference on Management of Data(Vir- tual Event, China) (SIGMOD ’21). Association for Computing Machinery,...

    2021

  19. [28]

    John Tukey. 2024. GitHub Dataset. https://www.kaggle.com/datasets/ johntukey/github-dataset Accessed: 2024-10-03

    2024

  20. [29]

    Jim Walker and Michelle Gienow. 2024. What is distributed SQL? An evolution of the database. (2024). https://www.cockroachlabs.com/blog/ what-is-distributed-sql/ Last edited on February 1, 2024

    2024

  21. [30]

    Lanjun Wang, Shuo Zhang, Juwei Shi, Limei Jiao, Oktie Hassanzadeh, Jia Zou, and Chen Wangz. 2015. Schema management for document stores. Proc. VLDB Endow. 8, 9 (may 2015), 922–933. https://doi.org/10.14778/ 2777598.2777601

    2015

  22. [31]

    Martin Wischenbart, Stefan Mitsch, Elisabeth Kapsammer, Angelika Kusel, Birgit Pröll, Werner Retschitzegger, Wieland Schwinger, Johannes Schön- böck, Manuel Wimmer, and Stephan Lechner. 2012. User pro"le inte- gration made easy: model-driven extraction and transformation of so...

    2012

  23. [32]

    Yelp, Inc. 2024. Yelp Open Dataset. https://www.yelp.com/dataset/ download Accessed: 2024-10-03

    2024

  24. [33]

    Joohyung Yun, Byungchul Tak, and Wook-Shin Han. 2024. ReCG: Bottom- up JSON Schema Discovery Using a Repetitive Cluster-and-Generalize Framework. Proceedings of the VLDB Endowment 17, 11 (2024), 3538–3550

    2024

  25. [34]

    Xin, Patrick Wendell, Tathagata Das, Michael Armbrust, Ankur Dave, Xiangrui Meng, Josh Rosen, Shivaram Venkatara- man, Michael J

    Matei Zaharia, Reynold S. Xin, Patrick Wendell, Tathagata Das, Michael Armbrust, Ankur Dave, Xiangrui Meng, Josh Rosen, Shivaram Venkatara- man, Michael J. Franklin, Ali Ghodsi, Joseph Gonzalez, Scott Shenker, and Ion Stoica. 2016. Apache Spark: a uni"ed engine for big data pr...

    2016 doi

  26. [2015]

    Inferring Versioned Schemas from NoSQL Databases and Its Appli- cations. In Proc. ER. 467–480

Pith tools

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