← Articles

Systems Programming

AVL Trees C CRUD Data Structures

Building an In-Memory Record Database in C (Part 1)

A litmus test to truly understand practical implementations of AVL trees in a language that requires manual memory management.

Published Sep 09, 2026

In-Memory Record Database

Want to view this project? In-Memory Record Database

Introduction

This section only provides background information on why this project was created and can be skipped.

One of the biggest hurdles for most people taking a traditional computer science course is the big data structures and algorithms class. I don’t necessarily blame people that struggle as it builds upon numerous other things that they should already have somewhat of a grasp on like recursion. Early data structure concepts like linked links, heaps, and stacks were pretty easy for me to understand, but it wasn’t until I started diving deep into binary search trees that things changed. Sure, the basic implementation of binary search trees are pretty easy, but it’s when you start thinking about how efficient your tree searches, insertions, etc. should be, that things start to become a lot more complicated.

I went to school online at Western Governors University. There’s a lot I could say about my experiences there, but one of the negative aspects occurred when I started taking my data structures and algorithms classes. The provided reading material was subpar at best, so I went out of my way to purchase A Common-Sense Guide to Data Structures and Algorithms, Second Edition by Jay Wengrow. While this book is a phenomenal resource, it suffers from the same issue that most data structures and algorithms courses suffer from: it’s not written in a language that requires manual memory management. I have a whole slew of thoughts around this, but that's for another time.

This led me to wanting to create a practical implementation of the AVL tree in C, which happened to be one of the data structures that I struggled with truly understanding.

Any programmer should, at the very least, be able to create a simple database system using an array that’s initialized at a fixed length at the beginning of the program, but I’m not just any programmer: I’m a programmer who happens to love slamming my head into the wall and crying to myself about segmentation faults. Now how do ya like THEM apples?

Why AVL Trees?

Whenever I think of data structures for databases, I’m immediately thinking about B-Trees and I did originally want to try implementing exactly this. However, B-Trees really aren’t the best option for an in-memory database. Perhaps when I decide to build a system that utilizes secondary storage will I revisit the B-Tree. Until then, an AVL tree will do just nicely since it’s optimized for memory operations.

Planning

Since this was more of a litmus test to see whether or not I could even do this project, I already decided that I would stick to just a simple console application. Unfortunately, that means I have to go and add a bunch of input verification for my menus to make sure no invalid inputs crash the program. Great.

I also didn’t want to fall into scope creep and start adding extra features that take away from the core challenge itself. That means we’re not allowing stuff like table/view creation, custom queries, and other stuff you’d typically expect from your standard SQL database. We’re sticking to the following requirements:

  • CREATE RECORD
  • EDIT RECORD
  • DELETE RECORD
  • SEARCH RECORD
  • LIST RECORDS

Sounds good, but what the heck even is a Record? It’s this right here:

struct Record
{
    int id;
    char firstName[101];
    char lastName[101];
    int age;
};

With our struct Record created, we can now define our requirements a bit further.

  • CREATE RECORD
    • First Name limited to 100 characters
    • Last Name limited to 100 characters
    • Age must be greater than 0 (I’ll let you decide if you’re 1000 years old. Doesn’t matter to me.)

I’m creating the first and last name members with a fixed length instead of a typical char* since most databases require you to specify the length like nvarchar(100) or something similar.

  • EDIT RECORD

    • Option to edit First Name
    • Option to edit Last Name
    • Option to edit Age

  • DELETE RECORD

    • Search for a record to delete by ID only since we’re not allowing complex queries.

  • SEARCH RECORD

    • Search by ID
    • Search by First Name
    • Search by Last Name
    • Search by Age

  • LIST RECORDS

    • List records sorted in ascending order by ID
    • List records sorted in ascending order by First Name
    • List records sorted in ascending order by Last Name
    • List records sorted in ascending order by Age

Alright, so what are we calling this thing? How about just TempDB? Works for me. Let’s begin.

Continue to Part 2 →