Hacker News Reader

Comment by kyleperik | Hacker News Reader

"Functional Database" is contradictory. Honestly this sounds like a bunch of buzzwords concatenated together. Is there an example or a purpose for this?

View on HN

Personally, I've heard of it in the context of https://github.com/commanded/commanded, a CQRS framework for Elixir that supports EventStore as a storage backend.

I think the idea is that it's something simpler than a database. It's more like an append-only file that has on-insert triggers/durable running queries. (Sort of like https://www.pipelinedb.com/ does, or like blockchain nodes do.)

Or, you could think of it as message queue like Kafka, with permanent durability of all "messages", and a single fixed subscriber bolted onto the queue server, where that subscriber is exposed through the queue server's API, allowing users to reprogram it arbitrarily.

It isn’t that contradictory. You can have data in a functional language. One of the common features of a functional language that separates it from imperative is data immutability. In this case it’s a database of immutable data. I personally understand exactly what they’re talking about when they call it a functional database.

I don't understand how this is useful. The purpose of functional programming isn't to make everything immutable, but to use immutability to prevent unnecessary change of state which can result in flaky code. So where's the usefulness in a functional Database?

Also this still isn't functional. Is adding records to a set not mutation?

I think your question is answered here: https://eventstore.org/docs/event-sourcing-basics/event-stor...

Oh I see I misunderstood then. But still, how is this a database? Without looking into it too much it seems that would either be an ORM or simply state.

A database is simply an organized collection of data with a restricted interface for accessing and/or querying said data. This seems to qualify.

Should we call PANDAS a database?

Add "durable" qualifier to my definition, since otherwise you could say that it's just a data structure. Which it is, but with durability properties.

Think about it as database of function calls, ordered by creation time. I'd however call it a log rather than a database - there will be a state your data achieves, but ES becomes the source of truth . DB can still used to contain the current state (however is not needed as ES tracks its own state) and data can be dropped from DB without repercussions, if you don't mind replaying events and have a separation of events that deal with setting data / performing external actions (like sendin emails for example)

They should make this more prominent, now I get what it does

Edit: Is a backup mechanism implemented? It's for persistent data, right?

git is a functional database, well almost. Datomic is what you get when you finish that idea. it does mostly all the same sorts of things postgres does, but like git, the strength is it has idealized caching at all layers and scales horizontally / serverless. it is also just better (do you know anyone who thinks git sucks and wants to go back to SVN or CVS?)

I don't know anything about EventStore, but immutability and databases go surprisingly nicely together. Mash together versioned data and persistent data structures, and you get to store history efficiently (and can have separate operations for excising history). See eg Datomic.

Reply on news.ycombinator.com