Schwierigkeiten, die ich sehe:
Der extrem geringe Arbeitsspeicher. Sobald du joinst musst Du die Daten vom Select vorrätig haben, wo sollen die hin, wenn nicht in den RAM?
Du solltest einen halbwegs intelligenten execution plan auf die Bein stellen.
Du hast kein Multithreading, daher hast auch keine Probleme mit Transactions oder Locking und musst nicht Tabellen mehrfach vorrätig haben. Aber Du hast automatisch die damit verbundenen Nachteile. Ignorierst Du Transactionanweisungen in den Queries einfach, kannst Du dich im Falle paralleler Abfragen, die sich auf mehrere Queries erstrecken, auf inkonsistente Daten gefasst machen. Das trifft maßgeblich auf Indexe zu. Damit kannst Du Dir schön Deine DB zerschießen.

Du hast also die Serverkomponente, den query parser, die execution plan factory und die eingentlichen Datentzugriffe in einem AVR zu vereinen. Selbst mit arg abgespeckten Funktionsumfang eine überaus herausfordernde Aufgabe.