selected_papers.json

[
  {
    "company": "Alibaba",
    "theme": "Unified optimizer, vector, lineage, and SQL visibility",
    "adoptable_idea": "Connect query execution, vector search, lineage, and code-to-SQL visibility into one metadata fabric.",
    "key_papers": [
      {
        "title": "Learned Query Optimizer in Alibaba MaxCompute: Challenges, Analysis, and Solutions",
        "url": "https://arxiv.org/abs/2602.07336",
        "type": "primary / arXiv",
        "source_url": "https://arxiv.org/abs/2602.07336",
        "last_verified": "2026-06-29",
        "source_type": "arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2602.07336",
        "claim_scope": "paper metadata"
      },
      {
        "title": "LindormVector: A Distributed Vector Engine on a Cloud-Native Multi-Model NoSQL Database",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      },
      {
        "title": "SQLens: Continuous Code-to-SQL Visibility in the Wild",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      },
      {
        "title": "NebulaSQL: A Large-scale Feature Computation System for Online Recommendation",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "A useful repository database should answer not only “what files exist?” but also “which code produced this SQL, which query produced this table, which vector index serves this search?”",
    "repo_db_translation": "Store `graph_edges`, `lineage_edges`, `query_runs`, `vector_index_entries`, and `code_to_sql_edges` as connected concepts.",
    "first_schema_objects": [
      "query_runs",
      "lineage_edges",
      "vector_index_entries",
      "code_to_sql_edges",
      "optimizer_observations"
    ],
    "do_now": "Log every generated SQL statement with source file, function/symbol, input artifact, execution plan, output artifact, and cost.",
    "do_later": "Use historical executions and repository context to rank candidate plans and queries.",
    "watch_out": "Vector search without lineage becomes hard to debug; lineage without query runs becomes hard to trust.",
    "priority": "P0"
  },
  {
    "company": "ByteDance",
    "theme": "Repository as production-scale graph and multimodal warehouse",
    "adoptable_idea": "Represent code, docs, schemas, tests, proofs, embeddings, and execution traces as graph-connected multimodal objects.",
    "key_papers": [
      {
        "title": "ByteHouse: ByteDance’s Cloud-Native Data Warehouse for Real-Time Multimodal Data Analytics",
        "url": "https://arxiv.org/abs/2602.08226",
        "type": "primary / arXiv",
        "source_url": "https://arxiv.org/abs/2602.08226",
        "last_verified": "2026-06-29",
        "source_type": "arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2602.08226",
        "claim_scope": "paper metadata"
      },
      {
        "title": "ByteGraph-Dione: An Adaptive Dual-Format Graph Engine with Hotspot Awareness and Transaction Efficiency for Production-Scale Workloads",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      },
      {
        "title": "G2+D: A High Performance Distributed Graph Mining System",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Large repositories are not just folders. They are multimodal graphs: code calls code, docs describe APIs, tests verify behavior, schemas constrain data, embeddings support retrieval.",
    "repo_db_translation": "Model repository entities in `repo_nodes`, connect them through `graph_edges`, and store multimodal evidence in `multimodal_chunks`.",
    "first_schema_objects": [
      "repo_nodes",
      "graph_edges",
      "multimodal_chunks",
      "execution_traces",
      "embedding_runs"
    ],
    "do_now": "Create typed nodes and edges for files, symbols, imports, tests, docs, schemas, and embeddings.",
    "do_later": "Add graph-mining jobs for hotspot files, central APIs, dead edges, and risky dependency clusters.",
    "watch_out": "A graph without stable IDs becomes noisy. Anchor nodes to stable file/symbol IDs and content hashes.",
    "priority": "P0"
  },
  {
    "company": "Databricks",
    "theme": "Generated artifacts as materialized views",
    "adoptable_idea": "Treat generated files, summaries, diagrams, JSONL, TSV, and Mermaid outputs as materialized views over source repository state.",
    "key_papers": [
      {
        "title": "Enzyme: Incremental View Maintenance for Data Engineering",
        "url": "https://arxiv.org/abs/2603.27775",
        "type": "primary / arXiv",
        "source_url": "https://arxiv.org/abs/2603.27775",
        "last_verified": "2026-06-29",
        "source_type": "arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2603.27775",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Enzyme: Incremental View Maintenance With Spark Declarative Pipelines",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "A repository with generated artifacts needs freshness, dependency tracking, and refresh plans. Materialized-view thinking gives a clean model for rebuilds.",
    "repo_db_translation": "`generated_artifacts`, `artifact_dependencies`, `refresh_plans`, and `stale_flags` should track source hashes, refresh plans, stale status, and incremental refresh metadata.",
    "first_schema_objects": [
      "generated_artifacts",
      "artifact_dependencies",
      "refresh_plans",
      "refresh_runs",
      "stale_flags"
    ],
    "do_now": "Record source file hashes for every generated artifact and mark artifacts stale when dependencies change.",
    "do_later": "Add an incremental refresh planner that refreshes only affected artifacts rather than rebuilding everything.",
    "watch_out": "Without lineage, generated docs silently drift from the source repository.",
    "priority": "P0"
  },
  {
    "company": "Google",
    "theme": "Long-lived key-value / wide-column metadata design",
    "adoptable_idea": "Optimize metadata identity for decades: stable keys, versioned paths, immutable content hashes, and forward-compatible columns.",
    "key_papers": [
      {
        "title": "Twenty Years of Bigtable",
        "url": "https://research.google/pubs/twenty-years-of-bigtable/",
        "type": "primary / Google Research",
        "source_url": "https://research.google/pubs/twenty-years-of-bigtable/",
        "last_verified": "2026-06-29",
        "source_type": "google_research",
        "venue_or_track": "Google Research",
        "doi_or_arxiv": "",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Twenty Years of Bigtable",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Repository metadata is historical by nature. Paths move, files rename, schemas evolve, and hashes remain the best anchor for content identity.",
    "repo_db_translation": "Use `file_id`, `path`, `sha256`, `version_id`, `valid_from`, `valid_to`, and `path_history` so metadata remains stable across renames and rebuilds.",
    "first_schema_objects": [
      "files",
      "file_versions",
      "path_history",
      "content_hashes",
      "metadata_cells"
    ],
    "do_now": "Separate logical file identity from mutable path and immutable content hash.",
    "do_later": "Partition metadata by repository, time, and content-hash prefix for large-scale scans.",
    "watch_out": "Do not use path as the only primary key. Paths are names, not identities.",
    "priority": "P0"
  },
  {
    "company": "Microsoft",
    "theme": "LLM recommendations must be validated by database tooling",
    "adoptable_idea": "Use LLMs for proposal generation, but rely on EXPLAIN plans, replay, benchmarks, and optimizer tooling for acceptance.",
    "key_papers": [
      {
        "title": "Evaluating the Practical Effectiveness of LLM-Driven Index Tuning with Microsoft Database Tuning Advisor",
        "url": "https://arxiv.org/abs/2603.09181",
        "type": "primary / arXiv",
        "source_url": "https://arxiv.org/abs/2603.09181",
        "last_verified": "2026-06-29",
        "source_type": "arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2603.09181",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Bitmap Filtering in the Fabric Data Warehouse",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      },
      {
        "title": "CoddSpeed: Hardware Accelerated Query Processing in Microsoft Fabric",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      },
      {
        "title": "ConDABench: Interactive Evaluation of Language Models for Data Analysis",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "LLMs can suggest useful index or schema changes, but production databases need repeatable validation because model output has variance and can regress workloads.",
    "repo_db_translation": "LLM-generated index/schema advice must pass `EXPLAIN`, benchmark runs, workload replay, and rollback checks before being merged.",
    "first_schema_objects": [
      "index_advice",
      "explain_plans",
      "benchmark_runs",
      "workload_replays",
      "validation_results"
    ],
    "do_now": "Create a gate: LLM proposal -> generated migration -> EXPLAIN delta -> benchmark -> replay -> approval.",
    "do_later": "Train a local rule library from LLM-generated hypotheses that repeatedly pass validation.",
    "watch_out": "Never merge index advice directly from a model. Treat it as a candidate patch, not a decision.",
    "priority": "P0"
  },
  {
    "company": "Oracle",
    "theme": "Normalize documents, JSON, Markdown, and YAML into relational projections",
    "adoptable_idea": "Keep developer-friendly document formats, but project them into relational tables for querying, constraints, migration, and governance.",
    "key_papers": [
      {
        "title": "From JSON to Duality: Automated Application Migration from Document to Relational Databases",
        "url": "https://dl.acm.org/doi/10.1145/3788853.3803096",
        "type": "ACM DOI",
        "source_url": "https://dl.acm.org/doi/10.1145/3788853.3803096",
        "last_verified": "2026-06-29",
        "source_type": "acm_doi",
        "venue_or_track": "ACM Digital Library",
        "doi_or_arxiv": "10.1145/3788853.3803096",
        "claim_scope": "paper metadata"
      },
      {
        "title": "From JSON to Duality: Automated Application Migration from Document to Relational Databases",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Markdown, JSON, and YAML are convenient for authors but weak for joins, constraints, and governance. Relational projection gives queryability without deleting the original documents.",
    "repo_db_translation": "Normalize raw documents into `docs`, parsed objects into `json_objects`, schema definitions into `schemas`, and dual views through `document_projection_map`.",
    "first_schema_objects": [
      "docs",
      "json_objects",
      "schemas",
      "relational_projection",
      "document_projection_map"
    ],
    "do_now": "Parse frontmatter, JSON, YAML, headings, links, and code blocks into typed relational projections.",
    "do_later": "Generate migration plans from loose documents to constrained schemas with reversible mappings.",
    "watch_out": "Do not throw away source documents. Store raw content, parsed structure, and normalized projection together.",
    "priority": "P0"
  },
  {
    "company": "Snowflake",
    "theme": "AI operators inside the database optimizer",
    "adoptable_idea": "Treat LLM/AI calls as first-class database operators with measurable cost, quality, confidence, and fallback behavior.",
    "key_papers": [
      {
        "title": "Streaming Model Cascades for Semantic SQL",
        "url": "https://arxiv.org/abs/2604.00660",
        "type": "primary / arXiv",
        "source_url": "https://arxiv.org/abs/2604.00660",
        "last_verified": "2026-06-29",
        "source_type": "arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2604.00660",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Cortex AISQL: A Production SQL Engine for Unstructured Data",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Semantic SQL makes AI inference part of query execution. That means the repository database should not hide prompts, models, costs, confidence, or verification state in logs only; they belong in normalized tables.",
    "repo_db_translation": "`ai_runs`, `model_costs`, `confidence`, `cascade_stage`, and `verified` should be stored alongside query and artifact metadata.",
    "first_schema_objects": [
      "ai_runs",
      "model_costs",
      "model_cascade_stages",
      "semantic_operator_results",
      "verification_events"
    ],
    "do_now": "Log every AI call with model, prompt hash, input row/object id, output hash, confidence, latency, token usage, price estimate, cascade stage, and verification status.",
    "do_later": "Let the optimizer choose between small/fast model, large/oracle model, cached output, and human review based on cost and confidence.",
    "watch_out": "Do not trust a semantic operator just because it returns an answer. Persist uncertainty and verification state so downstream artifacts can be rebuilt or invalidated.",
    "priority": "P0"
  },
  {
    "company": "AWS",
    "theme": "PostgreSQL-compatible horizontal scale",
    "adoptable_idea": "Start with normal PostgreSQL semantics, then add router, shard, replica, and distributed transaction concepts only when scale demands it.",
    "key_papers": [
      {
        "title": "Aurora PostgreSQL Limitless Database: Building a Highly Scalable OLTP Database",
        "url": "https://www.amazon.science/publications/aurora-postgresql-limitless-database-building-a-highly-scalable-oltp-database",
        "type": "primary / Amazon Science",
        "source_url": "https://www.amazon.science/publications/aurora-postgresql-limitless-database-building-a-highly-scalable-oltp-database",
        "last_verified": "2026-06-29",
        "source_type": "amazon_science",
        "venue_or_track": "Amazon Science",
        "doi_or_arxiv": "",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Aurora PostgreSQL Limitless Database: Building a Highly Scalable OLTP Database",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Most repo metadata projects should begin with one reliable relational database. Horizontal scaling should preserve compatibility instead of forcing application-level sharding too early.",
    "repo_db_translation": "Begin with single PostgreSQL. When repositories or organizations grow, introduce logical routers, project shards, replicas, and distributed transaction logs.",
    "first_schema_objects": [
      "router_rules",
      "project_shards",
      "replicas",
      "global_transaction_log",
      "shard_rebalancing_events"
    ],
    "do_now": "Design tables with stable IDs and clear shard keys, even before sharding is implemented.",
    "do_later": "Route by organization, repository, package, or project boundary when metadata volume becomes large.",
    "watch_out": "Avoid premature sharding. The first goal is correctness and compatibility; scale-out is a later migration path.",
    "priority": "P1"
  },
  {
    "company": "IBM",
    "theme": "End-to-end benchmarking for RAG and embeddings",
    "adoptable_idea": "Measure RAG as a whole system: embedding, indexing, retrieval, reranking, generation, latency, memory, update cost, and factual consistency.",
    "key_papers": [
      {
        "title": "RAGPerf: An End-to-End Benchmarking Framework for Retrieval-Augmented Generation Systems",
        "url": "https://arxiv.org/abs/2603.10765",
        "type": "supporting benchmark / arXiv",
        "source_url": "https://arxiv.org/abs/2603.10765",
        "last_verified": "2026-06-29",
        "source_type": "supporting_arxiv",
        "venue_or_track": "arXiv",
        "doi_or_arxiv": "arXiv:2603.10765",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Fabric-X: Scaling Hyperledger Fabric for Asset Exchange",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "A repository knowledge base is useful only if retrieval quality and system cost are measured together. Recall alone is not enough.",
    "repo_db_translation": "Persist `rag_eval_runs`, `context_recall`, `latency_ms`, `memory_mb`, `update_cost_ms`, `groundedness`, and `factual_consistency`.",
    "first_schema_objects": [
      "rag_eval_runs",
      "retrieval_metrics",
      "generation_metrics",
      "rerank_metrics",
      "factuality_checks"
    ],
    "do_now": "Benchmark at least five dimensions: recall, answer quality, latency, memory, and index update cost.",
    "do_later": "Run benchmark suites whenever embedding model, chunker, index, or reranker changes.",
    "watch_out": "RAG quality can improve while latency or update cost becomes unacceptable. Track both quality and systems metrics.",
    "priority": "P1"
  },
  {
    "company": "Neo4j",
    "theme": "Use graph databases when multi-hop queries become the bottleneck",
    "adoptable_idea": "Start with `graph_edges` in PostgreSQL, then mirror to Neo4j when multi-hop traversal and graph algorithms dominate workload cost.",
    "key_papers": [
      {
        "title": "RIOT: Replicated Independently-Ordered Transactions",
        "url": "https://dl.acm.org/doi/10.1145/3788853.3803094",
        "type": "ACM DOI",
        "source_url": "https://dl.acm.org/doi/10.1145/3788853.3803094",
        "last_verified": "2026-06-29",
        "source_type": "acm_doi",
        "venue_or_track": "ACM Digital Library",
        "doi_or_arxiv": "10.1145/3788853.3803094",
        "claim_scope": "paper metadata"
      },
      {
        "title": "Neo4j Research: RIOT",
        "url": "https://neo4j.com/research/",
        "type": "company research page",
        "source_url": "https://neo4j.com/research/",
        "last_verified": "2026-06-29",
        "source_type": "company_research",
        "venue_or_track": "Neo4j Research",
        "doi_or_arxiv": "",
        "claim_scope": "company research page"
      },
      {
        "title": "RIOT: Replicated Independently-Ordered Transactions",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Repository graphs become valuable when questions require several hops: which tests cover a changed symbol, which docs mention it, which generated artifacts depend on it?",
    "repo_db_translation": "Use PostgreSQL `graph_edges` first. Add a Neo4j mirror only after multi-hop queries, path ranking, or graph algorithms justify it.",
    "first_schema_objects": [
      "graph_edges",
      "graph_snapshots",
      "neo4j_mirror_state",
      "multi_hop_query_log"
    ],
    "do_now": "Store edges in a relational table with `src_id`, `dst_id`, `edge_type`, `source`, `valid_from`, and `confidence`.",
    "do_later": "Export edges to Neo4j for path queries, centrality, community detection, and impact analysis.",
    "watch_out": "Adding a graph DB too early creates operational overhead. Make the graph model portable first.",
    "priority": "P1"
  },
  {
    "company": "Cockroach Labs",
    "theme": "Distributed consensus for highly available metadata",
    "adoptable_idea": "Leader leases and range-level consensus matter once repository metadata becomes a shared, high-availability service.",
    "key_papers": [
      {
        "title": "Scalable Leader Leases For Multi Consensus Groups in CockroachDB",
        "url": "https://www.cockroachlabs.com/blog/distributed-database-leader-leases/",
        "type": "company blog / paper announcement",
        "source_url": "https://www.cockroachlabs.com/blog/distributed-database-leader-leases/",
        "last_verified": "2026-06-29",
        "source_type": "company_blog",
        "venue_or_track": "Cockroach Labs blog",
        "doi_or_arxiv": "",
        "claim_scope": "implementation interpretation source"
      },
      {
        "title": "Scalable Leader Leases For Multi Consensus Groups in CockroachDB",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Metadata services can become critical infrastructure. Leaseholders, ranges, and consensus groups become relevant when many services read and update metadata concurrently.",
    "repo_db_translation": "Use `metadata_ranges`, `leaseholders`, `consensus_groups`, and range-health observations when evolving toward distributed metadata storage.",
    "first_schema_objects": [
      "metadata_ranges",
      "leaseholders",
      "consensus_groups",
      "range_health_events",
      "lease_transfer_events"
    ],
    "do_now": "Keep metadata boundaries clean so a future distributed database can partition them by repository, organization, package, or time.",
    "do_later": "Adopt CockroachDB-like distributed SQL only when availability and horizontal scale matter more than local simplicity.",
    "watch_out": "Consensus solves availability and coordination problems, not bad schema design. Fix identity, lineage, and validation first.",
    "priority": "P2"
  },
  {
    "company": "Tencent",
    "theme": "Distributed design for heterogeneous multi-table workloads",
    "adoptable_idea": "Plan for multiple languages, package managers, schema styles, artifact types, and workload classes in large monorepos.",
    "key_papers": [
      {
        "title": "TDSQL-Boundless: A Distributed Database System for Large-scale Heterogeneous Multi-Table Workloads",
        "url": "https://dl.acm.org/doi/abs/10.1145/3788853.3803090",
        "type": "ACM DOI",
        "source_url": "https://dl.acm.org/doi/abs/10.1145/3788853.3803090",
        "last_verified": "2026-06-29",
        "source_type": "acm_doi",
        "venue_or_track": "ACM Digital Library",
        "doi_or_arxiv": "10.1145/3788853.3803090",
        "claim_scope": "paper metadata"
      },
      {
        "title": "TDSQL-Boundless: A Distributed Database System for Large-scale Heterogeneous Multi-Table Workloads",
        "url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "type": "SIGMOD 2026 Industry listing",
        "source_url": "https://2026.sigmod.org/sigmod_industry_papers.shtml",
        "last_verified": "2026-06-29",
        "source_type": "sigmod_industry_listing",
        "venue_or_track": "SIGMOD 2026 Industry",
        "doi_or_arxiv": "",
        "claim_scope": "accepted-paper listing"
      }
    ],
    "why_it_matters": "Large monorepos look like heterogeneous database workloads: many schemas, many access patterns, many teams, and uneven hotspots.",
    "repo_db_translation": "Use `project_shards`, `package_groups`, `heterogeneous_tables`, and workload-class routing for multi-language monorepo metadata.",
    "first_schema_objects": [
      "project_shards",
      "package_groups",
      "heterogeneous_tables",
      "workload_classes",
      "cross_shard_queries"
    ],
    "do_now": "Tag every file, package, generated artifact, and query with project, language, package manager, and workload class.",
    "do_later": "Shard by project or package group when single-node metadata operations become a bottleneck.",
    "watch_out": "Heterogeneity is a schema problem before it is a distributed-systems problem. Classify workload types early.",
    "priority": "P2"
  }
]