32 bit version of KDB+ is now free for commercial use

Ck out Arthur Whitney&#x27;s abridged manual for fun:<p><a href="http://kx.com/q/d/kdb+.htm" rel="nofollow">http:&#x2F;&#x2F;kx.com&#x2F;q&#x2F;d&#x2F;kdb+.htm</a><p>For using the 32-bit version (from Limits):<p>22 Limits<p>Each database runs in memory and&#x2F;or disk map-on-demand -- possibly partitioned. There is no limit on the size of a partitioned database but on 32-bit systems the main memory OLTP portion of a database is limited to about 1GB of raw data, i.e. 1&#x2F;4 of the address space. The raw data of a main memory 64bit process should be limited to about 1&#x2F;2 of available RAM.

This has come up before here, and the recent GNU APL stuff reminded me, but in summary, if you have ever been curious about APL or mildly suspicious of more conventional database approaches you owe it to yourself to take a look at the concepts at work here, especially primacy to columns instead of rows.<p>The &amp; &quot;where&quot; operator in raw k has stayed with me over the years as a particularly inspired way to deal with column based data.

Careful with these guys. I once built an open source implementation of the q language, and these guys immediately threatened to sue me, my employer, and our clients. The language is not that interesting, it&#x27;s easy to reproduce, and these guys will threaten you if you prove this.

For the unindoctrinated, KDB+ is an extremely fast, column oriented, in-memory database. It&#x27;s based on a language called Q and has been used at many banks to store exchange related data.

For anyone trying this out for the first time, Jeff Borror&#x27;s q for mortals is the best guide out there <a href="http://code.kx.com/wiki/JB:QforMortals2/contents" rel="nofollow">http:&#x2F;&#x2F;code.kx.com&#x2F;wiki&#x2F;JB:QforMortals2&#x2F;contents</a>

I&#x27;m not sure about the Q language, but their C API reads like obfuscated C contest entry: <a href="http://kx.com/q/c/c/k.h" rel="nofollow">http:&#x2F;&#x2F;kx.com&#x2F;q&#x2F;c&#x2F;c&#x2F;k.h</a>

Currently using MongoDB for my historical quotes ticks database. Any peeps in trading use KDB+ in production or for fun think it&#x27;s expressive enough to write queries directly to it for backtesting?

Except financial applications what is it good for ?