Pith. sign in

REVIEW 4 major objections 5 minor 48 references

ParquetDB: A Lightweight Python Parquet-Based Database

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

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

Pith's one-line read ParquetDB, a Python database built on Parquet, outperforms SQLite and MongoDB at scale.

desk verdict A genuinely useful Python library for Parquet-backed scientific data, but the benchmark claims, especially the needle-in-a-haystack result, are not yet credible as presented. read the letter →

arxiv 2502.05311 v2 pith:4MRWZERX submitted 2025-02-07 cs.DB physics.data-an

Logan Lang , Eduardo Hernandez , Kamal Choudhary , Aldo H. Romero This is my paper · ORCID
classification cs.DBphysics.data-an
keywords ApacheParquetPyArrowPythondatabasecolumnarstoragepredicatepushdownnesteddatabenchmarkAlexandria3D
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

ParquetDB is a Python database framework that stores records as Apache Parquet files and uses PyArrow for in-memory processing. The paper claims that for large datasets it outperforms SQLite and MongoDB on reads and bulk updates, especially when data is supplied as PyArrow Tables or pandas DataFrames, and that it natively handles nested and complex records that force workarounds in relational and document databases. The authors demonstrate the design on roughly 4.8 million records from the Alexandria 3D Materials Database, showing sub-second queries over millions of rows without maintaining explicit indexes.

What carries the argument

The mechanism that carries the argument is the Parquet row-group and page structure combined with PyArrow's compute and table APIs: queries use predicate pushdown and column projection to read only the needed blocks and columns, and the Parquet footer's per-column statistics let filters skip irrelevant row groups. On top of this, ParquetDB flattens nested dictionaries into dotted-column schemas (such as address.city), automatically generates integer record IDs, and offers a normalization step that rebalances rows across files for consistent performance.

What would settle it

Run the paper's create, read, and update benchmarks on a multi-million-row dataset containing strings and nested structures, feeding each system its natively preferred input format and including a Parquet-native query engine as an additional comparison; if ParquetDB no longer beats or ties SQLite and MongoDB on large reads and bulk updates, the generality claim fails.

Watch

Extended reading notes

Core claim

The central claim is that a lightweight database can be built directly on the Parquet file format rather than on a traditional storage engine, and that this design is faster for large analytic-style workloads than both a relational database (SQLite) and a document database (MongoDB) while offering schema evolution and file portability. In the benchmark, ParquetDB's read time crosses below SQLite and MongoDB once the dataset reaches a few hundred to a thousand rows, and its bulk update time becomes the best near one million rows, despite the overhead of converting Python lists into Arrow tables. The authors attribute this to Parquet's columnar layout, row-group statistics enabling predicate pushdown, and PyArrow's native handling of nested data.

Load-bearing premise

The benchmark workload — synthetic data with 100 integer columns, bulk operations, and Python lists as the input format — represents real usage closely enough that ParquetDB's measured advantage over SQLite and MongoDB carries over to other data types and workloads.

Editorial extensions

If this is right

  • For read-heavy, large-scale workloads, users can expect ParquetDB to load entire datasets and run filtered queries faster than SQLite or MongoDB without creating or maintaining indexes.
  • Nested and complex records (lists, dictionaries, arrays) can be stored and queried directly, avoiding the flattening or BLOB workarounds required by SQLite.
  • Because storage is a directory of Parquet files, transferring or sharing a database means copying files, and schema changes can be applied by adding fields with nulls for existing rows.
  • Bulk updates that rewrite many rows at once are competitive with indexed SQLite and MongoDB, while small single-record updates are much slower due to rewrite overhead.
  • The Alexandria 3D database case shows the design can manage roughly 4.8 million nested records, with column reads and filtered queries returning in about 0.05 to 0.1 seconds.

Reading between the lines

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

  • If the benchmark were repeated with PyArrow Tables or pandas DataFrames as the input format instead of Python lists, ParquetDB's update and create advantages would likely grow, since the paper itself measures Python lists as the slowest input format.
  • The absence of in-place updates means ParquetDB is best suited to append-mostly analytic pipelines; workloads dominated by many small, scattered updates would favor a conventional row-store.
  • The same file-based design could be extended to object storage to give a serverless analytic database with predicate pushdown, but durability and concurrent-writer behavior would need explicit handling.
  • The flattening approach trades deep nesting for queryability; very deeply nested or heavily repeated sub-structures may require the rebuild_nested_struct path, which is expensive on first access.
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.

Referee Report

4 major / 5 minor

Summary. The paper presents ParquetDB, a Python database framework built on Apache Parquet and PyArrow, offering CRUD operations, nested data support, schema evolution, and predicate pushdown. It benchmarks ParquetDB against SQLite and MongoDB on synthetic integer datasets (100 columns, up to one million rows) and demonstrates a real-world application on the Alexandria 3D Materials Database. The central claims are that ParquetDB outperforms SQLite and MongoDB for large read and bulk update workloads, and that it achieves point-query performance comparable to indexed systems without maintaining explicit indexes. The paper also provides a detailed description of the API, data flow, and Parquet file format background.

Significance. If the performance claims are substantiated, ParquetDB offers a lightweight, open-source alternative for managing large scientific datasets, with native support for nested data and no index-maintenance overhead. The provided GitHub repository, the detailed API documentation, and the Alexandria application are valuable assets that enable reproducibility and further evaluation. However, the headline outperformance claim currently rests on benchmark methodology that is not adequately described or verified, particularly around the needle-in-a-haystack experiment, so the significance cannot be fully assessed until these issues are resolved.

major comments (4)
  1. [Sec. 5.4] The needle-in-a-haystack benchmark does not state the actual value of the inserted unique key relative to the data domain (random integers in [0, 1,000,000]). If the inserted value lies outside this range, every row group except the one containing it has min/max statistics that exclude the key, so ParquetDB's constant query time is an artifact of row-group skipping rather than a general no-index point-lookup capability. To support the claim of 'performance comparable to indexed systems', the benchmark should specify the key value, the row-group layout (rows per group and number of groups), and repeat the experiment with an in-range key drawn from the populated domain; otherwise the curve in Fig. 7 is uninterpretable as evidence for predicate-pushdown-based constant-time lookup.
  2. [Sec. 5.1–5.4] All reported benchmark times appear to come from a single run per configuration; no error bars, standard deviations, or repetition counts are provided. The differences in the figures (e.g., ParquetDB read time crossing SQLite around a few thousand rows, and the non-monotonic update curves) could be within run-to-run noise. The paper should report mean and standard deviation over at least 5–10 runs, describe cache/warm-up handling, and state whether timings include process startup. Without this, the headline 'outperforms' claim is not statistically supported.
  3. [Sec. 5.4] The text states that ParquetDB 'ultimately becomes the third most efficient system' and then, in the same section, that it 'achieves query performance comparable to the indexed versions of SQLite and MongoDB.' These two statements are inconsistent: being third of five implies slower than both indexed systems, not comparable. The authors should reconcile the wording and be precise about the ranking (e.g., third after the two indexed systems, ahead of both non-indexed ones) and about what 'comparable' means.
  4. [Sec. 5.2–5.3] The cross-system comparison uses Python lists as the input format for all systems, yet Sec. 5.3 demonstrates that Python lists are the slowest input format for ParquetDB (Fig. 6). While the authors justify this as a 'baseline under suboptimal conditions', the comparison is not symmetric: for SQLite and MongoDB, the Python iteration is the native driver interface, whereas ParquetDB must convert the list to a PyArrow table. This choice, combined with the abstract's qualifier 'especially when using data formats compatible with PyArrow', makes the headline 'outperforms' workload-specific. The conclusion should be scoped to the evaluated input format, or the benchmark should also include a format that is native to ParquetDB.
minor comments (5)
  1. [Sec. 6 vs Abstract] The record count is inconsistent: the abstract says approximately 4.8 million records, while Sec. 6 states 4.3 million unique material structures and later mentions '4.8 million structures'. Please correct the numbers to a single consistent figure.
  2. [Sec. 6.1] The total JSON load time is given as 779.66 seconds at the top of the section and later as 727 seconds; the create time is 238.86 seconds initially and later '246 seconds'. Please make these numbers consistent.
  3. [Sec. 5.2] The sentence 'the timing was taken prior to the executemany operation' is ambiguous; please clarify whether the timer was started before or after the executemany call and what exactly is being measured.
  4. [Sec. 3.2.5 / Table 11] The 'Encoding Techniques' entry for SQLite is listed as 'None', but SQLite uses internal B-tree storage and record formats; please clarify what 'encoding' means in this context to avoid confusion.
  5. [Sec. 5.1] The paper does not mention why DuckDB or other Parquet-native query engines were excluded from the benchmark; a brief justification would help position the contribution against existing systems.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's claims are benchmark measurements against external systems, not derived from fitted or self-referential inputs.

full rationale

This is a systems and benchmarking paper. The central claims — that ParquetDB provides efficient serialization, predicate pushdown, nested data support, and competitive CRUD performance — are supported by measurements of a concrete implementation against external baselines (SQLite and MongoDB). There is no fitted parameter that is later renamed as a prediction, no model whose output is defined in terms of its inputs, and no load-bearing uniqueness theorem. The authors' use of the Alexandria 3D database is an external validation workload drawn from Schmidt et al. citations, not from the authors' own prior work, and the application section is an engineering demonstration rather than a derivation. The benchmarking choice to use Python lists for ParquetDB's cross-system comparison is disclosed as a conservative choice, and it works against ParquetDB rather than in its favor; therefore it does not make the reported performance gains circular. The needle-in-a-haystack benchmark in Sec. 5.4 may raise external-validity concerns about whether the queried unique value falls inside the domain populated by random integers, since row-group min/max statistics can skip all groups only for out-of-domain keys; however, that is a benchmark-design and generalizability concern, not a circularity in which the conclusion is equivalent to the input by construction. The paper also honestly acknowledges limitations such as quasi-durability and manual recovery (Sec. 4.8) and the overhead of reconstructing nested structures (Sec. 6.2.9), further indicating that the authors are not relying on a self-consistent but unfalsifiable framework. Overall, the derivation chain is self-contained: the implementation is real, the baselines are external, and no central claim reduces to a fit, a self-citation, or a definitional identity.

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

ParquetDB is a software artifact, so the ledger contains no fitted numerical parameters. The central claims depend on unverified background assumptions about the Parquet format and PyArrow performance, on the representativeness of the synthetic workload, and on the public availability of the library for independent testing.

assumptions (3)
  • domain assumption The Apache Parquet format provides row-group statistics and predicate pushdown that enable the reported query performance.
    Invoked in Sec 4.1 and Sec 5.4; the paper relies on the format's documented behavior without independently verifying it on the benchmark hardware.
  • domain assumption PyArrow's Python bindings execute the heavy lifting efficiently because the core is written in C++ and can bypass the Python GIL.
    Sec 4.2 asserts this as the backbone; all benchmark results depend on PyArrow's performance characteristics being as stated.
  • domain assumption Random integers in 100 columns are a suitable baseline for extrapolating to other data types.
    Stated in Sec 5.1; the representativeness of this synthetic workload for real nested scientific data is not established.
invented entities (1)
  • ParquetDB library independent evidence
    purpose: Provides a serverless CRUD database interface over Apache Parquet files via PyArrow.
    The library is publicly available on GitHub and via pip, so the claimed behavior can be independently executed and tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ParquetDB: A Lightweight Python Parquet-Based Database." pith.science (2026). https://pith.science/paper/4MRWZERX

@misc{pith2026250205311,
  author       = {Pith},
  title        = {Pith review of: ParquetDB: A Lightweight Python Parquet-Based Database},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4MRWZERX}},
  note         = {Machine review of arXiv:2502.05311}
}
read the original abstract

Traditional data storage formats and databases often introduce complexities and inefficiencies that hinder rapid iteration and adaptability. To address these challenges, we introduce ParquetDB, a Python-based database framework that leverages the Parquet file format's optimized columnar storage. ParquetDB offers efficient serialization and deserialization, native support for complex and nested data types, reduced dependency on indexing through predicate pushdown filtering, and enhanced portability due to its file-based storage system. Benchmarks show that ParquetDB outperforms traditional databases like SQLite and MongoDB in managing large volumes of data, especially when using data formats compatible with PyArrow. We validate ParquetDB's practical utility by applying it to the Alexandria 3D Materials Database, efficiently handling approximately 4.8 million complex and nested records. By addressing the inherent limitations of existing data storage systems and continuously evolving to meet future demands, ParquetDB has the potential to significantly streamline data management processes and accelerate research development in data-driven fields.

Figures

Figures reproduced from arXiv: 2502.05311 by the authors.

Figure 1
Figure 1. Illustration of the serialization and deserialization process for numerical data in CSV and JSON formats. The inefficient ASCII encoding requires multiple bytes for each character, leading to larger file sizes and slower data conversion. Conversion steps, represented by hourglass icons, introduce additional latency as numerical values must be transformed into optimized binary formats for computational use. This proc… view at source ↗
Figure 2
Figure 2. Comparison of search efficiency in an unordered list versus a B-Tree index. The unordered list requires 18 steps to locate the value 89 through a sequential scan, while the B-Tree index reduces this to only 6 steps by leveraging its hierarchical and balanced structure. This illustrates the significant performance improvement that indexing provides, particularly in large datasets, by minimizing the number of operatio… view at source ↗
Figure 3
Figure 3. Parquet File Format Overview. This diagram illustrates the structure of a Parquet file, including Row Groups, Columns, Pages, and the Footer. The metadata associated with each level provides essential details, such as schema, offsets, compression sizes, encryption, and statistical summaries. These metadata components enable efficient data storage, retrieval, and filtering, making Parquet an ideal choice for analytic… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Comparison of Storage Layouts. Row-Based, Column-Based, and Hybrid-Based (Row Group Size = 2). Parquet files utilize a hybrid storage layout, balancing the strengths of row-based and column-based storage by grouping rows together for efficient read and write operations…
Figure 5
Figure 5. Figure 5: Benchmark Create and Read Times for Different Databases. Create time is plotted on the left y-axis, read time on the right y-axis, and the number of rows on the x-axis. A log plot is shown in the inset [PITH_FULL_IMAGE:figures/full_fig_p026_5.png]
Figure 6
Figure 6. Figure 6: Update Time vs. Number of Rows for Different Data Formats in ParquetDB. Formats include Python lists, Python dictionaries, Pandas DataFrames, and PyArrow Tables. Log plot is shown in the inset. A plot of the update performance for each input format is presented in [PI…
Figure 7
Figure 7. Figure 7: Needle-in-a-Haystack Benchmark Results. Time is on the y-axis, number of rows on the x-axis. The log plot is shown in the inset. SQLite and MongoDB are compared with and without indexing [PITH_FULL_IMAGE:figures/full_fig_p028_7.png]
Figure 8
Figure 8. Figure 8: Update Times vs. Number of Rows for Different Databases. Update time is on the y-axis, number of rows on the x-axis, with a log plot in the inset. 29 [PITH_FULL_IMAGE:figures/full_fig_p029_8.png]
Figure 9
Figure 9. Figure 9: Create and JSON Loading Time for the Alexandria 3D Materials Database. This plot shows the time to load the json file (blue) and the time to create the records in ParquetDB (red). 6.1 Loading Data The results of the loading process are depicted in [PITH_FULL_IMAGE:fig…
Figure 10
Figure 10. Figure 10: Performance of Various Operations on the Alexandria 3D Materials Database. A horizontal bar chart is presented, with a log plot in the inset. 6.2.1 Database Normalization 1 db. normalize ( 2 batch_size = 100000 , 3 max_rows_per_file = 500000 , 4 max_rows_per_group = 5…
Figure 11
Figure 11. Figure 11: Analysis of electrical properties in the Alexandria3D database. (11a) Distribution of materials in the Alexandria3D database based on their electrical properties. The materials are classified as metals (Eg = 0 eV), small gap materials (0 < Eg < 0.1 eV), semiconductors…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 48 canonical work pages

  1. [1]

    https://www.sqlite.org/about.html

    About SQLite. https://www.sqlite.org/about.html

    work page

  2. [2]

    https://www.mongodb.com/

    MongoDB: The Developer Data Platform | MongoDB. https://www.mongodb.com/

    work page

  3. [3]

    Genomics Data

    Ephrem Habyarimana and Sofia Michailidou. Genomics Data. In Caj Sodergard, Tomas Mildorf, Ephrem Habyarimana, Arne J. Berre, Jose A. Fernandes, and Christian Zinke-Wehlmann, editors,Big Data in Bioeconomy: Results from the European DataBio Project, pages 69–76. Springer International Publishing, Cham, 2021

    work page 2021

  4. [4]

    Anubhav Jain, Shyue Ping Ong, Geoffroy Hautier, Wei Chen, William Davidson Richards, Stephen Dacek, Shreyas Cholia, Dan Gunter, David Skinner, Gerbrand Ceder, and Kristin A. Persson. Commentary: The Materials Project: A materials genome approach to accelerating materials innovation.APL Materials, 1(1):011002, July 2013

    work page 2013

  5. [5]

    https://www.sqlite.org/famous.html

    Well-Known Users Of SQLite. https://www.sqlite.org/famous.html

    work page

  6. [6]

    https://www.mongodb.com/solutions/customer-case-studies

    Customer Case Studies. https://www.mongodb.com/solutions/customer-case-studies

    work page

  7. [7]

    Do you use the right database for the job? https://www.ssw.com.au/rules/use-the-right-database/

    work page

  8. [8]

    The Evolution of Data Management: From Databases to Big Data Analytics

    work page

Show all 48 references
  1. [9]

    The Evolution of Data Engineering: From Traditional Databases to NoSQL and Beyond

    IABAC®. The Evolution of Data Engineering: From Traditional Databases to NoSQL and Beyond. https://iabac.org/blog/the-evolution-of-data-engineering-from-traditional-databases-to-nosql-and-beyond, August 2023

    2023

  2. [10]

    Evolution of Large-Scale Data Storage - DataScienceCentral.com

    Ovais Naseem. Evolution of Large-Scale Data Storage - DataScienceCentral.com. https://www.datasciencecentral.com/the-evolution-of-large-scale-data-storage-solutions/, March 2024

    2024

  3. [11]

    Accelerating Data Serialization/Deserialization Protocols with In-Network Compute

    Shiyi Cao, Salvatore Di Girolamo, and Torsten Hoefler. Accelerating Data Serialization/Deserialization Protocols with In-Network Compute. In2022 IEEE/ACM International Workshop on Exascale MPI (ExaMPI), pages 22–30, November 2022

    2022

  4. [12]

    CSV vs Parquet vs JSON for Data Science, November 2021

    Stephen. CSV vs Parquet vs JSON for Data Science, November 2021

    2021

  5. [13]

    From JSON to CSV to Parquet: The Rise of Apache Parquet as the Ultimate Data Storage Solution., May 2023

    Sarumathy P. From JSON to CSV to Parquet: The Rise of Apache Parquet as the Ultimate Data Storage Solution., May 2023

    2023

  6. [14]

    Apache Parquet vs JSON | What are the differences? https://stackshare.io/stackups/apache-parquet-vs-json

  7. [15]

    CSV vs Parquet vs JSON vs Avro, October 2022

    Data Engineer. CSV vs Parquet vs JSON vs Avro, October 2022

    2022

  8. [16]

    https://www.linkedin.com/pulse/spark- file-format-showdown-csv-vs-json-parquet-garren-staubli/

    (15) Spark File Format Showdown – CSV vs JSON vs Parquet | LinkedIn. https://www.linkedin.com/pulse/spark- file-format-showdown-csv-vs-json-parquet-garren-staubli/

  9. [17]

    NoSQL: What Are the Differences? https://www.indeed.com/career-advice/career- development/relational-database-vs-nosql

    Relational Database vs. NoSQL: What Are the Differences? https://www.indeed.com/career-advice/career- development/relational-database-vs-nosql

  10. [18]

    What Are the Different Types of Databases? https://www.indeed.com/career-advice/career-development/types-of- databases

  11. [19]

    15 Types of Databases and When to Use Them

    Ashish Pratap Singh. 15 Types of Databases and When to Use Them. https://blog.algomaster.io/p/15-types-of- databases, July 2024

    2024

  12. [20]

    https://parquet.apache.org/

    Parquet. https://parquet.apache.org/

  13. [21]

    https://cassandra.apache.org/

    Apache Cassandra | Apache Cassandra Documentation. https://cassandra.apache.org/

  14. [22]

    TXT - Text Document File

    Kashif Iqbal. TXT - Text Document File. https://docs.fileformat.com/word-processing/txt/, October 2019

    2019

  15. [23]

    What are the disadvantages of storing data to text files in Python? https://www.quora.com/What-are-the- disadvantages-of-storing-data-to-text-files-in-Python

  16. [24]

    CSV Format: History, Advantages and Why It Is Still Popular, September 2021

    2021

  17. [25]

    https://www.creativyst.com/Doc/Articles/CSV/CSV01.shtml

    CSV Comma Separated Value File Format - How To - Creativyst - Explored,Designed,Delivered.(sm). https://www.creativyst.com/Doc/Articles/CSV/CSV01.shtml

  18. [26]

    Common Format and MIME Type for Comma-Separated Values (CSV) Files

    Yakov Shafranovich. Common Format and MIME Type for Comma-Separated Values (CSV) Files. Request for Comments RFC 4180, Internet Engineering Task Force, October 2005

    2005

  19. [27]

    What are the challenges of working with very large CSV files in Python and how can you address them? https://www.linkedin.com/advice/0/what-challenges-working-very-large-csv-files-python-pezmc

  20. [28]

    The most (time) efficient ways to import CSV data in Python, February 2020

    Mihail Yanchev. The most (time) efficient ways to import CSV data in Python, February 2020

    2020

  21. [29]

    https://saturncloud.io/blog/how- to-efficiently-read-large-csv-files-in-python-pandas/, July 2023

    How to Efficiently Read Large CSV Files in Python Pandas | Saturn Cloud Blog. https://saturncloud.io/blog/how- to-efficiently-read-large-csv-files-in-python-pandas/, July 2023. 40 ParquetDB: A Lightweight Python Parquet-Based Database A Preprint

    2023

  22. [30]

    https://haveagreatdata.com/posts/why-you-dont-want-to-use-csv-files/, August 2019

    Why You Don’t Want to Use CSV Files. https://haveagreatdata.com/posts/why-you-dont-want-to-use-csv-files/, August 2019

    2019

  23. [31]

    https://www.json.org/json-en.html

    JSON. https://www.json.org/json-en.html

  24. [32]

    https://www.solarwinds.com/resources/it-glossary/database- index

    WhatisaDatabaseIndex? -ITGlossary|SolarWinds. https://www.solarwinds.com/resources/it-glossary/database- index

  25. [33]

    B-Tree Indexing Basics Explained, May 2024

    Shambhavi Shandilya. B-Tree Indexing Basics Explained, May 2024

    2024

  26. [34]

    https://www.javatpoint.com/binary-search-tree

    Binary Search Tree - javatpoint. https://www.javatpoint.com/binary-search-tree

  27. [35]

    Hash Indexing, January 2024

    Priya Patidar. Hash Indexing, January 2024

    2024

  28. [36]

    https://richardstartin.github.io/posts/how-a-bitmap-index-works, January 2017

    How a Bitmap Index Works. https://richardstartin.github.io/posts/how-a-bitmap-index-works, January 2017

    2017

  29. [37]

    Index Basics: Hidden Costs Associated With Indexes, September 2017

    Eric Cobb. Index Basics: Hidden Costs Associated With Indexes, September 2017

    2017

  30. [38]

    https://www.sqlite.org/serverless.html

    SQLite Is Serverless. https://www.sqlite.org/serverless.html

  31. [39]

    https://www.sciencedirect.com/topics/computer- science/database-server

    Database Server - an overview | ScienceDirect Topics. https://www.sciencedirect.com/topics/computer- science/database-server

  32. [40]

    https://www.ibm.com/topics/cloud-database, July 2023

    What Is a Cloud Database? | IBM. https://www.ibm.com/topics/cloud-database, July 2023

    2023

  33. [41]

    https://www.techtarget.com/searchcloudcomputing/definition/cloud-database

    What is a Cloud Database? Definition and In-Depth Guide | TechTarget. https://www.techtarget.com/searchcloudcomputing/definition/cloud-database

  34. [42]

    ServerlessdatabasecomputingwithAzureCosmosDBandAzureFunctions

    ealsur. ServerlessdatabasecomputingwithAzureCosmosDBandAzureFunctions. https://learn.microsoft.com/en- us/azure/cosmos-db/nosql/serverless-computing-database, August 2024

    2024

  35. [43]

    https://aws.amazon.com/s3/

    Amazon S3 - Cloud Object Storage - AWS. https://aws.amazon.com/s3/

  36. [44]

    https://www.sqlite.org/transactional.html

    SQLite Is Transactional. https://www.sqlite.org/transactional.html

  37. [45]

    https://www.sqlite.org/fileformat.html#b_tree_pages

    Database File Format. https://www.sqlite.org/fileformat.html#b_tree_pages

  38. [46]

    https://arrow.apache.org/docs/python/index.html

    Python — Apache Arrow v17.0.0. https://arrow.apache.org/docs/python/index.html

  39. [47]

    Jonathan Schmidt, Noah Hoffmann, Hai-Chen Wang, Pedro Borlido, Pedro J. M. A. Carriço, Tiago F. T. Cerqueira, SilvanaBotti,andMiguelA.L.Marques. Machine-Learning-AssistedDeterminationoftheGlobalZero-Temperature Phase Diagram of Materials.Advanced Materials, 35(22):2210788, 2023

    2023

  40. [48]

    Apache Parquet-MR version 1.10.1

    Jonathan Schmidt, Noah Hoffmann, Hai-Chen Wang, Pedro Borlido, Pedro J. M. A. Carriço, Tiago F. T. Cerqueira, Silvana Botti, and Miguel A. L. Marques. Large-scale machine-learning-assisted exploration of the whole materials space. October 2022. 41 PARQUET DB: A L IGHTWEIGHT PY...

    2022 arXiv

Pith tools

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