I created which was an Object-Relational Model framework for representing graphical data in your favorite Object-Oriented Programming language, namely Python. I promise at some point it was working. And I promise, nowdays I can code better. That project teached the following lesson: embedding the full query language of graphical databases inside Python without relying on string interpolation is not possible.
Given it was not possible to embed nicely another Turing Complete language inside Python, I tried to embed Python inside Tinkerpop in . I promise it was working at some point. To me, that was mostly a failure because it was not really possible to send Python queries directly from Python code without relying on string interpolation.
And I figured something else. Using Tinkerpop, unlike with PostgreSQL, I had to rely on another database to do full-text search and geospatial queries which would break the ACID semantic I was so attached to.
At this point, I knew that building a database in Python was bad idea . So, I pivoted into an "graph exploration tool" but never really executed that idea.
Along the way, I got lost a little regarding my goal. My initial idea was to create a general purpose database that support transactions all around.
For other reasons I learned Scheme programming language. GNU Guile did not have a Global Interpreter Lock and performance were better than CPython. I continued experimenting with ordered key-value stores. I have written several posts regarding this work:
Since, the beginning I always wrapped inside classes and Python objects the abstractions I was building. Somekind of Object-Oriented Programming made things, very difficult to interop and compose abstractions. To be honest, even the Scheme functional code was not easy to compose.
That is when I FoundationDB was open-sourced that I figured that the ordered key-value store doesn't have to be hidden. That is the underlying abstraction can leak on purpose because it helps to build higher level abstractions, compose them and generaly reach somekind of fractal architecture.
I have put in motion that idea in with an exampe abstraction . That is, abstractions on top of SRFI-167 shall not hide the ordered key-value store and accept to allow to hook it somewhere. Also, it should be possible to nest abstractions to be fractal. This is not possible in the sample implementation because the packing procedure don't support nested datastructures, as of yet.
So, if you wanted you could build a triple store on top a triple store. That is already a thing and some do n-tuples inside triple store. Based, on my analysis this is not great in terms of performance.
 This is still a work-in-progress and we very recently released another draft. Chime in!