Message DB: Event Store and Message Store for PostgreSQL
blog.eventide-project.org
Message DB: Event Store and Message Store for PostgreSQL
1–10 of 104 posts
Re: Message DB: Event Store and Message Store for PostgreSQL
#2this looks very interesting
Re: Message DB: Event Store and Message Store for PostgreSQL
#3Looks interesting but needs a few more language libraries to demonstrate broader utility outside of just Ruby projects.
Building on top of generic Postgres using a simple service is pretty neat but without the extra client libraries it’s hard to see a bright future.
The npm module doesn’t look like it actually does anything besides unzip and run the dB setup code at the moment so it’s definitely early days for them. But with a few basic client libraries that can actually do the work of publishing and subscribing to messages, this will be a pretty neat tool.
I’m going to have to watch how this develops.
Re: Message DB: Event Store and Message Store for PostgreSQL
#4Looks cool. I can't find any performance or benchmarks though. Anyone care to guess/ballpark what kind of write speeds single nodes might be able to handle?
Re: Message DB: Event Store and Message Store for PostgreSQL
#5It looks very awesome! However, how does it compares with a tiered message queue like Redis as frontend and Postgres/MySQL as backend?
Re: Message DB: Event Store and Message Store for PostgreSQL
#6On behalf of a technology team, looking to incorporate a messaging platform to our landscape: I am curious to understand the motivation behind implementing a messaging system on top of a database technology. There are robust offerings both for small scale and large throughput systems. What are the benefits of this project over other implementations(RabbitMQ, Kafka, Celery, ActiveMQ, ZeroMQ, SNS/SQS)?
Re: Message DB: Event Store and Message Store for PostgreSQL
#7On behalf of a technology team, looking to incorporate a messaging platform to our landscape: I am curious to understand the motivation behind implementing a messaging system on top of a database technology. There are robust offerings both for small scale and large throughput systems. What are the benefits of this project over other implementations(RabbitMQ, Kafka, Celery, ActiveMQ, ZeroMQ, SNS/SQS)?
Biggest wins I can imagine:
Atomic changes (rollback can undo any unprocessed messages)
Fewer moving parts, if you already need a DB
Easily query state of queues and messages with famailar SQL
Re: Message DB: Event Store and Message Store for PostgreSQL
#8Very interesting. This uses "Postgres server functions that can be used with any programming language or through the psql command line tool. Interaction with the underlying store through the Postgres server functions ensures correct writing and reading messages, streams, and categories." (https://github.com/message-db/message-db#api-overview)
In Elixir-land, there is https://github.com/commanded/eventstore (which AFAICT is closely tied to the Commanded CQRS/RS framework https://github.com/commanded/commanded)
Re: Message DB: Event Store and Message Store for PostgreSQL
#9"for"? I feel like this should be "in PostgreSQL". I thought this was something that was used internally by Postgres.
Re: Message DB: Event Store and Message Store for PostgreSQL
#10Looks interesting but needs a few more language libraries to demonstrate broader utility outside of just Ruby projects. Building on top of generic Postgres using a simple service is pretty neat but without the extra client libraries it’s hard to see a bright future. The npm module doesn’t look like it actually does anything besides unzip and run the dB setup code at the moment so it’s definitely early days for them.…
Publishing and subscribing are through SQL SELECT statements which can be called straight forward enough from most or all languages. Administering it does indeed require shell or ruby.
Better still in my opinion if possible, implement your business logic in PL/pgSQL procs with these SELECTs within them and call them from whatever client/frontend you are using. I know it's not cool right now but there's big advantages and a disadvantage to putting business logic in the DB is said to be vendor lock but when it comes to Postgres, lock me up and throw away the key.