AerospikeDB is open source. So it’s the customer’s favorite price: free. The Community Edition is free. Is and always will be. The Enterprise Edition, which includes XDR (Cross Datacenter Replication) and security features, amongst others, is where the costed product is. For small businesses, we also have a Start Up Special which is also free, and gets you the Enterprise Edition until you meet revenue numbers ($2 million in annual revenues, or $20 million in funding). For companies big and small, we publish the following price list:http://www.aerospike.com/products-services/

Also note that we only charge based on total data in your database; unlike a cloud provider, we do not charge based on usage of the data.

More comments are embedded below, which was part of your original email….

In a way, yes, but I wanted to get a clear idea. It looks like you want to have the following:• A desktop (Windows-based) trading desk application (buys and sells); broker-level, but not “exchange-floor” or “HFT cluster”-level.

• Seem you want an application that would allow brokers to control up HFT, but not the architecture to actually *execute/run* the HFT.

• This is important, because you are looking to allow what you call “HFT”, but not really the sort of thing where people are doing silicon-based HFT architectures to actually put in automated trading systems (q.v., Cisco Nexus: http://www.networkcomputing.com/networking/cisco-flexes-custom-silicon-muscle-for-high-frequency-trading-crowd/d/d-id/1233885?)

Let me know if any of those assumptions are correct or incorrect, because the kinds of solutions you are talking about are orders of magnitude larger and more complex to actually create an HFT cluster.

Also, this article on the topic was interesting to me. It was from 2012:

• Financial Business Cloud for High-Frequency Trading – http://www.thinkmind.org/download.php?articleid=intsys_v4_n34_2011_11

Rather than just say “this is best,” or “that is best,” the real thing to do is to check out your data modal, and your application architecture. First, I noticed that you created a two-part model, which inferred a desktop client, and then some remote “server,” but the differentiation between one and the other wasn’t very clear. For instance, are you doing server-side analytics, real-time analytics, or non-real time? Is it all desktop-based, or will there be a component of server-based, or both?

For instance, you might want to do “live” analytics with Hadoop or Spark; we have connectors for both. But that’s the sort of “big data” analytics that would fry your typical PC.

Also, I am presuming that any server you are using would have some sort of “upstream” connection to the live markets, such as NASDAQ FIX API (which replaced CTCI) (q.v., http://www.nasdaqtrader.com/content/technicalsupport/specifications/tradingproducts/fixactspec.pdf).

My thoughts would that you would need a “three tier” model, with the actual market APIs connecting to the “first tier” — the markets themselves. Then the “second tier” would be some sort of brokerage-based (or service-based) big data aggregation, transaction and analytics engine. The third tier would then be the desktop trader/broker desks.

Something akin to this?

Your desktop-analytics engine would be different than your server-side engine, just looking at a subset of the overall market data model. For instance, a single ticker symbol, or a set of them, or some time-series data.

Aerospike only runs natively on Linux. Though you could make it work on a desktop OS (Windows, Mac) with a virtual box, it might be best to use some other sort of local datastore for the desktop.Then the big thing would be to make sure you used some sort of data schema that would allow portability, such as JSON, so that data on the middle tier could be easily interchanged regardless of what desktop app, or even a “headless” transaction processing engine, was subscribing to it.