A curated, GitHub-ready reading list and implementation playbook for database-system papers around SIGMOD/PODS 2026, focused on how to turn research ideas into a practical repository metadata database.
This repository is intentionally selective. It does not try to list every accepted paper. It selects papers and company systems that map cleanly to a repo/database management architecture: AI-in-DB, optimizer validation, generated artifacts as materialized views, long-lived metadata identity, graph lineage, vector/RAG evaluation, and distributed metadata storage.
Scope note: this repository stores links, summaries, and implementation ideas. It does not redistribute paper PDFs.
Build the repository database in this order:
- Stable metadata foundation: files, versions, paths, content hashes, symbols, docs, schemas.
- Generated artifacts as materialized views: every generated
*.jsonl,*.tsv,*.mmd, summary, and report has lineage and freshness state. - AI operations with validation: every LLM/AI call has cost, confidence, cascade stage, and verification status.
- Graph + lineage + vector layer: code, docs, schemas, tests, proofs, and embeddings become typed nodes and edges.
- Benchmark before trusting RAG: measure recall, latency, memory, update cost, and factual consistency together.
- Scale out only when needed: start with PostgreSQL; add routers, shards, replicas, Neo4j, or distributed SQL only when workload evidence justifies it.
data/selected_papers.json is the canonical catalog. Generated views and examples are checked with:
make checkAfter editing the canonical catalog, regenerate derived files:
make generate
make checkFor SQL examples, make sql-check always runs static checks. If DATABASE_URL points to an empty scratch PostgreSQL database, it also loads docs/repo-db-schema.sql, examples/seed.sql, examples/queries.sql, and examples/explain.sql.
| Company | Adoptable idea | Key papers / source links | Repo / DB translation |
|---|---|---|---|
| Alibaba | Connect query execution, vector search, lineage, and code-to-SQL visibility into one metadata fabric. | Learned Query Optimizer in Alibaba MaxCompute: Challenges, Analysis, and Solutions LindormVector: A Distributed Vector Engine on a Cloud-Native Multi-Model NoSQL Database SQLens: Continuous Code-to-SQL Visibility in the Wild NebulaSQL: A Large-scale Feature Computation System for Online Recommendation |
Store graph_edges, lineage_edges, query_runs, vector_index_entries, and code_to_sql_edges as connected concepts. |
| ByteDance | Represent code, docs, schemas, tests, proofs, embeddings, and execution traces as graph-connected multimodal objects. | ByteHouse: ByteDance’s Cloud-Native Data Warehouse for Real-Time Multimodal Data Analytics ByteGraph-Dione: An Adaptive Dual-Format Graph Engine with Hotspot Awareness and Transaction Efficiency for Production-Scale Workloads G2+D: A High Performance Distributed Graph Mining System |
Model repository entities in repo_nodes, connect them through graph_edges, and store multimodal evidence in multimodal_chunks. |
| Databricks | Treat generated files, summaries, diagrams, JSONL, TSV, and Mermaid outputs as materialized views over source repository state. | Enzyme: Incremental View Maintenance for Data Engineering Enzyme: Incremental View Maintenance With Spark Declarative Pipelines |
generated_artifacts, artifact_dependencies, refresh_plans, and stale_flags should track source hashes, refresh plans, stale status, and incremental refresh metadata. |
| Optimize metadata identity for decades: stable keys, versioned paths, immutable content hashes, and forward-compatible columns. | Twenty Years of Bigtable Twenty Years of Bigtable |
Use file_id, path, sha256, version_id, valid_from, valid_to, and path_history so metadata remains stable across renames and rebuilds. |
|
| Microsoft | Use LLMs for proposal generation, but rely on EXPLAIN plans, replay, benchmarks, and optimizer tooling for acceptance. | Evaluating the Practical Effectiveness of LLM-Driven Index Tuning with Microsoft Database Tuning Advisor Bitmap Filtering in the Fabric Data Warehouse CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric ConDABench: Interactive Evaluation of Language Models for Data Analysis |
LLM-generated index/schema advice must pass EXPLAIN, benchmark runs, workload replay, and rollback checks before being merged. |
| Oracle | Keep developer-friendly document formats, but project them into relational tables for querying, constraints, migration, and governance. | From JSON to Duality: Automated Application Migration from Document to Relational Databases From JSON to Duality: Automated Application Migration from Document to Relational Databases |
Normalize raw documents into docs, parsed objects into json_objects, schema definitions into schemas, and dual views through document_projection_map. |
| Snowflake | Treat LLM/AI calls as first-class database operators with measurable cost, quality, confidence, and fallback behavior. | Streaming Model Cascades for Semantic SQL Cortex AISQL: A Production SQL Engine for Unstructured Data |
ai_runs, model_costs, confidence, cascade_stage, and verified should be stored alongside query and artifact metadata. |
| AWS | Start with normal PostgreSQL semantics, then add router, shard, replica, and distributed transaction concepts only when scale demands it. | Aurora PostgreSQL Limitless Database: Building a Highly Scalable OLTP Database Aurora PostgreSQL Limitless Database: Building a Highly Scalable OLTP Database |
Begin with single PostgreSQL. When repositories or organizations grow, introduce logical routers, project shards, replicas, and distributed transaction logs. |
| IBM | Measure RAG as a whole system: embedding, indexing, retrieval, reranking, generation, latency, memory, update cost, and factual consistency. | RAGPerf: An End-to-End Benchmarking Framework for Retrieval-Augmented Generation Systems Fabric-X: Scaling Hyperledger Fabric for Asset Exchange |
Persist rag_eval_runs, context_recall, latency_ms, memory_mb, update_cost_ms, groundedness, and factual_consistency. |
| Neo4j | Start with graph_edges in PostgreSQL, then mirror to Neo4j when multi-hop traversal and graph algorithms dominate workload cost. |
RIOT: Replicated Independently-Ordered Transactions Neo4j Research: RIOT RIOT: Replicated Independently-Ordered Transactions |
Use PostgreSQL graph_edges first. Add a Neo4j mirror only after multi-hop queries, path ranking, or graph algorithms justify it. |
| Cockroach Labs | Leader leases and range-level consensus matter once repository metadata becomes a shared, high-availability service. | Scalable Leader Leases For Multi Consensus Groups in CockroachDB Scalable Leader Leases For Multi Consensus Groups in CockroachDB |
Use metadata_ranges, leaseholders, consensus_groups, and range-health observations when evolving toward distributed metadata storage. |
| Tencent | Plan for multiple languages, package managers, schema styles, artifact types, and workload classes in large monorepos. | TDSQL-Boundless: A Distributed Database System for Large-scale Heterogeneous Multi-Table Workloads TDSQL-Boundless: A Distributed Database System for Large-scale Heterogeneous Multi-Table Workloads |
Use project_shards, package_groups, heterogeneous_tables, and workload-class routing for multi-language monorepo metadata. |
Start with Snowflake, Microsoft, and Alibaba. They give the cleanest guidance for integrating model calls, learned optimization, and validation into database workflows. The repo-level rule is simple: AI output is data, not magic. Store its cost, confidence, input hash, output hash, and verification state.
Read Databricks Enzyme next. A generated repository artifact should behave like a materialized view: it has dependencies, freshness, a refresh plan, and a rebuild history.
Read Google Bigtable and AWS Aurora Limitless together. Bigtable argues for stable identity over long time spans; Aurora shows how relational compatibility can coexist with horizontal scale. For a GitHub-scale repository metadata DB, use stable IDs and PostgreSQL first, then scale out.
Read Alibaba, ByteDance, and Neo4j as a cluster. Keep a relational graph_edges table first. Add specialized graph/vector infrastructure only when query patterns demand it.
Use IBM/RAGPerf as the evaluation discipline. Do not evaluate repository RAG only by retrieval recall. Add latency, memory, update cost, and factual consistency.
Read Cockroach Labs and Tencent last. Their ideas matter when metadata is a critical, multi-tenant service with many concurrent readers/writers and heterogeneous workloads.
docs/curated-table.md: detailed table with paper links, mapping, and caveats.docs/implementation-playbook.md: step-by-step architecture plan.docs/schema-design.md: conceptual schema and entity definitions.docs/repo-db-schema.sql: PostgreSQL-flavored starter DDL.docs/provenance.md: source metadata and interpretation boundary.docs/database-optimizer-notes.md: query-plan and index validation guidance.docs/source-links.md: generated source index with provenance fields.docs/topic-map.md: map from themes to papers and database objects.docs/architecture.mmd: Mermaid architecture diagram.docs/paper-notes/: one note per company.data/selected_papers.csv: machine-readable CSV.data/selected_papers.json: canonical machine-readable JSON.examples/: seed data, sample queries, EXPLAIN wrappers, and small JSONL/TSV examples.schemas/selected-paper.schema.json: catalog data contract.AGENTS.md: repeatable agent/contributor workflow.
files / file_versions / path_history
-> symbols / docs / schemas / generated_artifacts
-> graph_edges / lineage_edges / query_runs
-> ai_runs / model_costs / verification_events
-> vector_index_entries / rag_eval_runs
-> project_shards / consensus_groups / replicas (later)
A paper was selected if it answered at least one implementation question:
- How should AI/LLM calls be represented in a database system?
- How should generated artifacts stay fresh and reproducible?
- How should repository metadata survive path changes and long-term evolution?
- How should graph, vector, and lineage metadata be connected?
- How should RAG be benchmarked as a full system?
- When should a metadata database become distributed?
Use this as a seed repository. Add new papers only when they change a concrete design decision, table, benchmark, or operational rule.