The battle between powerful DB engines and nimble processes that keep
a limited set of state in memory has been waged on the trading floor
since time immemorial (at least the 80's). Just when you think the
database has won, some group doesn't want to afford the hardware and
licensing to support their usage and reverts back to the nimble
process. So I would expect there to be room for both models. Kx
products are not cheap, so maybe there is even room for niche EP
vendors to earn decent license rates in this area.

But... One reason for the success of KDB is that if you use it for
your tick database, you can be pretty sure that it will support most
of the stuff that you will want to do with the ticks. Fundamentally,
most CEP vendors don't do a good job of convincing me that their
product will be able to do (or at least will help with) everything I
will want to do in the future. Without this fundamental first step, EP
vendors can't really expect to see major adoption, and will be doomed
to the limbo of project-by-project sales.

--H

--- In CEP-Interest@yahoogroups.com, "Marc Adler" <magmasystems@...>
wrote:
>
> >>> (A tick database like KDB would handle this with no problem).
>
> Of course, I meant to say "A tick database IMPLEMENTED in KDB"
>