Joined March 2009
316 Photos and videos
Pinned Post
Introducing TigerFS - a filesystem backed by PostgreSQL, and a filesystem interface to PostgreSQL. Idea is simple: Agents don't need fancy APIs or SDKs, they love the file system. ls, cat, find, grep. Pipelined UNIX tools. So let’s make files transactional and concurrent by backing them with a real database. There are two ways to use it: File-first: Write markdown, organize into directories. Writes are atomic, everything is auto-versioned. Any tool that works with files -- Claude Code, Cursor, grep, emacs -- just works. Multi-agent task coordination is just mv'ing files between todo/doing/done directories. Data-first: Mount any Postgres database and explore it with Unix tools. For large databases, chain filters into paths that push down to SQL: .by/customer_id/123/.order/created_at/.last/10/.export/json. Bulk import/export, no SQL needed, and ships with Claude Code skills. Every file is a real PostgreSQL row. Multiple agents and humans read and write concurrently with full ACID guarantees. The filesystem /is/ the API. Mounts via FUSE on Linux and NFS on macOS, no extra dependencies. Point it at an existing Postgres database, or spin up a free one on Tiger Cloud or Ghost. I built this mostly for agent workflows, but curious what else people would use it for. It's early but the core is solid. Feedback welcome. tigerfs.io
77
112
1,153
132,121
This chart represents something I'm really proud of: almost a decade of engineering delivery. Consistency. It’s not just for database transactions.
That time of the year again. #Postgres19
1
2
16
1,823
Mike Freedman reposted
"@TimescaleDB is the new standard." That's @Siemens' conclusion for their industrial data historian. Replacing their use of Oracle, SQL Server, InfluxDB, and vanilla Postgres. Powering their next-generation industrial data platform. 🤌
3
10
37
2,022
10,000 GitHub contributions for @TimescaleDB! That's a metric to celebrate! 🥳
TimescaleDB just hit 10,000 contributions. Every ticket, comment, and PR got us here, from Tiger Data engineers to contributors around the world. Thank you. On to 100,000. #TimescaleDB #PostgreSQL #OpenSource
4
25
1,847
That time of the year again. #Postgres19
13
2,891
Congrats to @Polymarket for surpassing $1B in revenue run rate. Remarkable to join that small group of companies so quickly. And proud that @TimescaleDB and Tiger Cloud help power your critical database infrastructure. 📈📈📈 cnbc.com/2026/06/26/polymark…
3
8
553
Continuous aggregates are one of the most popular TimescaleDB features: incrementally maintained rollups that accelerate analytical queries while transparently handling late-arriving and backfilled data. The challenge is that analytical questions evolve. Need another aggregation? Historically, that meant dropping and rebuilding the continuous aggregate. In @TimescaleDB 2.28, adding a new aggregate to an existing continuous aggregate is just: > ALTER MATERIALIZED VIEW ... ADD COLUMN New values are computed automatically going forward. If you want historical values for the new column, simply run a refresh. Analytical requirements change. Your rollups should be able to change with them.
1
4
19
1,500
Local development remains hard to beat. $ curl -sL tsdb.co/start-local | sh
5
27
2,980
Webinar by CERN engineers (Thurs, June 25, 2026, 9 am ET / 3pm CET): tigerdata.com/events/webinar…
6
251
CERN operates some of the most complex infrastructure humanity has ever built. And the infrastructure that accelerates protons runs on data. Together with @Siemens, @TimescaleDB helps power 800 control systems supporting the ATLAS, CMS, LHCb, and ALICE experiments, along with the infrastructure behind them: electrical grids, cryogenics, vacuum systems, cooling, ventilation, radiation monitoring, gas distribution, machine protection, and more. Proud to play a small role in enabling both fundamental science and the systems that make it possible. For those interested in a technical deep dive into CERN's next-generation control system archives, webinar link below.
1
7
32
1,595
or: the filesystem is the API?
2
23
5,010
A little over a decade ago, I visited Facebook's Prineville datacenter. Facebook had brought together a small group of systems and networking researchers to discuss the future of datacenter infrastructure. What struck me then was how much of the physical design was organized around energy efficiency. The metric everyone cared about was PUE, or Power Usage Effectiveness: total facility power divided by IT equipment power. Older industry averages could be around 2.0 or higher, meaning that a large amount of power was spent on cooling, power distribution, and other facility overhead. Prineville represented a very different design point, with a PUE around 1.07 annualized at full load. The architecture made that plausible. It was fundamentally air-cooled, but carefully engineered: large slow fans to pull in outside air, filtration systems designed to handle air particulate (even from forest fires tens of miles away), evaporative "swamp" coolers on the second level, hot aisle containment, and large ductless supply paths where cool air naturally sank from the upper mechanical level into the data hall. That was the design point: move outside air efficiently, while minimizing the amount of active mechanical work required to cool the data hall. AI infrastructure changes the thermal design basis. For practical purposes, every watt of electrical power delivered to IT equipment must be removed as heat. Facebook later described its overall datacenter design point as about 5.5 kW per rack, with compute-heavy web-server racks around 10 to 12 kW. And if we use a much denser 20 kW CPU-era rack as the comparison point, that rack generates about 68,000 BTU/hour of heat. The airflow math around heat transfer is straightforward. If we allow a 20°F temperature rise across the rack, the 20 kW CPU-era rack needs roughly 3,000 CFM of airflow. For comparison, a typical central AC system in a 2,500 square foot home might move roughly 1,500 to 2,000 CFM of air. Even a 20 kW rack is effectively moving the airflow of one or two homes through a single cabinet. A current rack of NVIDIA Blackwell GPUs, such as the GB300 NVL72, is roughly 140 kW. That is about 478,000 BTU/hour from one rack. If air had to remove the full heat load, it would require more than 22,000 CFM, akin to pushing the airflow of a dozen homes through a single rack. And that is today. NVIDIA's future Rubin Ultra Kyber rack has been reported around 600 kW. If air had to remove that full heat load, the required airflow would be close to 95,000 CFM, roughly the airflow of 50 homes' central AC systems. More importantly, the challenge is not simply moving enough air through the rack. Modern AI accelerators concentrate enormous amounts of heat into a small physical area, so air alone becomes increasingly impractical as the primary path for removing heat from the chip package. In other words, the engineering of heat transfer at this scale fundamentally changes. Once the rack moves from tens of kilowatts to 100 kilowatts, the cooling system changes from "move enough air through the room" to "capture heat at the components and transport it through a liquid cooling loop." It also shortens the operational time window. A loss of coolant flow is no longer simply a maintenance issue. It can immediately affect compute availability. Operators now need visibility into coolant flow, pressure, inlet and outlet temperatures, pump state, cooling-system health, leak detection, rack thermal behavior, workload placement, and history. There is a joke that AI factories convert energy into tokens. But like advanced manufacturing facilities, they depend on complex physical infrastructure, continuous monitoring, and operational control systems. And increasingly, the data systems needed to understand and optimize them. A decade ago, most of us thought of the datacenter as the substrate underneath the distributed system. Increasingly, the datacenter itself is becoming part of the distributed system. More to write.
2
5
23
2,952
PSA for #Postgres extension developers: Consider adding open-source pgspot to your release CI pipeline. github.com/timescale/pgspot We regularly evaluate extensions for Tiger Cloud, and pgspot consistently finds security issues, privilege escalations, and unsafe patterns before deployment. We try to report what we find upstream through issues and PRs, but even better is catching these problems before a release ever ships.
6
29
1,494
Why do Postgres servers fall victim to OOM-killers despite having seemingly sound configurations? At Swiss PGDay on June 25, @TigerDatabase platform engineers @hintbits and Dimitris will share an intensive exploration of the failure path. They'll examine the complexities of Linux overcommit, cgroups, and Postgres memory architecture to understand why the kernel issues a SIGKILL. ⚡ The session will also highlight how eBPF was utilized for troubleshooting and how combining Patroni hooks with Postgres extensions can create a dependable memory ceiling. This deep dive offers a debugging experience that provides profound insights into both Linux and #Postgres operations. Link below.
1
6
40
3,549
Mike Freedman reposted
Agents love files. The problem is that files were never designed for agents. No transactions. No isolation. No safe undo. TigerFS turns Postgres into a transactional filesystem. With TigerFS 0.7, released today, we've added arbitrary rollback. Every filesystem operation is recorded in a history log, allowing you to undo changes from a named snapshot, revert a single file or operation, or selectively undo the work of a specific agent. Git is great for collaboration. It's less great as an undo log for AI agents. Don't trust agents to clean up after themselves. Give them an undo button. tigerfs.io
4
10
67
4,071
x.com/michaelfreedman/status…
Agents love files. The problem is that files were never designed for agents. No transactions. No isolation. No safe undo. TigerFS turns Postgres into a transactional filesystem. With TigerFS 0.7, released today, we've added arbitrary rollback. Every filesystem operation is recorded in a history log, allowing you to undo changes from a named snapshot, revert a single file or operation, or selectively undo the work of a specific agent. Git is great for collaboration. It's less great as an undo log for AI agents. Don't trust agents to clean up after themselves. Give them an undo button. tigerfs.io
142
Mike Freedman reposted
Now let's undo the undo with TigerFS to restore the changes... Filesystem interface skills. Agents are so good at this.
Revert all changes to the last savepoint. Let your agents cook, then clean up when they make a mess of everything. 😀
2
3
18
2,776