He said he would open source it 11 hours ago in multiple twitter replies but the github link to the repo as seen in the statically linked binary that they recommend to curl and pipe into your shell instead of any popular packaging solution (which doesn't seem to verify against a signed gpg signature - only a hash file obtained from the same subdomain)... Hosted on a domain registered only last month instead of their company's primary domain.
But it has been tweeted about by the creator who works there so maybe it's not all that suspicious.
Was this vibecoded? Right down to the curl pipe? It's really strange that the code isn't public yet.
Nice. I was a bit skeptical of the software distribution process and lack of a source for a company who usually opens their source. But this is great thank you.
Brilliant. I wonder what limits we can hit with this setup. What if local postgres is installed and its data directory location is on TigerFS, what are the trade-offs here? Could placing SQLite file on TigerFS mount increase durability for Litestream setup? Is it possible to somehow run have TigerFS database storing data on TigerFS?
Yes, TigerFS works well with local PG - in fact, all of my testing framework uses this setup.
Big upside of this is latency; main downside is that such a deployment is primarily "single user mode."
One very interesting approach of this is ability to transparently share state / collaborate across machines, with these transactionally serialized at the common database.
I primarily work with Postgres, including both at scale and in very ephemeral environments. So just haven't looked at all what doing with this SQLite would mean.
Super interesting. I love to see more stuff built on top of filesystem APIs.
I wonder what the performance characteristics are?
I'm assuming this is going to work well for small datasets that fit in memory, and probably less well beyond that. So good for config, context etc.
Also curious how the tables and index are maintained, for example if there's a write heavy workload. Does TigerFS handle rebuilding/repacking and the associated drudgery?
He said he would open source it 11 hours ago in multiple twitter replies but the github link to the repo as seen in the statically linked binary that they recommend to curl and pipe into your shell instead of any popular packaging solution (which doesn't seem to verify against a signed gpg signature - only a hash file obtained from the same subdomain)... Hosted on a domain registered only last month instead of their company's primary domain.
But it has been tweeted about by the creator who works there so maybe it's not all that suspicious.
Was this vibecoded? Right down to the curl pipe? It's really strange that the code isn't public yet.
github.com/timescale/tigerfs
Nice. I was a bit skeptical of the software distribution process and lack of a source for a company who usually opens their source. But this is great thank you.
Brilliant. I wonder what limits we can hit with this setup. What if local postgres is installed and its data directory location is on TigerFS, what are the trade-offs here? Could placing SQLite file on TigerFS mount increase durability for Litestream setup? Is it possible to somehow run have TigerFS database storing data on TigerFS?
Hey, author here. Just noticed this.
Yes, TigerFS works well with local PG - in fact, all of my testing framework uses this setup.
Big upside of this is latency; main downside is that such a deployment is primarily "single user mode."
One very interesting approach of this is ability to transparently share state / collaborate across machines, with these transactionally serialized at the common database.
I primarily work with Postgres, including both at scale and in very ephemeral environments. So just haven't looked at all what doing with this SQLite would mean.
What's the performance implications? Latency/throughput?
Super interesting. I love to see more stuff built on top of filesystem APIs.
I wonder what the performance characteristics are?
I'm assuming this is going to work well for small datasets that fit in memory, and probably less well beyond that. So good for config, context etc.
Also curious how the tables and index are maintained, for example if there's a write heavy workload. Does TigerFS handle rebuilding/repacking and the associated drudgery?
Really nice concept. I like the idea of using file system primitives to interact with structured data.
cool
lol did this just kill git?
Git is just so much more than that.