About

Tim Kraska is an Associate Professor at MIT in the Department of Electrical Engineering and Computer Science, specializing in Artificial Intelligence and Machine Learning. His research focuses on developing systems and techniques for AI and decision-making, combining intellectual traditions from computer science and electrical engineering to analyze and synthesize systems that interact with the external world through perception, communication, and action. His work involves learning, decision-making, and adaptation within changing environments, contributing to advancements in AI systems and their applications.

Research topics

• Computer Science
• Artificial Intelligence
• Information Retrieval
• Data Mining
• Database
• Machine Learning
• Programming language
• Parallel computing
• Data science
• World Wide Web
• Theoretical computer science
• Computer vision
• Algorithm

Selected publications

• Tailwind: A Practical Framework for Query Accelerators

  arXiv (Cornell University) · 2026-04-30

  preprintOpen accessSenior author

  Relational database management systems (RDBMSes) can process general-purpose queries, but often have lower performance compared to custom-built solutions for specific queries. For example, consider a group-by query over a few known groups (e.g., grouping by country). While an RDBMS would likely use a hash map to do the grouping, a faster method could hard-code the expected groups into the query executor. But such workload-specific techniques, which we call query accelerators, are not widely used in practice because the engineering effort (optimizer and engine changes, potential bugs) does not justify the isolated performance gains (speedup on a single specific query). We propose Tailwind: an external query planner that brings accelerators into any RDBMS that supports data import/export. Users define their accelerators using abstract logical plans (ALPs): a new mostly-declarative abstraction over relational operators built on regular tree expressions. ALPs allow Tailwind to automatically build customized neural network models to estimate when using a particular accelerator is beneficial. At runtime, Tailwind sits atop an RDBMS and transparently rewrites queries to run across one or more accelerators when predicted to be beneficial, falling back to the underlying RDBMS when not. On Redshift and DuckDB with a library of four diverse accelerators, Tailwind accelerates TPC-H queries by 1.38x on average (up to 29x).

  PublisherDOI

• Abacus: A Cost-Based Optimizer for Semantic Operator Systems

  Proceedings of the VLDB Endowment · 2026-01-01 · 1 citations

  articleOpen access

  LLMs enable an exciting new class of data processing applications over large collections of unstructured documents. Several new programming frameworks have enabled developers to build these applications by composing them out of semantic operators: a declarative set of AI-powered data transformations with natural language specifications. These include LLM-powered maps, filters, joins, etc. used for document processing tasks such as information extraction, summarization, and more. While systems of semantic operators have achieved strong performance on benchmarks, they can be difficult to optimize. An optimizer for this setting must determine how to physically implement each semantic operator in a way that optimizes the system globally. Existing optimizers are limited in the number of optimizations they can apply, and most (if not all) cannot optimize system quality, cost, or latency subject to constraint(s) on the other dimensions. In this paper we present Abacus, an extensible, cost-based optimizer which searches for the best implementation of a semantic operator system given a (possibly constrained) optimization objective. Abacus estimates operator performance by leveraging a minimal set of validation examples, prior beliefs about operator performance, and/or an LLM judge. We evaluate Abacus on document processing workloads in the biomedical and legal domains (BioDEX; CUAD) and multi-modal question answering (MMQA). We demonstrate that, on-average, systems optimized by Abacus achieve 6.7%-39.4% better quality and are 10.8x cheaper and 3.4x faster than the next best system.

  PublisherOA PDFDOI

• Tailwind: A Practical Framework for Query Accelerators

  ArXiv.org · 2026-04-30

  articleOpen accessSenior author

  Relational database management systems (RDBMSes) can process general-purpose queries, but often have lower performance compared to custom-built solutions for specific queries. For example, consider a group-by query over a few known groups (e.g., grouping by country). While an RDBMS would likely use a hash map to do the grouping, a faster method could hard-code the expected groups into the query executor. But such workload-specific techniques, which we call query accelerators, are not widely used in practice because the engineering effort (optimizer and engine changes, potential bugs) does not justify the isolated performance gains (speedup on a single specific query). We propose Tailwind: an external query planner that brings accelerators into any RDBMS that supports data import/export. Users define their accelerators using abstract logical plans (ALPs): a new mostly-declarative abstraction over relational operators built on regular tree expressions. ALPs allow Tailwind to automatically build customized neural network models to estimate when using a particular accelerator is beneficial. At runtime, Tailwind sits atop an RDBMS and transparently rewrites queries to run across one or more accelerators when predicted to be beneficial, falling back to the underlying RDBMS when not. On Redshift and DuckDB with a library of four diverse accelerators, Tailwind accelerates TPC-H queries by 1.38x on average (up to 29x).

  PublisherOA PDF

• Tressoir: Unifying Online, Offline, and HIL Design and Evolution of Multi-Agent Systems via Interpretable Blueprints

  2026-05-22

  articleOpen accessSenior author

  We explore a principled approach that jointly designs and evolves the architectures, prompts, tools, and knowledge of multi-agent systems, whether online, offline, or with human guidance.

  PublisherDOI

• Improving DBMS Scheduling Decisions with Fine-grained Performance Prediction on Concurrent Queries -- Extended

  ArXiv.org · 2025-01-27

  preprintOpen access

  Query scheduling is a critical task that directly impacts query performance in database management systems (DBMS). Deeply integrated schedulers, which require changes to DBMS internals, are usually customized for a specific engine and can take months to implement. In contrast, non-intrusive schedulers make coarse-grained decisions, such as controlling query admission and re-ordering query execution, without requiring modifications to DBMS internals. They require much less engineering effort and can be applied across a wide range of DBMS engines, offering immediate benefits to end users. However, most existing non-intrusive scheduling systems rely on simplified cost models and heuristics that cannot accurately model query interactions under concurrency and different system states, possibly leading to suboptimal scheduling decisions. This work introduces IconqSched, a new, principled non-intrusive scheduler that optimizes the execution order and timing of queries to enhance total end-to-end runtime as experienced by the user query queuing time plus system runtime. Unlike previous approaches, IconqSched features a novel fine-grained predictor, Iconq, which treats the DBMS as a black box and accurately estimates the system runtime of concurrently executed queries under different system states. Using these predictions, IconqSched is able to capture system runtime variations across different query mixes and system loads. It then employs a greedy scheduling algorithm to effectively determine which queries to submit and when to submit them. We compare IconqSched to other schedulers in terms of end-to-end runtime using real workload traces. On Postgres, IconqSched reduces end-to-end runtime by 16.2%-28.2% on average and 33.6%-38.9% in the tail. Similarly, on Redshift, it reduces end-to-end runtime by 10.3%-14.1% on average and 14.9%-22.2% in the tail.

  PublisherOA PDFDOI

• The Cambridge Report on Database Research

  ArXiv.org · 2025-04-15 · 1 citations

  preprintOpen access

  On October 19 and 20, 2023, the authors of this report convened in Cambridge, MA, to discuss the state of the database research field, its recent accomplishments and ongoing challenges, and future directions for research and community engagement. This gathering continues a long standing tradition in the database community, dating back to the late 1980s, in which researchers meet roughly every five years to produce a forward looking report. This report summarizes the key takeaways from our discussions. We begin with a retrospective on the academic, open source, and commercial successes of the community over the past five years. We then turn to future opportunities, with a focus on core data systems, particularly in the context of cloud computing and emerging hardware, as well as on the growing impact of data science, data governance, and generative AI. This document is not intended as an exhaustive survey of all technical challenges or industry innovations in the field. Rather, it reflects the perspectives of senior community members on the most pressing challenges and promising opportunities ahead.

  PublisherOA PDFDOI

• Recursive Language Models

  ArXiv.org · 2025-12-31

  articleOpen access

  We study allowing large language models (LLMs) to process arbitrarily long prompts through the lens of inference-time scaling. We propose Recursive Language Models (RLMs), a general inference paradigm that treats long prompts as part of an external environment and allows the LLM to programmatically examine, decompose, and recursively call itself over snippets of the prompt. We find that RLMs can successfully process inputs up to two orders of magnitude beyond model context windows and, even for shorter prompts, dramatically outperform the quality of vanilla frontier LLMs and common long-context and coding scaffolds (e.g., on GPT-5 by a median across the evaluated benchmarks of $26\%$ against compaction, $130\%$ against CodeAct with sub-calls, and $13\%$ against Claude Code) across four diverse long-context tasks while having comparable cost. At a small scale, we post-train the first model around the RLM. Our model, RLM-Qwen3-8B, outperforms the underlying Qwen3-8B model by $28.3\%$ on average and even approaches the quality of vanilla GPT-5 on three long-context tasks. Code is available at https://github.com/alexzhang13/rlm.

  PublisherOA PDF

• Parachute: Single-Pass Bi-Directional Information Passing

  ArXiv.org · 2025-06-16

  preprintOpen access

  Sideways information passing is a well-known technique for mitigating the impact of large build sides in a database query plan. As currently implemented in production systems, sideways information passing enables only a uni-directional information flow, as opposed to instance-optimal algorithms, such as Yannakakis'. On the other hand, the latter require an additional pass over the input, which hinders adoption in production systems. In this paper, we make a step towards enabling single-pass bi-directional information passing during query execution. We achieve this by statically analyzing between which tables the information flow is blocked and by leveraging precomputed join-induced fingerprint columns on FK-tables. On the JOB benchmark, Parachute improves DuckDB v1.2's end-to-end execution time without and with semi-join filtering by 1.54x and 1.24x, respectively, when allowed to use 15% extra space.

  PublisherOA PDFDOI

• A Write-Optimized Distributed B+Tree Index on Disaggregated Memory

  Communications of the ACM · 2025-04-15

  articleOpen access1st authorCorresponding

  Separation of compute and storage has become the de facto standard for cloud database systems.First proposed in 2007 for database systems, 2 it is now widely adopted by all major cloud providers, such as Amazon Redshift, Google BigQuery, and Snowflake.Separation of compute and storage adds enormous value for the customer.Users can scale storage independently of compute, which enables them to only pay for what they use.Consider a scenario in which data grows linearly over time.Most queries only access the last month of data, which remains relatively stable.Without the separation of compute and storage, the user would gradually be forced to significantly increase database cluster capacity.In contrast, modern cloud database systems allow scaling storage separately from compute; the compute cluster stays the same over time, whereas the data is stored on cheap cloud storage services, such as Amazon S3.However, current cloud database systems still tightly couple compute and memory.While it might feel unnatural to disaggregate compute and memory as the CPU needs access to data, a disaggregation would certainly have advantages.Servers used for database workloads tend to have large amounts of memory, so they can cache as much data as possible to avoid the relatively slow access to storage services and keep all intermediate results in memory.The latter is of the utmost importance as queries, which spill to disk, often fall off the performance cliff and are orders of magnitude slower than their in-memory counterparts.Yet, keeping the most relevant data, intermediate results, and metadata in-memory is a non-trivial and often costly problem.Memory is expensive and the right machine type, which offers enough memory and compute, is hard to determine up front.Moreover, workloads are rarely static.For example, a database system that mainly serves dashboarding queries might not require a lot of memory, except when it has to process ad hoc data-exploration queries.If it were possible to scale memory independently from compute, it would be feasible to dynamically adjust the amount of memory based on the workload.It would further enable better resource utilization.Consider a dynamic workload regarding the number of queries but with very strict response-time requirements, which can only be met if data is kept in-memory.In this case, the separation of compute and memory would enable scaling compute with the number of queries while keeping all the data constantly in-memory.This design principle is already used by services such as Google, which keeps the entire Web index in-memory.In some ways, the disaggregation of compute, storage, and memory is the natural evolution of the currently prevalent separation of compute and storage.However, it is only recently, with the advancement of RDMA and low-latency network standards, that this evolution has become possible.In 2016, 1 we proposed the network-attached-memory database (NAM-DB) as a first prototype to explore the design of a system with separation of compute, storage, and memory.As part of the same project, we also explored the design of the first RDMA-based B-Tree index, 3 which only uses one-sided

  PublisherOA PDFDOI

• KramaBench: A Benchmark for AI Systems on Data-to-Insight Pipelines over Data Lakes

  ArXiv.org · 2025-06-06

  preprintOpen accessSenior author

  Discovering insights from a real-world data lake potentially containing unclean, semi-structured, and unstructured data requires a variety of data processing tasks, ranging from extraction and cleaning to integration, analysis, and modeling. This process often also demands domain knowledge and project-specific insight. While AI models have shown remarkable results in reasoning and code generation, their abilities to design and execute complex pipelines that solve these data-lake-to-insight challenges remain unclear. We introduce KramaBench which consists of 104 manually curated and solved challenges spanning 1700 files, 24 data sources, and 6 domains. KramaBench focuses on testing the end-to-end capabilities of AI systems to solve challenges which require automated orchestration of different data tasks. KramaBench also features a comprehensive evaluation framework assessing the pipeline design and individual data task implementation abilities of AI systems. We evaluate 8 LLMs using our single-agent reference framework DS-Guru, alongside both open- and closed-source single- and multi-agent systems, and find that while current agentic systems may handle isolated data-science tasks and generate plausible draft pipelines, they struggle with producing working end-to-end pipelines. On KramaBench, the best system reaches only 55% end-to-end accuracy in the full data-lake setting. Even with perfect retrieval, the accuracy tops out at 62%. Leading LLMs can identify up to 42% of important data tasks but can only fully implement 20% of individual data tasks. Our code, reference framework, and data are available at https://github.com/mitdbg/KramaBench.

  PublisherOA PDFDOI

Recent grants

• III: Medium: Learning-based Synthesis of Data Processing Engines

  NSF · $1.2M · 2019–2023

• III: Medium: Quantifying the Unknown Unknowns for Data Integration

  NSF · $335k · 2020–2023

• III: Medium: Quantifying the Unknown Unknowns for Data Integration

  NSF · $985k · 2016–2020

• CAREER: Query Compilation Techniques for Complex Analytics on Enterprise Clusters

  NSF · $550k · 2015–2023

• BD Spokes: SPOKE: NORTHEAST: Collaborative: A Licensing Model and Ecosystem for Data Sharing

  NSF · $271k · 2019–2021

Frequent coauthors

• Carsten Binnig

  Technical University of Darmstadt

  74 shared

• Michael J. Franklin

  University of Chicago

  73 shared

• Emanuel Zgraggen

  53 shared

• Ryan Marcus

  California University of Pennsylvania

  45 shared

• Uğur Çetintemel

  34 shared

• Samuel Madden

  32 shared

• Andreas Kipf

  30 shared

• Yeounoh Chung

  29 shared