cmu-db / bustub
The BusTub Relational Database Management System (Educational)
AI Architecture Analysis
This repository is indexed by RepoMind. By analyzing cmu-db/bustub in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.
Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.
Repository Overview (README excerpt)
Crawler view----------------- BusTub is a relational database management system built at Carnegie Mellon University for the Introduction to Database Systems (15-445/645) course. This system was developed for educational purposes and should not be used in production environments. BusTub supports basic SQL and comes with an interactive shell. You can get it running after finishing all the course projects. **WARNING: IF YOU ARE A STUDENT IN THE CLASS, DO NOT DIRECTLY FORK THIS REPO. DO NOT PUSH PROJECT SOLUTIONS PUBLICLY. THIS IS AN ACADEMIC INTEGRITY VIOLATION AND CAN LEAD TO GETTING YOUR DEGREE REVOKED, EVEN AFTER YOU GRADUATE.** We make the autograder for each assignment available to non-CMU students on Gradescope after their due date for CMU students. In exchange for making this available to the public, we ask that you do not make your project implementations public on GitHub or other source code repositories. Please read the course FAQ on how to use the autograder on Gradescope. Run to sign an agreement before submitting to the autograder. **WARNING: IF YOU ARE A STUDENT OUTSIDE CMU, DO NOT MAKE YOUR SOLUTION PUBLICLY AVAILABLE, AND DO SUBMIT YOUR OWN WORK. OTHERWISE, YOU WILL BE BANNED FROM USING THE AUTOGRADER.** Thank you for creating a fair learning environment. Cloning this Repository The following instructions are adapted from the GitHub documentation on duplicating a repository. The procedure below walks you through creating a private BusTub repository that you can use for development. • Create a new repository under your account. Pick a name (e.g. ) and select **Private** for the repository visibility level. • On your development machine, create a bare clone of the public BusTub repository: • Next, mirror the public BusTub repository to your own private BusTub repository. Suppose your GitHub name is and your repository name is . The procedure for mirroring the repository is then: This copies everything in the public BusTub repository to your own private repository. You can now delete your local clone of the public repository: • Clone your private repository to your development machine: • Add the public BusTub repository as a second remote. This allows you to retrieve changes from the CMU-DB repository and merge them with your solution throughout the semester: You can verify that the remote was added with the following command: • You can now pull in changes from the public BusTub repository as needed with: • **Disable GitHub Actions** from the project settings of your private repository; otherwise, you may run out of GitHub Actions quota. We suggest working on your projects in separate branches. If you do not understand how Git branches work, learn how. If you fail to do this, you might lose all your work at some point in the semester, and nobody will be able to help you. Build We recommend developing BusTub on Ubuntu 24.04, or macOS (M1/M2/Intel). We do not support any other environments (i.e., do not open issues or come to office hours to debug them). We do not support WSL. The grading environment runs Ubuntu 24.04. Linux (Recommended) / macOS (Development Only) To ensure that you have the proper packages on your machine, run the following script to automatically install them: Then run the following commands to build the system: If you want to compile the system in debug mode, pass in the following flag to cmake: Debug mode: This enables AddressSanitizer by default. If you want to use other sanitizers, There are some differences between macOS and Linux (i.e., mutex behavior) that might cause test cases to produce different results in different platforms. We recommend students to use a Linux VM for running test cases and reproducing errors whenever possible.