BMbmurphy1976·Apr 8, 2026
There's also https://github.com/kahing/goofys, a Go equivalent. A bit of a dead project these days.
In S3 Fileskahing
goofys
Go2015–2026
kahing / goofys
goofys
a high-performance, POSIX-ish Amazon S3 file system written in Go
9Distinct people
23Mentions
0Explicit recommenders
5.6KGitHub stars
What to know before exploring
What it is
a high-performance, POSIX-ish Amazon S3 file system written in Go
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- kahing/catfs · linked in 4 of the same discussions
- s3fs-fuse/s3fs-fuse · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2015-10-16 23:08:12 UTC to 2026-04-08 01:04:51 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
23 sourcesYou know what would be really awesome? Making a fuse-based drop-in replacement for mapping a folder to a bucket, like goofys. Maybe a node.js process can watch files for instance and backup, or even better it can back the folder and not actually take up space on the local machine (except for a cache).
https://github.com/kahing/goofys
In Show HN: S3mini – Tiny and fast S3-compatible client, no-deps, edge-ready>... it might make you feel good to pretend that this is really just a variant of storage systems on your local NVMe unit, and that therefore the APIs involved really ought to converge. [...]
The author needs to ask themselves: in this cloud technology stack, is there POSIX involved somewhere lower down, where I can't access it? The answer is, of course, "yes". The sort of cloud storage systems described all run on top of POSIX APIs. They provide convenience (cost efficiency is more debatable) compared to the POSIX alternative, but that's because they exist at an entirely different conceptual layer (hence the presence of POSIX anyway, just buried).
Your point about revealing a POSIX that's actually there but hidden and thus visible to low-level Amazon employees building the S3 service and invisible to S3 end customers is true but that isn
Read the rest
't the the point of the article. The author is saying there are motivations for a POSIX-like api to also be visible to the end user.
So your explanation of the "hidden POSIX" stack looks like 2 layers: POSIX api <-- AWS S3 built on top of that
Author's essay is actually talking about 3 layers: POSIX <-- AWS S3 <-- POSIX
That's why the blog post has the following links to POSIX-on-top-of-S3-objects :
https://github.com/s3fs-fuse/s3fs-fuse
https://github.com/kahing/goofys
https://www.cuno.io/
How is this different than these other solutions?
https://github.com/kahing/goofys
https://github.com/s3fs-fuse/s3fs-fuse
In AWS Announces Open Source Mountpoint for Amazon S3Another interesting discussion: https://stackoverflow.com/questions/14633686/possible-to-sym...
And some cool github links:
- https://github.com/kahing/goofys -- a high-performance, POSIX-ish Amazon S3 file system written in Go
- https://github.com/maxogden/mount-url -- mount a http file as if it was a local file using fuse
In Symlink to a URLSome examples:
- https://github.com/kahing/goofys
- https://github.com/s3fs-fuse/s3fs-fuse
In Raft Consensus Animated (2014)> We've had some ideas around using this for distributed querying: in our case, each node responsible for a given partition of a dataset would be able to download just the objects in that partition on the fly (though constraint pruning), so we wouldn't need to knowingly seed each worker with data.
IMHO, if you're going to do this, I'd recommend not doing this in Postgres itself, but rather doing it at the filesystem level. It's effectively just a tiered-storage read-through cache, and filesystems have those all figured out already.
You know how pgBackRest does "partial restore" (https://pgbackrest.org/user-guide.html#restore/option-db-inc...), by making all the heap files seem to be there, but actually the ones you don't need are sparse files ftruncate(1)'d to the right length to make PG happy? And that this works because PG only cares ab
Read the rest
out DB objects it's not actively querying insofar as making sure they're there under readdir(2) with the expected metadata?
Well, an object-storage FUSE filesystems, e.g. https://github.com/kahing/goofys, would make PG just as happy, because PG could see all the right files as "being there" under readdir(2), even though the files aren't really "there", and PG would block on first fopen(2) of each file while goofys fetched the actual object to back the file.
(IIRC PG might fopen(2) all its files once on startup, just to ensure it can; you can hack around this by modding the origin-object-storage filesystem library to not eagerly "push down" its fopen(2)s into object fetches — instead just returning a file-descriptor connected to a lazy promise for the object — and then have read(2) and write(2) thunk that lazy promise, such that the first real IO done against the virtual file be what ends up blocking to fetch the object.)
So you could just make your pg_base dir into an overlayfs mountpoint for:
• top layer: tmpfs (only necessary if you don't give temp tables their own tablespace)
• middle layer: https://github.com/kahing/catfs
• bottom layer: goofys mount of the shared heap-file origin-storage bucket
Note that catfs here does better than just "fetching objects and holding onto them" — it does LRU cache eviction of origin objects when your disk gets full!
(Of course, this setup doesn't allow writes to the tables held under it. So maybe don't make this your default tablespace, but instead a secondary tablespace that "closed" partitions live in, while "open" partitions live in a node-local tablespace, with something like pg_partman creating new hourly tables, and then pg_cron running a session to note down the old ones and do a VACUUM FREEZE ?; ALTER TABLE ? SET TABLESPACE ?; on them to shove them into the secondary tablespace — which will write-through the catfs cache, pushing them down into object storage.)
https://github.com/kahing/goofys/ can detect public bucket automatically and not require prior setup. https://cloud.google.com/storage/docs/gsutil works as well (despite it's from google it works fine with s3) iirc
In In praise of S3> 1. FUSE filesystems. This means sending really slow queries to S3, and so you're much better off using compression to get better performance.
As author of https://github.com/kahing/goofys/ I respectfully disagree :-)
In Loading NumPy arrays from disk: mmap() vs. Zarr/HDF5Define big data? Have you tried https://github.com/kahing/goofys/ ?
Disclaimer: I am the author
In Apache Arrow Flight: A Framework for Fast Data TransportIt support Azure too. https://github.com/kahing/goofys/blob/master/bench/azure/REA...
In Goofys: A high-performance, Posix-ish Amazon S3 file system written in GoGoofys: A high-performance, Posix-ish Amazon S3 file system written in Go
2 points · Open discussionI learned go and wrote https://github.com/kahing/goofys in a month, and learned rust and wrote https://github.com/kahing/catfs in about the same amount of time
In Ask HN: How long does it take you to learn a new language?It did ok for the most part, except it also suggested "goofys" as a tag for https://github.com/kahing/goofys.
In Topic Suggestions for Millions of Repositoriesgoofys - https://github.com/kahing/goofys/ - like s3fs except a lot faster
catfs - https://github.com/kahing/catfs/ - generic disk cache for fuse filesystems
In Ask HN: Projects that don't make you money but you're doing it out of sheer joy?Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.