These are two rather distinct ways of storing data. Especially graph databases are quite domain specific to, well, data structured as a graph, something classical relational databases struggle with. Key-value databases are a bit more general purpose. Without understanding your domain model and the expected real-world workload of your application, we can't give you any relevant suggestions to what db will perform better for you. I'm afraid you have to benchmark and try their APIs yourself and see what fits.
But native_db is a wrapper ontop of key_value pair and it seems to very well work with structures just like with agdb.
Just general usecase so for example storing customer's details, retrieving data etc, so the whole of CRUD really.
Possibly I would imagine I would have a client/web application that would connect to a webserver and the webserver could use either native_db or agdb. So what do you think would work best?
I'd suspect native_db to have the more ergonomic interface if your data does not behave like a graph. Depending on your domain, customer data could be stored as a graph though. I once developed an application where users were organised hierarchically in a tree structure. Querying a subtree of the user tree from the document database I used to store the user data was brutally inefficient. I later regretted not using a graph database for the user tree directly and that I had to instead rely heavily on caching.
I'm not familiar with how data is actually stored in graph databases. I assume that it varies from implementation to implementation. What I do know is that they offer a query language that makes it easier to work with graph structures, including recursive queries where you "hop" from vertex to vertex along the graph's edges.