
ksqlDB: Event streaming database for stream processing applications - synthc
https://ksqldb.io/
======
xearl
The naming strikes me as quite unfortunate. Kdb+ is a (time-series) database
that supports the languages K and SQL. Naming a product in a similar space
KSQL was already a questionable idea. Jumping through the hoops of renaming
only to choose ksqlDB (which, arguably, is even more confusing) is, well,
unfortunate.

~~~
therein
Entirely agreed. I immediately thought this had something to do with Kx
Systems.

------
georgewfraser
Streams are a fascinating topic, but this is not in any way shape or form a
substitute for a real database. Take a look at the docs for joins:

[https://docs.confluent.io/current/ksql/docs/developer-
guide/...](https://docs.confluent.io/current/ksql/docs/developer-guide/join-
streams-and-tables.html)

It’s a long list of caveats about how your queries will silently fail if you
don’t guarantee all sorts of properties of the data.

Anyone considering making Kafka the center of your data infrastructure should
also consider using a conventional column-store database instead. The only
advantage of Kafka in this comparison is better latency (seconds vs minutes).
If you can live with a minute or two of latency, the advantages of a real
database are MANY.

~~~
dig1
There is major difference between Kafka and database(s): Kafka is used for
passing data through and databases are for storing the data. Also, KSQL/kdbSQL
are not intended to be general tool for transforming _all_ data, but to assist
you without writing custom services (unless I'm getting things wrong).

Now, should Kafka be central place for routing data? I think that is the main
reason why it exists. Should it be used for permanently storing data like
conventional database? Absolutely not.

By design, it will temporarily store it in case consumer goes offline, but you
can also use it to implement backpressure/queue for slow receivers that are
not capable to catch up with fast data ingestion (e.g. syslog -> kafka ->
logstash).

------
synthc
accompanying blog post: [https://www.confluent.io/blog/intro-to-ksqldb-sql-
database-s...](https://www.confluent.io/blog/intro-to-ksqldb-sql-database-
streaming)

------
darren0
I really think most people want a traditional SQL database that has a stream
query that gives real time updates. I honestly don't know enough about
databases to understand why that isn't a simple enough feature to implement.

------
lelc
Looks a lot like what VoltDB has for stream processing. Will definitely make
developing streaming apps a lot easier.

------
arnon
> It does not provide read-after-write consistency

So, this is probably the last "database" you should ever opt to use, unless
you're in a very serious bind.

~~~
egwor
I don't think that KDB does, either? MY understanding of this in KDB, and I
could be wrong (I'm not an expert) is that in KDB you can write to the
tickerplant database. Those clients subscribing to the realtime will see this
in realtime, and then eventually it will get asynchronously written to another
DB which allows querying. I guess you'd think of it as eventual consistency.
(Please correct me if I'm incorrect/misunderstood the above)

~~~
bladecatcher
You’re right. You don’t get read-your-own-writes guarantees in a typical Kdb
tickerplant architecture, as the event streams are propagated to the real-time
nodes asynchronously.

------
geocar
The subliminal uppercase is a bit tasteless though.

~~~
neonate
I don't understand, can you explain?

