Thanks for joining the discussion T0pH4t! Your concern for extra overhead from a general purpose solution is a valid one, but only in the most extreme cases where very low latency is required. So it is not relevant to many people. For those that seek the fastest latency possible I suggest writing everything in native binaries and minimizing middleware modules, essentially writing hard to maintain, monolithic ad-hoc solutions to specific use cases. That is very expensive and out of reach for all but the well-funded institutional high-frequency traders. Every message in ZMAPI is prefixed with a byte that expresses the codec that will be used to decode the message. So far I have only used JSON codec as it's by far the easiest codec to work with and it works fine unless low latency is required. Especially those users who want to subscribe to lots of tickers simultaneously with high throughput subscription parameters I'd recommend using a binary codec. FastFIX seems okay but I haven't done a lot of research on that yet. I'll focus on that more if there is demand for that. I'm planning on sending all the PUB emissions in the connectors and middleware modules using a binary codec. The users who prefer JSON output can use codec converter middleware. That way both performance and convenience demanding users can be served. Middleware modules add a tiny bit of latency. This is negligible for most users because even if you program directly to vendor API there are typically many proprietary middleware modules already chained in the upstream so you never really can get very direct connectivity unless you are an institution with lots of funds. This problem can be alleviated in the future by writing the middleware components as native binaries, maximizing their performance. I have chosen to write them with Python for now just to get ZMAPI project up and running quickly. Python code is also relatively easy to read which will make it easier for new developers to get in touch with the code base. Native versions can be and most likely will be written in the future. ZMAPI core middleware modules are not saving any data to databases as this is a higher level functionality -- only required by some users. In other words only streaming is supported by the current set of modules. The methodology you are using can be applied by writing a data mining middleware module that collects data to a database and adds some custom commands that provide access to standardized forms of historical data. This kind of module seems like a very useful one and should actually be written. Good idea. I'm not sure if I understand the last question about data amount differences. ZMAPI provides standardized subscription definitions that include subscription speed settings.